kernel/comm.c - page fault in thread
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.
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"
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