kernel/comm.c - page fault in thread

[Cihan Altinay]

Uwe Bonnes wrote:
>     Cihan> I am currently in Australia so I guess it wouldn't be possible
>     Cihan> although it would help a lot.
> 
> It's only a RS232 9 pin connector with 3 solder blobs. If you have a solder
> iron, easily done yourself.

Ok, I'll see if it is still necessary.

>     Cihan> I am still trying to figure out what the problem might be when
>     Cihan> using purge to clear the output buffer. When G-Ware writes
>     Cihan> subsequently to the port it looks like this:
>     Cihan> 1) Purge (input/output)
>     Cihan> 2) Write
>     Cihan> 3) SetWaitMask (RXCHAR|RXFLAG|CTS|DSR|RLSD|BRK|ERR)
>     Cihan> 4) WaitCommEvent
>     Cihan> (4a) Read input if there's something)
>     Cihan>  Goto 1)
> 
>     Cihan> As you can see there is no TXEMPTY flag so G-Ware seems to rely
>     Cihan> on the buffers to be emptied beforehand and then just calls Purge
>     Cihan> before writing again.  Just to make sure I wrote a short program
>     Cihan> that does the following:
>     Cihan> 1) Write command 
>     Cihan> 2) Purge 
>     Cihan> 3) Write
> 
>     Cihan> another command (Without any delay). Obviously some bytes from
>     Cihan> the first command are flushed away and thus the device indeed
>     Cihan> returns the same error value I get under G-Ware. 
> 
> Here you forgot the behaviour of the actual device. It probably only reacts
> when a complete command is written and terminated in some way, perhaps a CR
> or something like that. If G-Ware send this "magic" byte as the last
> command, no need fot tcdrain or such....

It's a bit more complicated. When connecting to the device G-Ware reads
out all stored values (quite a lot of traffic). Most of the commands to
do that are 16 or 96 bytes long and are not terminated by any character
(the command length is fixed depending on the command code).
It happens quite frequently that commands (mostly the shorter ones) are
sent out one after another in one string (ie. 32/192 bytes) with no
problem. So the device actually decodes the command and interprets the
correct amount of bytes that follow as parameters or whatever and then
continues with the next command after sending a reply.
What seems to happen under wine is that a command string is put in the
transmit buffer and before it is actually sent out completely the buffer
is flushed and a new command is sent out resulting in an error because
the parameters are wrong (or sometimes 'command too long').

What I don't know is why this happens under wine and I tried a lot to
find out... any help would be appreciated.

>     Cihan> I can prevent it
>     Cihan> by using tcdrain() or insert a sleep with a large enough value.
>     Cihan> I also tried to _see_ it by using a tty instead of the serial
>     Cihan> port but interestingly that does work, ie. no bytes are lost.
>     Cihan> Uwe, could you try and see what happens when you use the loopback
>     Cihan> and do a Write-Purge-Write sequence under both, wine and windows?
> 
> I am sure that bytes will get lost without any kind of line dicipline...

I would think so as well but maybe something that works differently
under windows prevents this loss? Therefore I thought an actual test
would clarify.

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

Sorry, forgot to ask for comments here. Is it possible to do what I
suggest? Does it sound right at all?


Thanks a lot,
Cihan