kernel/comm.c - page fault in thread

[Uwe Bonnes]

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


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

Bye
-- 
Uwe Bonnes                bon at elektron.ikp.physik.tu-darmstadt.de

Institut fuer Kernphysik  Schlossgartenstrasse 9  64289 Darmstadt
--------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------