qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] usb-storage assertions


From: Andrey Korolyov
Subject: Re: [Qemu-devel] usb-storage assertions
Date: Mon, 18 Jan 2016 12:50:39 +0300

On Mon, Jan 18, 2016 at 12:38 PM, Gerd Hoffmann <address@hidden> wrote:
> On Fr, 2016-01-15 at 21:08 +0300, Andrey Korolyov wrote:
>> Just checked, Linux usb driver decided to lose a disk during a
>> 'stress-test' over unpacking linux source instead of triggering an
>> assertion in 2.5 (and to irreparably damage its ext4 as well),
>
> Ok, so behavior changed here from 2.2 -> 2.5.  I don't see disk
> corruption in my tests, but linux guest resets the usb-storage device
> now and then.  Seems to be able to resume operations though, there are
> no disk errors in the logs.

Thanks for checking, I`ve seen a couple of bus resets as well and
suddenly guest froze with 'fs remounted as ro' message splat over
physical console. Of course I didn`t set any external kernel logging
or pstore at a time and I could only assume that same timeouts was a
general cause of a corruption itself (more likely some inflights was
lucky enough to finish while others did not made it, but I don`t see a
way to corrupt a superblock *that bad*).

>
>> NetBSD
>> 7.0 reboot action hangs on USB_RESET and NetBSD 5.1 triggers second of
>> mentioned asserts. Backend itself is a regular USB2-SATA adapter with
>> Intel S3500 SSD, hence it should not trigger first timing-related
>> assertion at all.
>
> ok.  Had no trouble with freebsd, will go fetch netbsd images.  What
> arch is this?  i386?  x86_64?

i386 7.0 for the reference, but I`m sure that this wouldn`t matter in
any way. Just to mention - ancient 2.6, like 2.6.18, are actually
doing things quite faster using same frontend+backend combination, may
be due to lack of proper timeout checks... Actually there is a very
small chance that the real performance regression was introduced
during further development, so I instead believe in improper
interaction of a newer guest EHCI driver and qemu frontend. Please let
me know if any countable measurements like fio could be a matter of
interest - I don`t think that many people are concerned about USB/USB2
frontend performance at all, since they are bringing in a ton of
unwelcomed wakeups and the one thing which could be a matter of
concern in that case is an emulated xHCI, IMHO.

>
> cheers,
>   Gerd
>



reply via email to

[Prev in Thread] Current Thread [Next in Thread]