svn commit: r198659 - in stable/8/sys: .
contrib/dev/acpica contrib/pf dev/pci dev/usb/controller dev/xen/xenpci
avg at freebsd.org
Tue Nov 17 12:42:59 UTC 2009
on 17/11/2009 14:06 Florian Smeets said the following:
> On 10/30/09 12:25 AM, Andrew Thompson wrote:
>> Author: thompsa
>> Date: Thu Oct 29 23:25:52 2009
>> New Revision: 198659
>> URL: http://svn.freebsd.org/changeset/base/198659
>> MFC r198151
>> Workaround buggy BIOS code in USB regard. By doing the BIOS to OS
>> handover for
>> all host controllers at the same time, we avoid problems where the
>> BIOS will
>> actually write to the USB registers of all the USB host
>> controllers every time
>> we handover one of them, and consequently reset the OS programmed
> this commit causes some of my servers (all of the same type), to detect
> interrupt storms on irq11:
> interrupt storm detected on "irq11:"; throttling interrupt source
> and it does not stop logging these.
> flo at relay3:~ 6 > vmstat -i
> interrupt total rate
> irq0: clk 229846 990
> irq4: uart0 596 2
> irq5: sis0 2850 12
> irq8: rtc 29595 127
> irq11: sis3 115799 499
> irq14: ata0 2071 8
> Total 380757 1641
> sis3 is not used and not even up.
> Setting sysctl hw.intr_storm_threshold to high values e.g. 10000 does
> not help.
> The kernels on these servers do not have usb compiled in at all, but
> it's enabled in the BIOS.
> Setting hw.pci.usb_early_takeover=0 "fixes" the problem.
> Is this expected?
This is not expected in a sense that nobody planned to introduce interrupt storms.
But it is possible, because this is one of the edge cases introduced by the
commit in question, and the tunable is there exactly to deal with the edge cases.
What might be happening here is that your USB controller(s) is configured with
interrupt 11, but you don't see it in vmstat -i output, because there is no USB
driver to discover the hardware and its configuration. If we take over the
controllers, BIOS no longer controls the devices and it is expected that the OS
would do it, but it doesn't. So if interrupts are generated by USB hardware they
remain unhandled and cause the storm.
Thus, there are 3 choices:
1. what you have already done (and it does fix the problem, no quote-unquote needed);
2. add USB drivers, so that USB interrupts are handled;
3. disable USB in BIOS.
Depending on your goals one choice may suite better than the others.
Does this make sense?
More information about the svn-src-stable-8