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: Tue, 19 Jan 2016 13:59:29 +0300

On Tue, Jan 19, 2016 at 10:13 AM, Gerd Hoffmann <address@hidden> wrote:
> On Di, 2016-01-19 at 02:49 +0300, Andrey Korolyov wrote:
>> On Mon, Jan 18, 2016 at 4:55 PM, Gerd Hoffmann <address@hidden> wrote:
>> >   Hi,
>> >
>> >> > 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.
>> >
>> > 7.0 trace:
>>
>> Whoops, sorry, should be 5.1/i386.
>
> I'll check that too ...
>
>>  On a 7.0 I observe same endless
>> loop as you do.
>
> ... just wanted to start with that one.
>
> [ trace snipped ]
>
>> > So, to shutdown ehci netbsd clears the cmd register, then sets the reset
>> > bit in the cmd register.  Fine.
>> >
>> > Then it goes read the status register, in a loop, forever.  No idea why,
>> > and I also can't spot then place in the source code.  Hmm ...
>
> /me was hoping anyone has an idea what is going on here.
> Are you familiar with the netbsd kernel sources?
>

Probably not enough with driver subsystem to point even at the obvious
issue in the EHCI driver. I`d start with slowing down an emulated CPU
10...100 times via its thread cg, leaving emulator code hanging with
enough CPU cycles and check if the issue is still here. If roots of
the crash or endless loop are timing-related, they either would change
appearance significanly or disappear completely (or vice versa, slow
an emulator thread). If you don`t have enough time for such blind
testing, I may check it in a next few days. Since I`ve seen interrupt
storm complaint on FreeBSD within same conditions, I strongly prefer
the idea of a race-driven behavior.



reply via email to

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