El Mon, 15 Sep 2014 14:47:41 -0700 Peter Maydell <peter.mayd...@linaro.org> escribió: > On 11 September 2014 02:40, Marc Marí <marc.mari.barc...@gmail.com> > wrote: > > Increase the clock step to avoid Travis failure in some builds due > > to overagressive timeout. > > > > Signed-off-by: Marc Marí <marc.mari.barc...@gmail.com> > > Unfortunately Travis is still failing with this: > > ERROR:tests/virtio-blk-test.c:209:pci_basic: assertion failed: > (qvirtio_wait_queue_isr(&qvirtio_pci, &dev->vdev, &vqpci->vq, > QVIRTIO_BLK_TIMEOUT)) > > GTester: last random seed: R02S490664995052f018e72f25518e90cb81 > > ** > > ERROR:tests/virtio-blk-test.c:578:pci_idx: assertion failed: > (qvirtio_wait_queue_isr(&qvirtio_pci, &dev->vdev, &vqpci->vq, > QVIRTIO_BLK_TIMEOUT)) > > GTester: last random seed: R02S5471c60ecfff4007d0adc9b0b7c265b6 > > thanks > -- PMM
This means agressive timeout is not the problem. The problem is the ISR not being raised at all after sending a read or write request. If this is the log of the failing case: https://travis-ci.org/qemu/qemu/builds/35118444 (first time looking at Travis logs, not sure) The difference between the one failing and the same arch not failing is: brlapi support yes, linux AIO support yes, uuid support yes, licap-ng support yes, virtio-blk-data-plane yes, vhdx yes (this configuration fails). The difference that is most likely to fail is virtio-blk-data-plane. So we should start looking there. Marc
