On Monday 04 September 2006 21:55, Peter Osterlund wrote: > Michael Buesch <[EMAIL PROTECTED]> writes: > > > On Monday 04 September 2006 05:09, Larry Finger wrote: > > > Emanuele Giaquinta wrote: > > > > 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 > > > > > > This sounds as if there may be a deadlock when a restart occurs. Do you > > > have the lock debugging > > > options set in your configuration? I used to get the NETDEV WATCHDOG > > > timeouts, but the recent > > > wireless-2.6 changes appear to have fixed them. > > > > Yes, Emanuele. Please try with: > > * Latest wireless-2.6 > > * and most Kernel Hacking options enabled > > * and most important, with bcm43xx debugging enabled. > > Unfortunately, it doesn't help on my computer. With current > wireless-2.6 tree, I see the same behavior as I reported before, ie > "transmit timed out", followed by "controller RESET" and ksoftirqd > using 100% CPU.
I still think you don't have bcm43xx debugging enabled, or you don't post all debug messages here. Please do so, otherwise we can't help. Please provide full dmesg. -- Greetings Michael. _______________________________________________ Bcm43xx-dev mailing list [email protected] https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
