kern/60662: bwi(4) livelocks the machine with an interrupt storm on BCM4309 (MAC rev 5, PHY type 2)

[" via gnats" <gnats-admin%NetBSD.org@localhost>]

>Number:         60662
>Category:       kern
>Synopsis:       bwi(4) generates a ~34k/sec interrupt storm on BCM4309, making the device unusable
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    kern-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Fri Aug 28 16:00:00 +0000 2026
>Originator:     <YOUR NAME>
>Release:        NetBSD 10.1 (GENERIC) #0: Mon Dec 16 13:08:11 UTC 2024
>Organization:
<YOUR ORGANIZATION>
>Environment:
System: NetBSD 10.1 NetBSD 10.1 (GENERIC) #0: Mon Dec 16 13:08:11 UTC 2024
	mkrepro%mkrepro.NetBSD.org@localhost:/usr/src/sys/arch/i386/compile/GENERIC
Architecture: i386
Machine: i386

Hardware: Dell Inspiron 8600 (Dell Computer Corporation), Intel 686-class,
Intel 82855PM chipset.

Wireless adapter: Broadcom BCM4309 Mini PCI (Dell TrueMobile 1400), listed
as supported in the bwi(4) HARDWARE section.

pcictl(8) reports:
	002:03:0: Broadcom BCM4309 (miscellaneous network, revision 0x03)

Relevant dmesg at attach:

	bwi0 at pci2 dev 3 function 0: Broadcom Wireless
	bwi0: interrupting at irq 9
	bwi0: BBP id 0x4306, BBP rev 0x3, BBP pkg 1
	bwi0: MAC: rev 5
	bwi0: PHY type 2, rev 2, ver 2
	bwi0: RF manu 0x17f, type 0x2050, rev 2

Firmware is the v3 set referenced by the bwi(4) man page, taken from
https://leaf.dragonflybsd.org/~sephe/bwi/v3.tbz and installed in
/libdata/firmware/bwi/v3.  It loads without complaint:

	bwi0: firmware rev 0x0127, patch level 0x000e

>Description:

Bringing bwi0 up causes an immediate, sustained interrupt storm on the
adapter's interrupt line.  The storm begins on the "up" transition itself,
before any scan, association or transmit is requested by userland.

Measured interrupt rate on the adapter's pin, sampled over 10 second
windows with vmstat -i:

	bwi0 down:      0 interrupts/sec
	bwi0 up:   33,928 interrupts/sec

The storm accounts for roughly 99% of all interrupts on the machine and
drives the load average up on an otherwise idle system.

Because the line is storming, transmits are never completed and the
watchdog fires continuously:

	bwi0: autoconfiguration error: device timeout
	bwi0: autoconfiguration error: wait for TX ring(1) stable timed out

The practical result is that "ifconfig bwi0 list scan" always returns an
empty list: no probe request ever reaches the air, so no beacon is ever
received, and the interface can never associate.

Note on interrupt sharing.  On this machine bwi0 shares IRQ 9 with auich0:

	bwi0:   interrupting at irq 9
	auich0: interrupting at irq 9

Sharing is *not* the cause.  With bwi0 down the line measures exactly 0
interrupts/sec, i.e. auich0 contributes nothing, so bwi0 is effectively
alone on the line and still storms.  Moving the device to another pin
would only relocate the storm.

This is consistent with the interrupt handler failing to acknowledge or
clear the adapter's interrupt status on a level-triggered PCI line: the
handler declines the interrupt, the line remains asserted, and it
re-fires indefinitely.

The bwi(4) BUGS section documents that BCM4306 and BCM4309 "do not work
properly on channel 1, 2, and 3".  This report is a separate and more
fundamental problem: it is not channel dependent (see How-To-Repeat) and
occurs before any channel is ever used.

>How-To-Repeat:

On a BCM4309 (MAC rev 5, PHY type 2 rev 2) with the v3 firmware installed:

	# sysctl -n hw.bwi0.fw_version		# -> 3
	# vmstat -i | grep 'pin 9'		# note the counter
	# ifconfig bwi0 up
	# sleep 10
	# vmstat -i | grep 'pin 9'		# counter has advanced ~340,000

	# ifconfig bwi0 list scan
	(empty)

	# dmesg | tail
	bwi0: autoconfiguration error: device timeout

Bringing the interface back down stops the storm immediately and the
counter stops advancing.

The failure is invariant to configuration.  I swept the following, with
a full down/up chip reset between each, two scan attempts per
configuration.  Every single one returned 0 access points and the same
number of device timeouts:

	baseline (broadcast scan, all channels)
	forced 11b mode                    (ifconfig bwi0 media autoselect mode 11b)
	pinned to channel 6                (ifconfig bwi0 chan 6)
	pinned to channel 11
	pinned to channel 1
	hw.bwi0.dwell_time=500
	hw.bwi0.txpwr_calib=0
	11b + channel 6 + txpwr_calib=0

In particular, pinning to channel 6 or 11 - the documented workaround for
the channel 1-3 defect - makes no difference whatsoever, which is what
distinguishes this from the known BUGS entry.

>Fix:

Not known.  I am not able to supply a patch.

The evidence points at the interrupt path in sys/dev/pci/if_bwi_pci.c /
sys/dev/ic/bwi.c rather than at the radio: the storm starts on the "up"
transition, is independent of channel, mode and tunables, and disappears
the instant the interface is brought down.

A useful first step for someone with the hardware would be to confirm
whether bwi_intr() correctly reads and acknowledges the interrupt status
register for MAC rev 5 / PHY type 2 parts, and whether it returns 0
("not mine") for an interrupt it has in fact caused.

Two suggestions, independent of the bug itself:

1. If this cannot be fixed, it would help users if the BUGS section of
   bwi(4) noted that some BCM4309 parts livelock the machine, so the
   failure is recognisable rather than being mistaken for missing
   firmware or a hardware fault.

2. bwi(4) FILES points at an off-site tarball for firmware, and there is
   no pkgsrc package for it (unlike iwn-firmware, wpi-firmware, etc).
   A bwi-firmware package would make this driver considerably easier to
   set up, and would avoid depending on a single third-party URL that has
   been the only source for many years.

>Unformatted: