Hi,
> Whoops, sorry, should be 5.1/i386. On a 7.0 I observe same endless
> loop as you do.
Any chance the irq storm fix helps on 5.1 guests too?
I've installed 5.1.6 on a (virtual) usb-stick hooked up via ehci.
Works fine here, rebooted multiple times without any problems.
cheers,
Gerd
Hi,
> 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
On Tue, Jan 19, 2016 at 10:13 AM, Gerd Hoffmann wrote:
> On Di, 2016-01-19 at 02:49 +0300, Andrey Korolyov wrote:
>> On Mon, Jan 18, 2016 at 4:55 PM, Gerd Hoffmann wrote:
>> > Hi,
>> >
>> >> > ok. Had no trouble with freebsd, will go fetch netbsd images. What
>> >> > arch is this? i386? x86
On Di, 2016-01-19 at 02:49 +0300, Andrey Korolyov wrote:
> On Mon, Jan 18, 2016 at 4:55 PM, Gerd Hoffmann 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 th
On Mon, Jan 18, 2016 at 4:55 PM, Gerd Hoffmann 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
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:
[ ... ]
12417@1453119296.506252:usb_ehci_opreg_write wr mmio 0020 [USBCMD] = 0
12417@1
On Mon, Jan 18, 2016 at 12:38 PM, Gerd Hoffmann 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 i
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
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), NetBSD
7.0 reboot action hangs on USB_RESET and NetBSD 5.1 triggers second of
mentioned asserts. Backend i
On Wed, Jan 13, 2016 at 7:13 PM, Gerd Hoffmann wrote:
> On Di, 2016-01-12 at 14:56 +, Daniel P. Berrange wrote:
>> On Tue, Jan 12, 2016 at 03:36:40PM +0100, Kevin Wolf wrote:
>> > Am 12.01.2016 um 15:17 hat Gerd Hoffmann geschrieben:
>> > > On Sa, 2016-01-09 at 20:34 +0300, Andrey Korolyov wro
On Di, 2016-01-12 at 14:56 +, Daniel P. Berrange wrote:
> On Tue, Jan 12, 2016 at 03:36:40PM +0100, Kevin Wolf wrote:
> > Am 12.01.2016 um 15:17 hat Gerd Hoffmann geschrieben:
> > > On Sa, 2016-01-09 at 20:34 +0300, Andrey Korolyov wrote:
> > > > Hello,
> > > >
> > > > during regular operation
On Tue, Jan 12, 2016 at 03:36:40PM +0100, Kevin Wolf wrote:
> Am 12.01.2016 um 15:17 hat Gerd Hoffmann geschrieben:
> > 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 cr
Am 12.01.2016 um 15:17 hat Gerd Hoffmann geschrieben:
> 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:
>
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->r
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
15 matches
Mail list logo