No -- just running virtual box w/ gnome loaded. Within virtualbox, I was merely installing some software in an win7 vm.
On Thu, Sep 17, 2009 at 11:45 AM, Kerry Shu <[email protected]> wrote: > > > Jason King wrote: >> >> On Thu, Sep 17, 2009 at 10:16 AM, Garrett D'Amore <[email protected]> wrote: >>> >>> Look closely at the stack. You'll notice that a PIL9 interrupt >>> *interrupted* e1000g while it was servicing an interrupt. I don't think >>> e1000g is at fault here. Something else is doing it. >> >> This is probably my lack of knowledge about how solaris handles >> interrupts, but with doing a little digging: >> >>> 0xffffff0007c49c60::findstack -v >> >> stack pointer for thread ffffff0007c49c60: ffffff0007c49b30 >> ffffff0007c49bb0 rm_isr+0xaa() >> ffffff0007c49c00 av_dispatch_autovect+0x7c(10) >> ffffff0007c49c40 dispatch_hardint+0x33(10, 6) >> ffffff0007c4f450 switch_sp_and_call+0x13() >> ffffff0007c4f4a0 do_interrupt+0x9e(ffffff0007c4f4b0, b) >> ffffff0007c4f4b0 _interrupt+0xba() >> >> I'm assuming this portion of the stack dump is what you're talking >> about... looking at the function signature for dispatch_hardint -- the >> new vector is 10, and the old ipl is 6. >> >>> ::interrupts -d >> >> IRQ Vect IPL Bus Trg Type CPU Share APIC/INT# Driver Name(s) >> 3 0xb1 12 ISA Edg Fixed 0 1 0x0/0x3 asy#1 >> 4 0xb0 12 ISA Edg Fixed 0 1 0x0/0x4 asy#0 >> 6 0x41 5 ISA Edg Fixed 0 1 0x0/0x6 fdc#0 >> 7 0x42 5 ISA Edg Fixed 1 1 0x0/0x7 ecpp#0 >> 9 0x81 9 PCI Lvl Fixed 1 1 0x0/0x9 acpi_wrapper_isr >> 15 0x43 5 ISA Edg Fixed 0 1 0x0/0xf ata#1 >> 16 0x83 9 PCI Lvl Fixed 1 4 0x0/0x10 hci1394#0, uhci#3, >> uhci#0, >> nvidia#0 >> 17 0x87 8 PCI Lvl Fixed 0 1 0x0/0x11 audio810#0 >> 18 0x86 9 PCI Lvl Fixed 1 1 0x0/0x12 pci-ide#1 >> 19 0x85 9 PCI Lvl Fixed 0 1 0x0/0x13 uhci#1 >> 23 0x84 9 PCI Lvl Fixed 1 1 0x0/0x17 ehci#0 >> 26 0x40 5 PCI Lvl Fixed 1 1 0x1/0x2 aac#0 >> 48 0x60 6 PCI Lvl Fixed 1 1 0x2/0x0 e1000g#0 >> 72 0x82 7 PCI Edg MSI 0 1 - pcie_pci#0 >> 73 0x30 4 PCI Edg MSI 0 1 - pcie_pci#2 >> 74 0x44 5 PCI Edg MSI 0 1 - adpu320#0 >> 160 0xa0 0 Edg IPI all 0 - poke_cpu >> 192 0xc0 13 Edg IPI all 1 - xc_serv >> 208 0xd0 14 Edg IPI all 1 - kcpc_hw_overflow_intr >> 209 0xd1 14 Edg IPI all 1 - cbe_fire >> 210 0xd3 14 Edg IPI all 1 - cbe_fire >> 240 0xe0 15 Edg IPI all 1 - xc_serv >> 241 0xe1 15 Edg IPI all 1 - apic_error_intr >> >> That makes sense -- e1000g#0 is IPL 6, however shouldn't there then be >> an entry somewhere in there with a VECT value of 0x0a and an IPL of 9? >> Or do i still have more learning to do? >> > > 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? > > Regards, > Kerry > _______________________________________________ driver-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/driver-discuss
