On Sat, 2006-11-18 at 06:24 -0500, Joseph Fannin wrote: > This sounds like what my laptop was doing in -rc5, though mine > didn't take hours to start acting up. > > I *think* it was the MSI troubles, causing interrupts to get > lost forever. Anyway, it went away in -rc6. Hah, that's a lot more plausible than bcm43xx's drain patch actually causing this. So maybe somehow interrupts for bcm43xx aren't routed properly or something... Ray, please check /proc/interrupts when this happens. I am convinced that the patch in question (drain tx status) is not causing this -- the patch should be a no-op in most cases anyway, and in those cases where it isn't a no-op it'll run only once at card init and remove some things from a hardware-internal FIFO. johannes
Attachment:
signature.asc
Description: This is a digitally signed message part
- Follow-Ups:
- Re: bcm43xx regression 2.6.19rc3 -> rc5, rtnl_lock trouble?
- From: Larry Finger <[email protected]>
- Re: bcm43xx regression 2.6.19rc3 -> rc5, rtnl_lock trouble?
- References:
- bcm43xx regression 2.6.19rc3 -> rc5, rtnl_lock trouble?
- From: Ray Lee <[email protected]>
- Re: bcm43xx regression 2.6.19rc3 -> rc5, rtnl_lock trouble?
- From: [email protected] (Joseph Fannin)
- bcm43xx regression 2.6.19rc3 -> rc5, rtnl_lock trouble?
- Prev by Date: 2.6.19-rc6-rt4, changed yum repository
- Next by Date: Re: bcm43xx regression 2.6.19rc3 -> rc5, rtnl_lock trouble?
- Previous by thread: Re: bcm43xx regression 2.6.19rc3 -> rc5, rtnl_lock trouble?
- Next by thread: Re: bcm43xx regression 2.6.19rc3 -> rc5, rtnl_lock trouble?
- Index(es):