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). -- Greetings Michael. _______________________________________________ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de http://bat.berlios.de/mailman/listinfo/bcm43xx-dev
