netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Larry Finger <Larry.Finger-tQ5ms3gMjBLk1uMJSBkQmQ@public.gmane.org>
To: Michael Buesch <mb-fseUSCV1ubazQB+pC5nmwQ@public.gmane.org>
Cc: netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	Bcm43xx-dev-0fE9KPoRgkgATYTw5x5z8w@public.gmane.org,
	Stefano Brivio <st3-sGOZH3hwPm2sTnJN9+BGXg@public.gmane.org>
Subject: Re: RFC/T: Possible fix for bcm43xx periodic work bug
Date: Thu, 07 Sep 2006 17:08:26 -0500	[thread overview]
Message-ID: <4500985A.7000701@lwfinger.net> (raw)
In-Reply-To: <200609072239.20074.mb-fseUSCV1ubazQB+pC5nmwQ@public.gmane.org>

[-- Attachment #1: Type: text/plain, Size: 1674 bytes --]

Michael Buesch wrote:
> 
> The real question is: Why does this patch help?
> 
> Let's explain it. We don't stop networking just for fun there.
> While executing long preemptible periodic work, we must ensure
> that the TX path into the driver is not entered. It's the same
> reason why we disable IRQs in the first place. We can't take the
> mutex in the TX path and the IRQ handler. (That are the only places
> where we can't take the mutex).
> Short: We must stop netif here.
> The question is: Why does stopping netif queue cause a watchdog
> trigger here? The maximum time it can take for the periodic
> work inside of the critical section is about 0.2sec. So the queue
> is stopped for about 0.2sec max. Why does the watchdog trigger?
> Any idea from some networking guru?
> Could synchronize_net() take over 5sec in some worst case? Why?
> Questions over questions :D
> 

To check if it takes more than 5 seconds, I restored the original network disabling code and 
increased the timeout to 30 seconds. If this works without error, I'll try to margin the time. I'm 
still running that branch every second.

Larry


Index: wireless-2.6/drivers/net/wireless/bcm43xx/bcm43xx_main.c
===================================================================
--- wireless-2.6.orig/drivers/net/wireless/bcm43xx/bcm43xx_main.c
+++ wireless-2.6/drivers/net/wireless/bcm43xx/bcm43xx_main.c
@@ -4147,6 +4147,7 @@ static int __devinit bcm43xx_init_one(st
  	SET_MODULE_OWNER(net_dev);
  	SET_NETDEV_DEV(net_dev, &pdev->dev);

+	net_dev->watchdog_timeo = 30 * HZ;
  	net_dev->open = bcm43xx_net_open;
  	net_dev->stop = bcm43xx_net_stop;
  	net_dev->get_stats = bcm43xx_net_get_stats;



[-- Attachment #2: patch_periodic --]
[-- Type: text/plain, Size: 1054 bytes --]


Index: wireless-2.6/drivers/net/wireless/bcm43xx/bcm43xx_main.c
===================================================================
--- wireless-2.6.orig/drivers/net/wireless/bcm43xx/bcm43xx_main.c
+++ wireless-2.6/drivers/net/wireless/bcm43xx/bcm43xx_main.c
@@ -3207,7 +3207,7 @@ static void do_periodic_work(struct bcm4
 		bcm43xx_periodic_every15sec(bcm);
 	bcm->periodic_state = state + 1;
 
-	schedule_delayed_work(&bcm->periodic_work, HZ * 15);
+	schedule_delayed_work(&bcm->periodic_work, HZ * 1);
 }
 
 /* Estimate a "Badness" value based on the periodic work
@@ -3227,7 +3227,7 @@ static int estimate_periodic_work_badnes
 	if (state % 1 == 0) /* every 15 sec */
 		badness += 1;
 
-#define BADNESS_LIMIT	4
+#define BADNESS_LIMIT	0
 	return badness;
 }
 
@@ -4147,6 +4147,7 @@ static int __devinit bcm43xx_init_one(st
 	SET_MODULE_OWNER(net_dev);
 	SET_NETDEV_DEV(net_dev, &pdev->dev);
 
+	net_dev->watchdog_timeo = 30 * HZ;
 	net_dev->open = bcm43xx_net_open;
 	net_dev->stop = bcm43xx_net_stop;
 	net_dev->get_stats = bcm43xx_net_get_stats;


[-- Attachment #3: Type: text/plain, Size: 179 bytes --]

_______________________________________________
Bcm43xx-dev mailing list
Bcm43xx-dev-0fE9KPoRgkgATYTw5x5z8w@public.gmane.org
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev

  parent reply	other threads:[~2006-09-07 22:08 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-09-07 18:17 RFC/T: Possible fix for bcm43xx periodic work bug Larry Finger
     [not found] ` <45006221.4090603-tQ5ms3gMjBLk1uMJSBkQmQ@public.gmane.org>
2006-09-07 20:39   ` Michael Buesch
     [not found]     ` <200609072239.20074.mb-fseUSCV1ubazQB+pC5nmwQ@public.gmane.org>
2006-09-07 22:08       ` Larry Finger [this message]
     [not found]     ` <45016F63.9000200@lwfinger.net>
     [not found]       ` <45016F63.9000200-tQ5ms3gMjBLk1uMJSBkQmQ@public.gmane.org>
2006-09-08 20:42         ` Michael Buesch
2006-09-08  9:42 ` Erik Mouw
2006-09-08  9:45   ` Michael Buesch
2006-09-08 13:23     ` Erik Mouw
     [not found]       ` <20060908132317.GS26916-7jKlSzr1t1+rFW3l5+5NieqUGfbH9hYC@public.gmane.org>
2006-09-08 13:36         ` Larry Finger
     [not found]           ` <450171E4.8070901-tQ5ms3gMjBLk1uMJSBkQmQ@public.gmane.org>
2006-09-11 10:52             ` Erik Mouw
     [not found]               ` <20060911105202.GA7903-7jKlSzr1t1+rFW3l5+5NieqUGfbH9hYC@public.gmane.org>
2006-09-11 14:37                 ` Larry Finger

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4500985A.7000701@lwfinger.net \
    --to=larry.finger-tq5ms3gmjblk1umjsbkqmq@public.gmane.org \
    --cc=Bcm43xx-dev-0fE9KPoRgkgATYTw5x5z8w@public.gmane.org \
    --cc=mb-fseUSCV1ubazQB+pC5nmwQ@public.gmane.org \
    --cc=netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=st3-sGOZH3hwPm2sTnJN9+BGXg@public.gmane.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).