ntdll: Perform the offset checks also for a serial device.
fgouget at free.fr
Thu Sep 26 09:54:30 CDT 2013
On Thu, 26 Sep 2013, Dmitry Timoshkov wrote:
> Obviously you need nothing to know about the test except that it works with
> a COM-port, so the only thing you'd need to investigate is the difference
> between VMs in COM-port setup,
There's none. All the VMs, wxppro, w7u, w7pro64, etc have the same
serial port configuration:
<target type='serial' port='0'/>
> and try to figure out why this test doesn't always pass. I have no no
> idea what kind of results you have in mind that I'd need to share.
* I'm talking about the tests you've done to make sure that this was not
a timing issue.
* I'm talking about the tests you've done to try to understand why these
tests are failing in the VM.
* I'm talking about the research into WineTest's past results that show
that this is the only machine where this error occurs.
But the thing is that this is not the only VM where these errors occur:
they also happen intermitently on the wxppro, wvistau64-64 and
Also it does not happen systematically on that w7pro64 VM as this result
However the only VMs showing this problem are the new testbot's QEmu/KVM
ones. So that leaves timing issues and QEmu bugs as the two
So do I read this test right?
* It sets up a COM device for transmitting at 150 bps, with no
parity and one stop bit so 10 bits per byte sent (1 start bit, 8 data
bits, 1 stop bit).
* It calls SetCommMask() so it is notified when the transmit
buffer is empty.
* Then it calls WriteFile to sends 17 bytes (16 characters plus the
trailing '\0'), which should take 1133ms (17 bytes * 10 bits/byte
/ 150 bits per second). Because this is an overlapped COM device it
should return immediately.
* It then calls WaitCommEvent() which should also return immediately
with ERROR_IO_PENDING owing to the overlapped COM device.
* Then it waits for WaitCommEvent() to signal the event within 1000ms.
* Finally it checks that this all took less that 900ms.
So the first bug is that WaitCommEvent() succeeds which means the COM
device is either not overlapped, or that somehow all the bits got sent
The second issue is that this all took 1014ms. This actually makes sense
since it's supposed to take at least 1133ms. So it just timed out. It's
the test I don't understand. Same thing for the check that this takes
less than 900ms.
I ran the test manually with added traces and there are cases where
this took much less than 1000ms. I suspect baud rate emulation is broken
or unreliable in QEmu. This is also comforted by:
On the host's /dev/pts/x device I systematically see a 38400bps speed.
If that's what QEmu uses it could explain the failures, at least some of
the time. So I should go back to trying to upgrade QEmu.
Note that I also got failures in that section of the code on my EeePC on
Windows XP. That's because it tests COM3 which is the Bluetooth device.
This probably does not allow changing the baud rate or setting to
overlapped. The test should really detect such situations and skip.
> Also I'd appreciate avoiding the wording like "please don't waste my
> time", otherwise it becomes pretty obvious that I should just reply to
> failure notifications in the testbot with simple "it's broken"
Oh! I was under the impression that was exactly what you were doing
> and stop wasting my time explaining why.
Saying 'That VM is broken, it works for me' is not an explanation of why
or how that VM is broken. Indeed you were wrong: it's not that specific
VM that's broken, it's either all the QEmu ones or the VM host. Sorry
for expecting better from you.
Francois Gouget <fgouget at free.fr> http://fgouget.free.fr/
Hell is empty and all the devils are here.
-- Wm. Shakespeare, "The Tempest"
More information about the wine-devel