On Wednesday 28 August 2013 12:41:00 Dmitry Timoshkov wrote: > Dmitry Timoshkov <dmi...@baikal.ru> wrote: > > Alexandre Julliard <julli...@winehq.org> wrote: > > > It doesn't work here: > > > > > > ../../../tools/runtest -q -P wine -M kernel32.dll -T ../../.. -p > > > kernel32_test.exe.so comm.c && touch comm.ok comm.c:835: Test failed: > > > WriteFile took 1 ms to write 17 Bytes at 150 Baud comm.c:848: Test > > > failed: WaitCommEvent failed with a timeout > > > comm.c:859: Test failed: WaitCommEvent error 997 > > > comm.c:860: Test failed: WaitCommEvent: expected EV_TXEMPTY, got 0 > > > comm.c:865: Test failed: WaitCommEvent used 1000 ms for waiting > > > comm.c:1895: Tests skipped: interactive tests (set > > > WINETEST_INTERACTIVE=1) > > > make: *** [comm.ok] Error 5 > > > > I assume it's a real hardware and not a VM? Is this with a real COM port, > > or USB-serial cable? If the latter one what driver is it using? > > Looking at the failure messages above once again, I can say that WriteFile > failure is definitely not caused by this patch. Does running the test > several times cause the same failures? In any case it would be interesting > to see the +comm log with "ntdll: Add a trace for transmitter's buffer > empty flag." applied. > > And current logic of setting the empty buffer flag is really broken, it > always sets the flag to a not zero value if ioctl(TIOCOUTQ) succeeds.
Yes, but this should be no problem for the test. If you only have TIOCOUTQ it is very difficult to do otherwise. You would have to monitor any write to the serial port by any thread. The applications I know write something and then wait, so the imperfect emulation we have now is enough. Regards, -- Wolfgang Walter Studentenwerk München Anstalt des öffentlichen Recht Abteilungsleiter IT Leopoldstraße 15 80802 München
