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.

-- 
Peter Osterlund - [EMAIL PROTECTED]
http://web.telia.com/~u89404340
_______________________________________________
Bcm43xx-dev mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev

Reply via email to