kernel/comm.c - page fault in thread

[Uwe Bonnes]

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

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

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