kernel/comm.c - page fault in thread

Cihan Altinay cihan at uq.edu.au
Wed Nov 9 03:15:37 CST 2005


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...

You can find G-Ware 5.0.6 here as posted in the first message:
http://www.clearone.com/docs/downloads/G-Ware5.0.6.zip [20MB]

However, without a suitable echo canceller device there is probably not
much you can see. If you like I can send a short log of the input/output
behaviour under windows and under wine to show the difference (basically
the input seems to accumulate more under wine and it happens more often
that we read >200 bytes at once whereas this doesn't happen under
windows).
I would like to write a test case but we don't have 'real' Windows [here
at university]. Instead, we were using VMWare up till now just to get
this program running (that's why it's so important for us to be able to
use wine).

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

Cheers,
Cihan



More information about the wine-devel mailing list