Re: bcm43xx regression 2.6.19rc3 -> rc5, rtnl_lock trouble?

[Larry Finger <Larry.Finger-tQ5ms3gMjBLk1uMJSBkQmQ@public.gmane.org>]

Ray Lee wrote:
> First off, thanks for all your help.
> 
> Second off,
> 
> On 11/16/06, Larry Finger <Larry.Finger-tQ5ms3gMjBLk1uMJSBkQmQ@public.gmane.org> wrote:
>> Ray Lee wrote:
>> >
>> > If I could figure out a way to make it repeatable, I'd happily do a 
>> blind
>> > bisect.
> [...]
>> > I'm open to suggestions on how to make the problem trigger more than 
>> once
>> > every two days...
>>
>> I don't know what might be causing the lock problems. I'm more 
>> concerned with the NETDEV WATCHDOG
>> timeouts. AFAIK, you are the only one still reporting this error. On 
>> my system, I get an occasional
>> MAC suspend failure, sometimes followed by an BCM43xx_IRQ_XMIT_ERROR.
> 
> Last time I had trouble with 2.6.18-rcX, I wasn't the only one, just
> the only one reporting it. Can you tell me why reverting the likely
> culprit isn't an option? rc6 is out, and Linus is really pushing to
> finalize 2.6.19 here soon.
> 
>>  From what I read in your post, the timeouts happen a lot more often 
>> than once every two days. Once
>> we get those fixed, then we can concentrate on the locking.
> 
> It's becoming clear that I wasn't so clear :-). No, it doesn't happen
> more than once every two (three, now) days. I'm saying that it's only
> happened twice, as once the first timeout message starts, the timeouts
> don't stop short of a reboot.
> 
> Or, in other words, it happened occasionally under 2.6.19-rc3, but
> fixed itself. Under 2.6.19-rc5, it's happened less frequently (maybe),
> but once it starts, it goes on solid until I reboot the computer.
> Until I reboot, the laptop is fully unusable as things start hanging
> on the rtnl_lock (X, apparently).
> 
> Please see http://madrabbit.org/~ray/messages.gz for the
> /var/log/messages to understand what I mean by that. (Though, that was
> captured before I'd rebuilt the module with debugging, unfortunately.
> Regardless, it may help clarify what I mean here.)
> 
> So all the NETDEV WATCHDOG timeouts other than the first (of each of
> the two events) appear to be bogus, or side effects of rtnl_lock being
> held after the first time, and not clearing out.
> 
> <thinks...> Maybe I've got the culprit backward here. Perhaps
> something else in my system is locking on rtnl_lock, and bcm43xx can't
> acquire it? Could the NETDEV WATCHDOG timeouts be a side effect of
> someone acquiring and not releasing the rtnl_lock()? Is that possible?
> (ie, would it cause the effect I'm seeing?)

It certainly could. Please remove the new line in the hunk below for 
drivers/net/wireless/bcm43xx/bcm43xx_main.c:

@@ -3569,6 +3586,7 @@ int bcm43xx_select_wireless_core(struct
         bcm43xx_macfilter_clear(bcm, BCM43xx_MACFILTER_ASSOC);
         bcm43xx_macfilter_set(bcm, BCM43xx_MACFILTER_SELF, (u8 *)(bcm->net_dev->dev_addr));
         bcm43xx_security_init(bcm);
+       drain_txstatus_queue(bcm);
         ieee80211softmac_start(bcm->net_dev);

This will effectively remove _ALL_ bcm43xx patches between 2.6.19-rc3 and -rc6. If the rtnl_locks 
still occur, bcm43xx is not causing them. The other patches are not involved for your system.

Larry