kernel/comm.c - page fault in thread

[Cihan Altinay]

Uwe Bonnes wrote:
>>>>>>"Cihan" == Cihan Altinay <cihan at uq.edu.au> writes:
> 
> 
>     Cihan> Uwe Bonnes wrote:
>     >>>>>>> "Cihan" == Cihan ALTINAY <cihan at uq.edu.au> writes:
>     >>
>     Cihan> Hi again, Sorry for the double post and the stupid default
>     Cihan> From-Header (not my machine).  I replaced my modified comm.c with
>     Cihan> the latest CVS, made the changes as described below and still got
>     Cihan> communication errors (the device replies that commands are
>     Cihan> malformed). So I attempted to apply the changes I made one-by-one
>     Cihan> to see when the errors disappear. And the first (and easiest)
>     Cihan> change helped: When replacing both tcflush(fd,TCOFLUSH) by
>     Cihan> tcdrain(fd) in the PurgeComm function all errors disappear and
>     Cihan> the program works as expected.  Now, I know that the two
>     Cihan> functions do different things and according to the API
>     Cihan> specification of PurgeComm tcflush seems more appropriate.  So I
>     Cihan> wonder if this is not really a fix but only a workaround for a
>     Cihan> different problem (maybe a race condition as mentioned earlier?).
>     >>
>     Cihan> I know that G-Ware does some funny (stupid?) things and there are
>     Cihan> always at least 2 threads running that poll for input/output. One
>     Cihan> effect is that it still opens ~200 file handles to the port but,
>     Cihan> more importantly, maybe they interact in a way it shouldn't
>     Cihan> happen?
>     >>  Obvious my WaitCommEvent implementation is not right for G-Ware
>     >> (b.t.w.: any pointers to a dwonloadable version?). Can you write test
>     >> case for to show where the current implementation is at fault? Maybe
>     >> the server needs to be involved...
> 
>     Cihan> You can find G-Ware 5.0.6 here as posted in the first message:
>     Cihan> http://www.clearone.com/docs/downloads/G-Ware5.0.6.zip [20MB]
> 
>     Cihan> However, without a suitable echo canceller device there is
>     Cihan> probably not much you can see. If you like I can send a short log
>     Cihan> of the input/output behaviour under windows and under wine to
>     Cihan> show the difference (basically the input seems to accumulate more
>     Cihan> under wine and it happens more often that we read >200 bytes at
>     Cihan> once whereas this doesn't happen under windows).  I would like to
>     Cihan> write a test case but we don't have 'real' Windows [here at
>     Cihan> university]. Instead, we were using VMWare up till now just to
>     Cihan> get this program running (that's why it's so important for us to
>     Cihan> be able to use wine).
> 
> If tests show a difference in behaviour betweem Wine and VMWare, I guess
> wine will be wrong. I can than test with my XP machine, if you send me the
> test.

I studied the test cases in tests/comm.c but I am not sure how to
implement a test that requires input from the serial port. I saw the
loopback possibility but I cannot test it.
Do I need to write a test case for the first issue as well (where
*commio->buffer is written to after it is already freed)? It seems
quite obvious that the thread may still be running after the client
frees its buffers.


>     Cihan> In regards to this I found out something else today while
>     Cihan> testing: When I run the program under wine with the changes
>     Cihan> applied I mentioned before, then everything works fine.  Starting
>     Cihan> vmware with a serial port enabled and closing it down again and
>     Cihan> trying to run G-Ware under wine again breaks things: I get
>     Cihan> 'Timeout' errors and the like. It took me a while to see the
>     Cihan> reason: Under wine I get extra bytes inserted in the data and a
>     Cihan> check of the serial parameters shows why - vmware enables the
>     Cihan> INPCK flag of the serial port when exiting (who knows why) and
>     Cihan> wine doesn't reset the the flags but only OR's and AND's it with
>     Cihan> flags needed.  I would say vmware is not behaving correctly but
>     Cihan> on the other hand we never set the input flags to a fixed state
>     Cihan> which makes things unpredictable. Any comments?
> 
> Here the test would be: Open the port, set the INPCK flag. Then close it and
> then try to provoke the error you observe.
> 
> I guess wine should reset the parity check flag...

Sorry I just found out that the extra bytes are actually caused by the
PARMRK input flag. Interestingly vmware leaves this (and the INPCK) flag
on while G-Ware is running and it still works so it seems vmware is
handling the mark character without passing it on.

I wrote a little test program to confirm that this time. All it does is:
- Get current tty settings via ioctl
- toggle the PARMRK flag
- Write back settings

(1) Run vmware->Run wine->fail (getting bogus 0xff in data stream)
(2) toggle flag->run wine->success
(3) toggle flag->run wine->fail
etc.

I found in the documentation that the PARMRK flag duplicates 0xff in
the stream to avoid confusion with the actual error character. I
verified that by inspecting the stream with/without flag set.
Can we simply clear the PARMRK flag in wine or is there something
similar under windows?

Cheers,
Cihan