Pavel Roskin wrote: > Hello! > > Sorry, another look at the assert issue in bcm43xx has taken some time. > That's the complete kernel messages from the point where the driver is > inserted to the first assertion failure. --snip-- > bcm43xx: DMA-32 0x0200 (RX) max used slots: 1/64 > bcm43xx: DMA-32 0x02A0 (TX) max used slots: 0/512 > bcm43xx: ASSERTION FAILED (bcm43xx_status(bcm) == > BCM43xx_STAT_INITIALIZED) > at: > /home/proski/src/linux-2.6/drivers/net/wireless/bcm43xx/bcm43xx_main.c:1861:bcm43xx_interrupt_handler() > > I'm using the current mb tree plus the fixes to bring it up to date. > It turns out that the Broadcom card shares interrupts with a large number of > devices: > > # cat /proc/interrupts > CPU0 > 0: 1281260 XT-PIC-XT timer > 1: 10 XT-PIC-XT i8042 > 2: 0 XT-PIC-XT cascade > 4: 4855 XT-PIC-XT serial > 8: 1 XT-PIC-XT rtc > 9: 332 XT-PIC-XT acpi > 11: 271806 XT-PIC-XT yenta, yenta, uhci_hcd:usb1, > uhci_hcd:usb2, uhci_hcd:usb3, eth9, [EMAIL PROTECTED]:0000:01:00.0, bcm43xx > 12: 2337 XT-PIC-XT i8042 > 14: 25257 XT-PIC-XT ide0 > 15: 37722 XT-PIC-XT ide1 > NMI: 0 > ERR: 0
I think your analysis is correct. The reason I don't see these assertions is that my bcm43xx is alone on IRQ 19, and no other device comes through this path. I don't remember the details on my old computer, but I never saw these assertions. Probably, the interrupt was shared, but by less active devices. > It's not necessary to remove the module to trigger the assert messages. > All it takes it to bring the interface (eth0 in my case) up and down. > > Assertion failures always happen when bcm43xx_status(bcm) is > BCM43xx_STAT_SHUTTINGDOWN. Debugging shows that all of then are printed > after bcm43xx_shutdown_all_wireless_cores() sets the status and all the > way until free_irq() is called. bcm43xx_interrupt_disable() has not > effect. > > I believe it happens because bcm43xx_interrupt_handler() checks status > before it check whether the interrupt is even destined for us. I think > the wired ethernet (eth9) and the video card can generate quite a lot of > interrupts. Indeed, moving the assertion down eliminates all assertion > failures. > > It is possible that we still can get some assertion failures caused by > the interrupts for the card after BCM43xx_STAT_SHUTTINGDOWN is set and > before bcm43xx_interrupt_disable() is called. It tried to reproduce it > by bringing the interface down during flood ping. I don't see assertion > failures, but I don't see any reasons why they cannot happen (I hope I'm > not seeing the obvious). My observation is that they do not occur, but I have not done a thorough analysis. > bcm43xx_d80211 is not affected because it doesn't have the > BCM43xx_STAT_SHUTTINGDOWN state. I think the bcm43xx driver could avoid > it too if bcm43xx_shutdown_all_wireless_cores() ensured first that it's > not interrupted by anything that could access the card hardware. > > I'm surprised that bcm43xx_wireless_core_reset() has a reference to > BCM43xx_STAT_SHUTTINGDOWN. I just don't see how that function could be > called in that state. > > Here's my patch, and I'm even signing it off in case it actually turns > out to be good. I'm testing it now and will send it upstream unless someone objects. Thanks for the effort in chasing this down. Larry _______________________________________________ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
