On Thu, Sep 17, 2009 at 11:55 AM, Dana H. Myers <dana.my...@sun.com> wrote: > Kerry Shu wrote: >> >> What you are looking for is 0x10, not 0x0a. Looks to me, here you have >> IRQ# 16 interrupt (might be either hci1394#0, uhci#3, uhci#0, or >> nvidia#0) preempting e1000g#0 interrupt. I guess such situation happened >> frequently since you felt system freeze. So are you running something >> that let both e1000g0 and other 4 driver instances at IRQ# 16 busy? For >> example, are you putting heavy load on both network and graphics? > > I don't understand what the VirtualBox/bridged-Ethernet configuration > does here, but one comment about xHCIs - they tend to interrupt > regularly at a reasonable rate, IIRC, even without a heavy > load. Graphics interrupts periodically but not that often, I > believe tied to vertical retrace/frame rate, which is 50-100 per > second.
Could it be possible that it's stuck in in the e1000g ISR and the IRQ 16 preemption is just a red herring? I'm not really familiar with the Opensolaris interrupt implementation, so I'm making some assumptions here (corrections are welcome) --- looking at the stack, I'm guessing the preemption by IRQ 16 starts at the _interrupt call. Since xHCIs interrupt regularly, if the e1000g ISR (or really the vboxfilt stream module sitting ontop of e1000g) is deadlocked on a mutex, isn't that what you'd see? I'm assuming the mutex call prior to _interrupt isn't part of the preemption process. _______________________________________________ driver-discuss mailing list driver-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/driver-discuss
