ntdll: Perform the offset checks also for a serial device.

[Francois Gouget]

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:

    <serial type='pty'>
      <target port='0'/>
    </serial>
    <console type='pty'>
      <target type='serial' port='0'/>
    </console>


> 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 
w2008s64-64 VMs:
http://test.winehq.org/data/tests/kernel32:comm.html

Also it does not happen systematically on that w7pro64 VM as this result 
pair shows:
http://test.winehq.org/data/2413841ecb8c845591e0c8173cd22a724dd82bde/win7_newtb-w7pro64-32/kernel32:comm.html
http://test.winehq.org/data/2413841ecb8c845591e0c8173cd22a724dd82bde/win7_newtb-w7pro64-64/kernel32:comm.html

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

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

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:
http://comments.gmane.org/gmane.comp.emulators.qemu/215606

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


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