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

Ray Lee wrote:

First off, thanks for all your help.

Second off,

On 11/16/06, Larry Finger [off-list ref] wrote:

quoted

Ray Lee wrote:

quoted

If I could figure out a way to make it repeatable, I'd happily do a 

blind

quoted

bisect.

[...]

quoted

quoted

I'm open to suggestions on how to make the problem trigger more than 

once

quoted

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.

quoted

 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