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 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.
Ha! That nailed it. /me was looking for a loop in the code, waiting for the device having finished reset or something like that. But it turned out to be a interrupt storm indeed. cheers, Gerd
