From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:43816) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XTeb4-00050k-OM for qemu-devel@nongnu.org; Mon, 15 Sep 2014 18:18:15 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XTeb0-0006fl-54 for qemu-devel@nongnu.org; Mon, 15 Sep 2014 18:18:10 -0400 Received: from mail-wi0-x233.google.com ([2a00:1450:400c:c05::233]:34179) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XTeaz-0006fH-V2 for qemu-devel@nongnu.org; Mon, 15 Sep 2014 18:18:06 -0400 Received: by mail-wi0-f179.google.com with SMTP id q5so3062638wiv.0 for ; Mon, 15 Sep 2014 15:18:01 -0700 (PDT) Date: Tue, 16 Sep 2014 00:17:57 +0200 From: Marc =?UTF-8?B?TWFyw60=?= Message-ID: <20140916001757.17427df3@crunchbang> In-Reply-To: References: <1410428416-5046-1-git-send-email-marc.mari.barcelo@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [TRIVIAL][PATCH v2] libqos virtio: Increase ISR timeout List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Maydell Cc: QEMU Developers , Stefan Hajnoczi El Mon, 15 Sep 2014 14:47:41 -0700 Peter Maydell escribi=C3=B3: > On 11 September 2014 02:40, Marc Mar=C3=AD > wrote: > > Increase the clock step to avoid Travis failure in some builds due > > to overagressive timeout. > > > > Signed-off-by: Marc Mar=C3=AD >=20 > Unfortunately Travis is still failing with this: >=20 > ERROR:tests/virtio-blk-test.c:209:pci_basic: assertion failed: > (qvirtio_wait_queue_isr(&qvirtio_pci, &dev->vdev, &vqpci->vq, > QVIRTIO_BLK_TIMEOUT)) >=20 > GTester: last random seed: R02S490664995052f018e72f25518e90cb81 >=20 > ** >=20 > ERROR:tests/virtio-blk-test.c:578:pci_idx: assertion failed: > (qvirtio_wait_queue_isr(&qvirtio_pci, &dev->vdev, &vqpci->vq, > QVIRTIO_BLK_TIMEOUT)) >=20 > GTester: last random seed: R02S5471c60ecfff4007d0adc9b0b7c265b6 >=20 > 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