http://bugs.winehq.org/show_bug.cgi?id=9988
Summary: IOCTL_SERIAL_WAIT_ON_MASK does not always return correct answer Product: Wine Version: 0.9.46. Platform: Other OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: wine-misc AssignedTo: wine-bugs@winehq.org ReportedBy: tombrus@gmail.com
The io_control() function with IOCTL_SERIAL_WAIT_ON_MASK in dlls/ntdll/serial.c does not seem to always return the equivalent status as windows.
Unfortunately I only have an proprietary windows application (no source) that shows this. It is an application called FanControl shipped with a water cooling control unit from Innovatek (germany). The application controls the unit via an USB FTDI serial port. The application only works if there is such a device available. Rather difficult to reproduce on the average system :(.
The fix is to remove a few lines of code from the wait_on() function:
*events = check_events(fd, commio->evtmask, &commio->irq_info, &commio->irq_info, commio->mstat, commio->mstat); if (*events) goto out_now;
where the 'if' is the essential bit. The status returned to the caller will be zero when the check_events() returns something. This seems to confuse the windows application. When the above lines are taken out the returned code is always "STATUS_PENDING" and the handling through wait_for_event() will always return the right things to my windows application.
The code mentioned above looks like a shortcut to avoid starting a workitem with RtlQueueWorkItem(). My feeling is that this shortcut is not always valid.
I will attach a patch.
http://bugs.winehq.org/show_bug.cgi?id=9988
--- Comment #1 from Tom Brus tombrus@gmail.com 2007-10-11 07:47:08 --- Created an attachment (id=8510) --> (http://bugs.winehq.org/attachment.cgi?id=8510) patch for serial.c
http://bugs.winehq.org/show_bug.cgi?id=9988
--- Comment #2 from Tom Brus tombrus@gmail.com 2007-10-12 09:36:10 --- I have reasons to believe that the above fix is not a proper fix. I am investigating further, please do not act yet. Remarks are welcome though ;)
-Tom
http://bugs.winehq.org/show_bug.cgi?id=9988
--- Comment #3 from Tom Brus tombrus@gmail.com 2007-10-21 14:00:10 --- I got the sources of the windows application and have determined what is going wrong. Unfortunately I can not share the sources themselves for copyright reasons.
I pinpointed the problem to the WaitCommEvent() function (which does the IOCTL_SERIAL_WAIT_ON_MASK). I deduced that under windows this function will probably never return true. It always returns false with the GetLastError() being ERROR_IO_PENDING. This is at least seems to be true for the situation where the rcv and tx buffers are both empty and SetCommMask() is set to (EV_RXCHAR | EV_TXEMPTY).
In contrast the wine implementation returns true (because of the 'shortcut' discussed previously in this bug).
The following abbreviated code is based on the windows application code. I stripped some unimportant details:
for (;;) { ok = WaitCommEvent(...); if (ok) { if (chars_available_for_read==0) continue; } else { switch (GetLastError()) { case ERROR_IO_PENDING: break; default : report_error();break; } } switch (WaitForMultipleObjects(...)) { ... } }
This code runs fine on windows and hangs under wine. I traced it under wine and the following happens: WaitCommEvent() returns true because the tx buffer is empty; the chars_available_for_read is 0 so the for loop will start over. This will happen in an endless succession: a classic hang.
You can argue in several ways that this code can be improved but that is beside the point: it works under windows. You can also argue that wine's WaitCommEvent() works according to the manual, but that is again besides the point because wine should emulate windows, not its manual, right? ;)
On second evaluation the above fix and patch are correct. Could whoever is responsible please look at them and either discuss options or apply the patch. Thanks.
http://bugs.winehq.org/show_bug.cgi?id=9988
Juan Lang juan_lang@yahoo.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |juan_lang@yahoo.com
--- Comment #4 from Juan Lang juan_lang@yahoo.com 2007-12-06 13:36:29 --- You should try sending this to wine-patches for inclusion. If it isn't accepted, writing a test case that shows the behavior you're seeing (1) would go a long way toward getting it included.
(1) A test that shows WaitCommEvent returns FALSE (ERROR_IO_PENDING) when "the rx and tx buffers are empty and SetCommMask() is set to (EV_RXCHAR | EV_TXEMPTY)".
http://bugs.winehq.org/show_bug.cgi?id=9988
Damjan Jovanovic damjan.jov@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |damjan.jov@gmail.com
--- Comment #5 from Damjan Jovanovic damjan.jov@gmail.com 2007-12-07 05:02:11 --- Is this a dup of bug #9356?
http://bugs.winehq.org/show_bug.cgi?id=9988
--- Comment #6 from Juan Lang juan_lang@yahoo.com 2007-12-07 05:15:08 --- I don't think so. The ioctls are different, and the patch is different.
http://bugs.winehq.org/show_bug.cgi?id=9988
Vitaliy Margolen vitaliy@kievinfo.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Component|-unknown |ntdll
http://bugs.winehq.org/show_bug.cgi?id=9988
Dan Kegel dank@kegel.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |dank@kegel.com Keywords| |patch
http://bugs.winehq.org/show_bug.cgi?id=9988
Michael Karpukhin triada123@pochta.ru changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |triada123@pochta.ru
http://bugs.winehq.org/show_bug.cgi?id=9988
--- Comment #7 from Austin English austinenglish@gmail.com 2009-04-17 12:06:56 --- Is this still an issue in current (1.1.19 or newer) wine?
http://bugs.winehq.org/show_bug.cgi?id=9988
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |hardware
--- Comment #8 from Austin English austinenglish@gmail.com 2009-10-29 13:50:09 --- Is this still an issue in current (1.1.32 or newer) wine?
http://bugs.winehq.org/show_bug.cgi?id=9988
Tom Brus tombrus@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED Resolution| |INVALID
--- Comment #9 from Tom Brus tombrus@gmail.com 2009-10-30 03:23:52 --- I am currently not in the situation to try and reproduce this. I have set this one to RESOLVED-INVALID to keep your bugsbase clean. If I stumble upon it in the future, I will reopen or make a new bug.
http://bugs.winehq.org/show_bug.cgi?id=9988
Dmitry Timoshkov dmitry@codeweavers.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #10 from Dmitry Timoshkov dmitry@codeweavers.com 2009-10-30 03:25:22 --- Closing invalid.