Peter Osterlund wrote: > Peter Osterlund <[EMAIL PROTECTED]> writes: > > > Michael Buesch <[EMAIL PROTECTED]> writes: > > > > > On Friday 04 August 2006 01:31, Peter Osterlund wrote: > > > > "Ivan Matveich" <[EMAIL PROTECTED]> writes: > > > > > > > > > [interface works fine for a few hours, then this spontaneously > > > > > happens] > > > > > [note: the computer does nothing but compile stuff, etc during this > > > > > time] > > > > > > > > > > NETDEV WATCHDOG: wireless: transmit timed out > > > > > bcm43xx: Controller RESET (TX timeout) ... > > > > > bcm43xx: select_wireless_core: cleanup > > > > > bcm43xx: Radio turned off > > > > > bcm43xx: DMA 0x0200 (RX) max used slots: 1/64 > > > > > bcm43xx: DMA 0x0260 (TX) max used slots: 0/512 > > > > > bcm43xx: DMA 0x0240 (TX) max used slots: 0/512 > > > > > bcm43xx: DMA 0x0220 (TX) max used slots: 70/512 > > > > > bcm43xx: DMA 0x0200 (TX) max used slots: 0/512 > > > > > bcm43xx: Radio turned on > > > > > bcm43xx: Chip initialized > > > > > bcm43xx: DMA initialized > > > > > bcm43xx: Keys cleared > > > > > bcm43xx: Selected 802.11 core (phytype 2) > > > > > bcm43xx: Controller restarted > > > > > > > > > > [now the interface stops working: pings no longer go through] > > > > > > > > I've seen this too and I also use a preemptable kernel. In my case the > > > > problem goes away if I increase BADNESS_LIMIT to 20 in bcm43xx_main.c. > > > > Therefore, my guess is that the new locking strategy isn't > > > > preempt-safe. (I haven't tested a non-preemptable kernel though.) > > > > > > That might be wrong guesswork. > ... > > > To verify: Does it also go away, if you stay away from BADNESS_LIMIT > > > and disable preemption? To do that, you must disable CONFIG_PREEMPT > > > and make the function bcm43xx_voluntary_preempt() in bcm43xx_phy.c > > > a NOP (return early). > > > > I just booted a linville wireless git tree kernel with these changes. > > Now I'll just have to wait a few hours to see what happens. > > This version also stopped working after about 2.5 hours of uptime. It > doesn't lock up the system, but instead ksoftirqd starts using 100% > CPU time, and the only way to stop that seems to be a reboot.
I can confirm the very same behaviour using a bcm4306 on linux-2.6.18-rc4 with the bcm43xx patches queued for 2.6.19 applied; when a hard reset occurs ksoftirqd begins using 100% CPU indefinitely, and in one case the controller restart failed: NETDEV WATCHDOG: eth1: transmit timed out bcm43xx: Controller RESET (TX timeout) ... bcm43xx: Controller restarted NETDEV WATCHDOG: eth1: transmit timed out bcm43xx: Controller RESET (TX timeout) ... bcm43xx: IRQ_READY timeout bcm43xx: Controller restart failed NETDEV WATCHDOG: eth1: transmit timed out bcm43xx: Controller RESET (TX timeout) ... bcm43xx: IRQ_READY timeout bcm43xx: Controller restart failed Trying to free already-free IRQ 52 -- Emanuele Giaquinta _______________________________________________ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
