kernel/comm.c - page fault in thread

[Mr Cihan ALTINAY]

Hi again,

Sorry for the double post and the stupid default From-Header
(not my machine).
I replaced my modified comm.c with the latest CVS, made the changes
as described below and still got communication errors (the device
replies that commands are malformed). So I attempted to apply the
changes I made one-by-one to see when the errors disappear. And the
first (and easiest) change helped:
When replacing both
  tcflush(fd,TCOFLUSH)
by
  tcdrain(fd)
in the PurgeComm function all errors disappear and the program works
as expected.
Now, I know that the two functions do different things and according
to the API specification of PurgeComm tcflush seems more appropriate.
So I wonder if this is not really a fix but only a workaround for a
different problem (maybe a race condition as mentioned earlier?).

I know that G-Ware does some funny (stupid?) things and there are
always at least 2 threads running that poll for input/output. One
effect is that it still opens ~200 file handles to the port but,
more importantly, maybe they interact in a way it shouldn't happen?

Anyone?


----- Original Message -----
From: Mr Cihan ALTINAY <cihan at uq.edu.au>
Date: Tuesday, November 8, 2005 10:13 am
Subject: kernel/comm.c - page fault in thread
> Hi,
> 
> I finally got G-Ware to work flawlessly under wine after some
> tweaks in the comm.c file. One problem was in the (thread) function
> COMM_WaitCommEventService().
> When I 'disconnect' in the client program it calls purge and sets
> the event mask to 0 (ie. it is no longer interested in events from
> the port). But there are still threads running that poll the port.
> 
> The program crashes when the thread exits the loop (with abort!=0)
> and tries to set
>  *commio->buffer = rc;
> (line 2010) but this buffer is already freed by the client.
> Replacing
> 
>  if (abort) rc = 0;
>  *commio->buffer = rc;
> 
> by
> 
>  if (!abort)
>      *commio->buffer = rc;
> 
> fixes this problem.
> 
> There were other communication errors which I managed to fix but
> I have to find out first which changes are really necessary to
> make things work because I tried a lot of things in comm.c.
> It looks as if there are race conditions when more than one
> polling thread is running. Currently I check if a thread is already
> running and don't start a second one if so. But I will find out if
> that is responsible for the errors or something else and report it
> on the list.
> 
> Cheers,
> Cihan
> 
> 
> 
>