tech-kern archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: Interrupt storm mitigation needed
Tom Ivar Helbekkmo <tih%hamartun.priv.no@localhost> writes:
> Your new wrapper doesn't grab the sc_intr_lock mutex, so it fails the
> KASSERT in uhci_intr1(). I'll add the enter and exit calls to the
> wrapper and try again -- after dinner. :)
I have it running, now, and the initial impression is that it works very
well. The machine is talking nicely with the UPS over the USB serial
interface, I've done a 'cvs update' of the NetBSD source tree, which
would normally cause a number of hangs, and I'm building a kernel as I'm
writing this. Absolutely no incidents so far.
The uhci pins on the ioapics are chalking up a few interrupts, but not
many, and no bursts. Here's a snapshot from a running 'vmstat -i 10':
interrupt total rate
cpu0 timer 121654 100
ioapic1 pin 14 183977 151
ioapic2 pin 0 136176 112
ioapic0 pin 16 10623 8
ioapic0 pin 18 16565 13
ioapic0 pin 23 28335 23
ioapic0 pin 14 11 0
ioapic0 pin 4 394 0
Total 497735 409
This is with an uptime of 21 minutes, and it's been quite active the
whole time. Oh, and the various interrupt lines are:
amr0: interrupting at ioapic1 pin 14
wm0: interrupting at ioapic2 pin 0
wm1: interrupting at ioapic2 pin 1
uhci0: interrupting at ioapic0 pin 16
uhci1: interrupting at ioapic0 pin 19
uhci2: interrupting at ioapic0 pin 18
ehci0: interrupting at ioapic0 pin 23
cmdide0: using ioapic0 pin 23 for native-PCI interrupt
piixide0: primary channel interrupting at ioapic0 pin 14
piixide0: secondary channel interrupting at ioapic0 pin 15
radeon0: interrupting at ioapic0 pin 18 (radeon)
I'll keep pushing it, and watching for events.
-tih
--
Popularity is the hallmark of mediocrity. --Niles Crane, "Frasier"
Home |
Main Index |
Thread Index |
Old Index