On Thu 24 Jan 2019 07:07:47 PM CET, Eric Blake wrote: >>>> 093 and 136 seem really flaky to me. I can reproduce that by >>>> running: >>> >>> That's interesting, I can make 093 fail quite easily now (I haven't >>> tested the other one yet), but I don't think this happened >>> earlier. I'll try to figure out what's going on. >> >> I bisected this and it seems that 093 started to fail after this: >> >> 8258292e monitor: Remove "x-oob", offer capability "oob" unconditionally >> >> I'm not familiar with that option so I need to investigate. > > We've got several tests failing after making x-oob unconditional; here's > another thread: > > https://lists.gnu.org/archive/html/qemu-devel/2019-01/msg05587.html > > Could it be that the test was using some sort of QMP command as an > attempt to synchronize state, but the OOB handling is now making it not > a reliable sync point?
093 submits several I/O requests using aio_read and aio_write with hmp_qemu_io(), then advances the clock using clock_step and finally calls query-blockstats to see how much of the I/O has been completed (it's an I/O throttling test). The expectation is that by the time query-blockstats is called all submitted I/O requests have been processed (up to the amount allowed by the throttling limits). Are the QMP (hmp_qemu_io, query-blockstats) and qtest (clock_step) sockets maybe running in different threads? Berto
