On Tue, Jan 19, 2016 at 10:13 AM, Gerd Hoffmann <kra...@redhat.com> wrote: > On Di, 2016-01-19 at 02:49 +0300, Andrey Korolyov wrote: >> On Mon, Jan 18, 2016 at 4:55 PM, Gerd Hoffmann <kra...@redhat.com> 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.
