Re: ntdll: Perform the offset checks also for a serial device.
Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://newtestbot.winehq.org/JobDetails.pl?Key=2267 Your paranoid android. === w7pro64 (32 bit comm) === comm.c:863: Test failed: WaitCommEvent failed with a timeout comm.c:875: recovering after WAIT_TIMEOUT... comm.c:886: Test failed: WaitCommEvent error 0 comm.c:888: Test failed: WaitCommEvent: expected EV_TXEMPTY, got 0 comm.c:892: WaitCommEvent for EV_TXEMPTY took 1014 ms (timeout 1000) comm.c:894: Test failed: WaitCommEvent used 1014 ms for waiting comm.c:1561: test_AbortWaitCts timeout 500 handle 000000F8 comm.c:1528: Changing CommMask on the fly for handle 000000F8 after timeout 500
Marvin <testbot(a)winehq.org> wrote:
=== w7pro64 (32 bit comm) === comm.c:863: Test failed: WaitCommEvent failed with a timeout comm.c:875: recovering after WAIT_TIMEOUT... comm.c:886: Test failed: WaitCommEvent error 0 comm.c:888: Test failed: WaitCommEvent: expected EV_TXEMPTY, got 0 comm.c:892: WaitCommEvent for EV_TXEMPTY took 1014 ms (timeout 1000) comm.c:894: Test failed: WaitCommEvent used 1014 ms for waiting comm.c:1561: test_AbortWaitCts timeout 500 handle 000000F8 comm.c:1528: Changing CommMask on the fly for handle 000000F8 after timeout 500
This VM is broken, my working computer runs Windows 7 Pro 64-bit on real hardware, and I run both 32-bit and 64-bit tests with and without serial devices powered on. -- Dmitry.
Dmitry Timoshkov <dmitry(a)baikal.ru> wrote:
Marvin <testbot(a)winehq.org> wrote:
=== w7pro64 (32 bit comm) === comm.c:863: Test failed: WaitCommEvent failed with a timeout comm.c:875: recovering after WAIT_TIMEOUT... comm.c:886: Test failed: WaitCommEvent error 0 comm.c:888: Test failed: WaitCommEvent: expected EV_TXEMPTY, got 0 comm.c:892: WaitCommEvent for EV_TXEMPTY took 1014 ms (timeout 1000) comm.c:894: Test failed: WaitCommEvent used 1014 ms for waiting comm.c:1561: test_AbortWaitCts timeout 500 handle 000000F8 comm.c:1528: Changing CommMask on the fly for handle 000000F8 after timeout 500
This VM is broken, my working computer runs Windows 7 Pro 64-bit on real hardware, and I run both 32-bit and 64-bit tests with and without serial devices powered on.
Besides these are existing tests. -- Dmitry.
On Tue, 24 Sep 2013, Dmitry Timoshkov wrote:
Marvin <testbot(a)winehq.org> wrote:
=== w7pro64 (32 bit comm) === comm.c:863: Test failed: WaitCommEvent failed with a timeout comm.c:875: recovering after WAIT_TIMEOUT... comm.c:886: Test failed: WaitCommEvent error 0 comm.c:888: Test failed: WaitCommEvent: expected EV_TXEMPTY, got 0 comm.c:892: WaitCommEvent for EV_TXEMPTY took 1014 ms (timeout 1000) comm.c:894: Test failed: WaitCommEvent used 1014 ms for waiting comm.c:1561: test_AbortWaitCts timeout 500 handle 000000F8 comm.c:1528: Changing CommMask on the fly for handle 000000F8 after timeout 500
This VM is broken,
How so? That is: what should I do to fix it? -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ Linux: It is now safe to turn on your computer.
Francois Gouget <fgouget(a)free.fr> wrote:
=== w7pro64 (32 bit comm) === comm.c:863: Test failed: WaitCommEvent failed with a timeout comm.c:875: recovering after WAIT_TIMEOUT... comm.c:886: Test failed: WaitCommEvent error 0 comm.c:888: Test failed: WaitCommEvent: expected EV_TXEMPTY, got 0 comm.c:892: WaitCommEvent for EV_TXEMPTY took 1014 ms (timeout 1000) comm.c:894: Test failed: WaitCommEvent used 1014 ms for waiting comm.c:1561: test_AbortWaitCts timeout 500 handle 000000F8 comm.c:1528: Changing CommMask on the fly for handle 000000F8 after timeout 500
This VM is broken,
How so? That is: what should I do to fix it?
Investigate, find the source of failures and fix it? Note, that all other VMs pass this test just fine, moreover, this same w7pro64 VM doesn't always fail. -- Dmitry.
On Thu, 26 Sep 2013, Dmitry Timoshkov wrote: [...]
This VM is broken,
How so? That is: what should I do to fix it?
Investigate, find the source of failures and fix it? Note, that all other VMs pass this test just fine, moreover, this same w7pro64 VM doesn't always fail.
You obviously know more about this API and that test than I do. Further, before claiming the VM is broken I'm sure you have positively determined that the successes you had on your boxes were not just due to luck but that something really is wrong with the VM. So please don't waste my time, at least share your results. -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ Avoid the Gates of Hell - use Linux.
Francois Gouget <fgouget(a)free.fr> wrote:
This VM is broken,
How so? That is: what should I do to fix it?
Investigate, find the source of failures and fix it? Note, that all other VMs pass this test just fine, moreover, this same w7pro64 VM doesn't always fail.
You obviously know more about this API and that test than I do. Further, before claiming the VM is broken I'm sure you have positively determined that the successes you had on your boxes were not just due to luck but that something really is wrong with the VM. So please don't waste my time, at least share your results.
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, 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. 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" and stop wasting my time explaining why. -- Dmitry.
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. -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ Hell is empty and all the devils are here. -- Wm. Shakespeare, "The Tempest"
participants (3)
-
Dmitry Timoshkov -
Francois Gouget -
Marvin