qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: John Snow <jsnow@redhat.com>
To: "Marc Marí" <marc.mari.barcelo@gmail.com>
Cc: qemu-devel <qemu-devel@nongnu.org>
Subject: Re: [Qemu-devel] virtio-blk-test failure
Date: Mon, 23 Feb 2015 17:37:28 -0500	[thread overview]
Message-ID: <54EBABA8.3050908@redhat.com> (raw)
In-Reply-To: <20150223233530.32ef6bcc@crunchbang>



On 02/23/2015 05:35 PM, Marc Marí wrote:
> El Mon, 23 Feb 2015 17:22:57 -0500
> John Snow <jsnow@redhat.com> escribió:
>> I've been seeing this failure pop up very occasionally and I can
>> usually get the test to pass again by just re-running, but every now
>> and again:
>>
>> GTESTER check-qtest-x86_64
>> blkdebug: Suspended request 'A'
>> blkdebug: Resuming request 'A'
>> main-loop: WARNING: I/O thread spun for 1000 iterations
>> main-loop: WARNING: I/O thread spun for 1000 iterations
>> **
>> ERROR:/home/bos/jhuston/src/qemu/tests/libqos/virtio.c:91:qvirtio_wait_queue_isr:
>> assertion failed: (g_get_monotonic_time() - start_time <= timeout_us)
>> GTester: last random seed: R02S3ba253e130ac76bbcb0bade0a2d54b2f
>> [vmxnet3][WR][vmxnet3_peer_has_vnet_hdr]: Peer has no virtio
>> extension. Task offloads will be emulated.
>> make: *** [check-qtest-x86_64] Error 1
>>
>>
>> I wrote a test loop that runs virtio-blk-test over and over again in
>> a loop and saw it fail after 137 runs.
>>
>> It looks like the culprit is /virtio/blk/pci/msix; if you run only
>> that test it could take anywhere from 20-250 runs before you see it
>> fail.
>>
>> I only did a little bit of debugging, but the QMP command that
>> immediately precedes the wait_config_isr call here appears to execute
>> successfully.
>>
>> Any hunches, Marc?
>
> This is very similar to the one that took back the virtio MMIO patch.
> And the reason is the same, although nobody reported it:
>
> test/libqos/virtio-pci.c:162
>
>      data = readl(dev->config_msix_addr);
>      writel(dev->config_msix_addr, 0);
>      return data == dev->config_msix_data;
>
> If my memory is correct, this write is acking the interrupt. But it is
> always acking, without checking first what was read. There might be a
> race condition there.
>
> Tomorrow I'll send a patch.
>
> Thanks
> Marc
>

Awesome, CC me on it and I will run tests, thanks!

--js

      reply	other threads:[~2015-02-23 22:37 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-02-23 22:22 [Qemu-devel] virtio-blk-test failure John Snow
2015-02-23 22:35 ` Marc Marí
2015-02-23 22:37   ` John Snow [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=54EBABA8.3050908@redhat.com \
    --to=jsnow@redhat.com \
    --cc=marc.mari.barcelo@gmail.com \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).