All of lore.kernel.org
 help / color / mirror / Atom feed
From: Gerd Hoffmann <kraxel@redhat.com>
To: Andrey Korolyov <andrey@xdel.ru>
Cc: Kevin Wolf <kwolf@redhat.com>,
	hdegoede@redhat.com,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>
Subject: Re: [Qemu-devel] usb-storage assertions
Date: Tue, 12 Jan 2016 15:17:39 +0100	[thread overview]
Message-ID: <1452608259.29014.26.camel@redhat.com> (raw)
In-Reply-To: <CABYiri-wpdNGBrUnHKf22d13iXGg5YzyJrwMSHu5G5WTGz-5Tw@mail.gmail.com>

On Sa, 2016-01-09 at 20:34 +0300, Andrey Korolyov wrote:
> Hello,
> 
> during regular operations within linux guest with USB EHCI frontend I
> am seeing process crashes with an assert during regular operations
> like dpkg install:
> 
> hw/usb/dev-storage.c:334: usb_msd_handle_reset: Assertion `s->req ==
> ((void *)0)' failed.
> 
> This does happen when real block backend is an USB-attached device
> itself, so we are hitting some subtle race right there, because a
> single change of a backend to a raw file sitting on SSD has never
> triggered this block with the linux guest (but xBSD pre-reboot flush
> would trigger assertion from time to time in the usb_cancel_packet()
> without regarding physical backend type:
> 
> hw/usb/core.c:508: usb_cancel_packet: Assertion
> `usb_packet_is_inflight(p)' failed.
> )
> 
> Since the 2.2.0 which I am running is not exactly freshest one, I
> could re-check with master today or tomorrow, but log for hw/usb/ has
> no related commits for intentional fixes over one or another issue.

Checking would be nice, but I likewise don't expect things being
different on 2.5.

Most likely these are bugs in rarely taken code paths, probably because
the guest cancels requests and/or resets device due to timeouts (which
in turn are triggered by slow backing storage on the host).

Any chance you can rebuild qemu with DEBUG_MSD enabled (in
hw/usb/dev-storage.c), then trigger the asserts again, so we hopefully
get a useful trail of the events triggering the bugs?

Kevin, is is possible to limit transfer rates for block devices, to
simplify debugging stuff like this?  Preferably in a way supported by
libvirt?

thanks,
  Gerd

  reply	other threads:[~2016-01-12 14:17 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-01-09 17:34 [Qemu-devel] usb-storage assertions Andrey Korolyov
2016-01-12 14:17 ` Gerd Hoffmann [this message]
2016-01-12 14:36   ` Kevin Wolf
2016-01-12 14:56     ` Daniel P. Berrange
2016-01-13 16:13       ` Gerd Hoffmann
2016-01-13 16:28         ` Andrey Korolyov
2016-01-15 18:08           ` Andrey Korolyov
2016-01-18  9:38             ` Gerd Hoffmann
2016-01-18  9:50               ` Andrey Korolyov
2016-01-18 13:55                 ` Gerd Hoffmann
2016-01-18 23:49                   ` Andrey Korolyov
2016-01-19  7:13                     ` Gerd Hoffmann
2016-01-19 10:59                       ` Andrey Korolyov
2016-01-19 11:44                         ` Gerd Hoffmann
2016-01-19 14:19                     ` Gerd Hoffmann

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=1452608259.29014.26.camel@redhat.com \
    --to=kraxel@redhat.com \
    --cc=andrey@xdel.ru \
    --cc=hdegoede@redhat.com \
    --cc=kwolf@redhat.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.