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_ne... http://test.winehq.org/data/2413841ecb8c845591e0c8173cd22a724dd82bde/win7_ne...
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.