kernel/comm.c - page fault in thread

[Cihan Altinay]

Uwe Bonnes wrote:
> If you need input into the serial port, consider using some kind of
> loopback. Either use the plug with the appropriate pins shorted , or use two
> serial lines with a crossover cable.
> 
> Where do you live. I could consider sending you the plug..

I am currently in Australia so I guess it wouldn't be possible although
it would help a lot.

>     Cihan> I found in the documentation that the PARMRK flag duplicates 0xff
>     Cihan> in the stream to avoid confusion with the actual error
>     Cihan> character. I verified that by inspecting the stream with/without
>     Cihan> flag set.  Can we simply clear the PARMRK flag in wine or is
>     Cihan> there something similar under windows?
> 
> Clear all those offending flags and write a comment that somebody looking in
> the code can understand.

Can I just do that around line 1106 where c_iflag is initialized?
I will send a patch out shortly.

I am still trying to figure out what the problem might be when using
purge to clear the output buffer. When G-Ware writes subsequently to
the port it looks like this:
1) Purge (input/output)
2) Write
3) SetWaitMask (RXCHAR|RXFLAG|CTS|DSR|RLSD|BRK|ERR)
4) WaitCommEvent
(4a) Read input if there's something)
5) Goto 1)

As you can see there is no TXEMPTY flag so G-Ware seems to rely on
the buffers to be emptied beforehand and then just calls Purge before
writing again.
Just to make sure I wrote a short program that does the following:
1) Write command
2) Purge
3) Write another command
(Without any delay). Obviously some bytes from the first command are
flushed away and thus the device indeed returns the same error value
I get under G-Ware. I can prevent it by using tcdrain() or insert a
sleep with a large enough value.
I also tried to _see_ it by using a tty instead of the serial port
but interestingly that does work, ie. no bytes are lost.
Uwe, could you try and see what happens when you use the loopback and
do a Write-Purge-Write sequence under both, wine and windows?

One more thing regarding the page fault in the EventService:
We obviously have to set the buffer to 0 when the event mask changes
because that's what the API spec says. But maybe we have to monitor
which threads exist and wake them up when SetCommMask is called so
that they finish their work before SetCommMask returns.
MSDN says: "...WaitCommEvent returns immediately"

Sorry for my long posts, I hope we can close this thread soon...

Cheers,
Cihan