mlelstv@serpens.de (Michael van Elst) writes:

> tls@rek.tjls.com (Thor Lancelot Simon) writes:
>
>>One of the NetBSD Foundation servers is a dual-Opteron with an onboard
>>dual Broadcom gigabit chip.  This chip, as far as I can tell from some
>>experiments, gets seriously disturbed by the driver's tendency to
>>acknowledge interrupts even if they're not actually from the device.
>
> I believe something similar hits a Thinkpad T43 which is i386 and
> not amd64. Almost all peripherals take irq 11 and using the bge
> interface causes symptoms I correlate with bad interrupt handling.
> I.e. carrier status isn't recognized correctly, network traffic
> is slowed, USB misses disconnect events, DDB freezes when returning
> to a live kernel.
>
> bge0: interrupting at irq 11
> uhci0: interrupting at irq 11
> uhci1: interrupting at irq 11
> uhci2: interrupting at irq 11
> uhci3: interrupting at irq 11
> ehci0: interrupting at irq 11
> iwi0: interrupting at irq 11
> cbb0: interrupting at irq 11
> auich0: interrupting at irq 11
>
> I first suspected iwi to be at fault, but I guess this is just
> because it has activity on irq 11 when enabled.

My problem is similar and last week I suspected again of iwi, but it
doesn't seem so. This is an Acer laptop running NetBSD/i386:

hci0: interrupting at irq 11
uhci1: interrupting at irq 11
uhci2: interrupting at irq 11
uhci3: interrupting at irq 10
ehci0: interrupting at irq 11
fwohci0: interrupting at irq 11
iwi0: interrupting at irq 11
bge0: interrupting at irq 10
cbb0: interrupting at irq 11
piixide0: primary channel interrupting at irq 14

When I enable ioapic, iwi works, but the rest is a huge mess (usb
doesn't work, acpi events are not triggered, etc.)
When I disable ioapic, everything works except iwi (it halts the
system, possibly creating an interrupt storm).

-- 
  Rui Paulo			<rpaulo@{NetBSD{,-PT}.org,fnop.net}>