kernel/comm.c - page fault in thread

Uwe Bonnes bon at elektron.ikp.physik.tu-darmstadt.de
Mon Nov 14 03:32:54 CST 2005


>>>>> "Cihan" == Cihan Altinay <cihan at uq.edu.au> writes:

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

    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.

    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.

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

Looks reasonable

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


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

    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"

Bye

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

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



More information about the wine-devel mailing list