[Bug 1244] Failure to communicate with serial device

[Wine Bugs]

http://bugs.winehq.com/show_bug.cgi?id=1244





------- Additional Comments From winebug at flonet.net  2003-23-06 12:40 -------
Bug comments restored from Gmane.org: 

I'm trying to run Garmin's "UPDATER.EXE", which is supposed to load a new
firmware image into a GPS device.  Communication is done over a serial port.

If I run the program without any debugmsg flags, it fails immediately,
complaining that it can't find the GPS.  However, if I run with:

--debugmsg +comm,+file,+serial

then it gets a bit further.  The first thing it does is get the model number and
current firmware version from the device.  But it soon fails again before
beginning the upload.  Here's an annotated debug log:

trace:comm:COMM_Init COM1 = /dev/ttyS0
trace:comm:COMM_Init LPT1 = /dev/lp0
trace:comm:COMM_Init COM2 = /dev/ttyS1
trace:comm:COMM_Init COM3 = /dev/ttyS2
trace:comm:COMM_Init COM4 = /dev/ttyS3
trace:file:CreateFileW L"COM2" GENERIC_READ GENERIC_WRITE OPEN_EXISTING 
attributes 0x0
trace:file:CreateFileW opening device L"COM2"
trace:file:DOSFS_CreateCommPort L"COM2" c0000000 0
trace:file:CreateFileW returning 0x4c
trace:comm:GetCommState handle 0x4c, ptr 0x41222858
trace:comm:GetCommState OK
trace:comm:GetCommState bytesize 8 baudrate 9600 fParity 0 Parity 0 stopbits 1
trace:comm:GetCommState ~IXON ~IXOFF
trace:comm:GetCommState ~CRTSCTS
trace:comm:SetCommState handle 0x4c, ptr 0x41222858
trace:comm:SetCommState bytesize 8 baudrate 9600 fParity 0 Parity 0 stopbits 1
trace:comm:SetCommState ~IXON ~IXOFF
trace:comm:GetCommTimeouts (0x4c,0x41222844)
trace:comm:SetCommTimeouts (0x4c,0x41222844)
fixme:comm:SetupComm insize 4096 outsize 4096 unimplemented stub
trace:comm:PurgeComm handle 0x4c, flags f
trace:comm:ClearCommError handle 0x4c cbInQue = 0 cbOutQue = 0
trace:file:WriteFile 0x4c 0x40f01851 6 0x41222670 (nil)
trace:comm:ClearCommError handle 0x4c cbInQue = 0 cbOutQue = 0

(this line is repeated many times, presumably while it waits for input)

trace:comm:ClearCommError handle 0x4c cbInQue = 8 cbOutQue = 0
trace:file:ReadFile 0x4c 0x41222a70 8 0x41222530 (nil)
trace:file:FILE_TimeoutRead 0x4c 0x41222a70 8 0x41222530
trace:file:FILE_ReadFileEx file 0x4c to buf 0x41222a70 num 8 0x41222488 func (nil)
trace:file:GetOverlappedResult (0x4c 0x41222488 0x41222530 1)
trace:file:GetOverlappedResult waiting on 0x41222488
trace:file:FILE_AsyncReadService 0x41222488 0x41222a70
trace:file:FILE_AsyncReadService read 8 more bytes 8/8 so far
trace:file:GetOverlappedResult wait on 0x41222488 returned 192
trace:file:GetOverlappedResult waiting on 0x41222488
trace:file:GetOverlappedResult wait on 0x41222488 returned 0

It then continues to do this several times, reading 8 or 16 bytes at a time from
the serial port.  There is then one more write/read exchange, then this:

trace:file:WriteFile 0x4c 0x40f01851 8 0x4122256c (nil)
trace:comm:ClearCommError handle 0x4c cbInQue = 0 cbOutQue = 0
trace:file:WriteFile 0x4c 0x40f01851 8 0x41222670 (nil)
trace:comm:ClearCommError handle 0x4c cbInQue = 0 cbOutQue = 0

This last line then repeats about 10,000 times before the program times out and
gives up on hearing anything.

I'm guessing that since it works slightly better with debugging enabled, that
there is a race condition at work here.  Maybe the last packet never actually
got written to the serial port, or a response came and Wine lost it.


------- Additional Comments From keldon <at> ont.com  2003-02-02 19:52 -------
I got this to work using an ugly patch (see attached).  The write buffer
of the serial port was getting overrun.  That caused the app to wait for
an ACK packet that was never going to come.

What I don't understand is why the call to write() doesn't block until
the buffer has drained.


------- Additional Comments From keldon <at> ont.com  2003-02-02 20:00 -------
Created an attachment (id=388)
 --> (http://bugs.winehq.com/attachment.cgi?id=388&action=view)
ugly hack to fix serial writes


------- Additional Comments From tony_lambregts <at> telusplanet.net 2003-02-06
16:30 -------
This is a wonderfull bug report. I am not sure why you think that it is not the
"right" fix. This is not my area though. Anyway If it solves your problem
I would like to se it go to wine patches. The following link gives you the
information on how to do this.

http://www.winehq.org/docs/wine-devel/patches.shtml

I would not want it to bit rot, and someone might want to come up with a better
solution if it is posted there.

BTW is there a demo or download version of this program.

-- 
Configure bugmail: http://bugs.winehq.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.