From: Michael Buesch <mb-fseUSCV1ubazQB+pC5nmwQ@public.gmane.org>
To: Larry Finger <Larry.Finger-tQ5ms3gMjBLk1uMJSBkQmQ@public.gmane.org>
Cc: netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Bcm43xx-dev-0fE9KPoRgkgATYTw5x5z8w@public.gmane.org,
John Linville <linville-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org>,
Stefano Brivio <st3-sGOZH3hwPm2sTnJN9+BGXg@public.gmane.org>
Subject: Re: [PATCH] bcm43xx: further fix for periodic work errors
Date: Sat, 23 Sep 2006 09:56:05 +0200 [thread overview]
Message-ID: <200609230956.05475.mb@bu3sch.de> (raw)
In-Reply-To: <4514B322.mail1K91A36N8-tQ5ms3gMjBLk1uMJSBkQmQ@public.gmane.org>
On Saturday 23 September 2006 06:08, Larry Finger wrote:
> Recent changes in the setup for preemptible periodic work fixed most
> of the problems with NETDEV watchdog timeouts; however, some variants
> of the bcm43xx device still had the problem. These were fixed by setting
> the parameter MAXIMUM_BADNESS to 0. By doing so, all the functionality
> associated with calculating the 'badness' of the upcoming periodic work
> is no longer needed; therefore it is removed.
Uhm, no. Wait. _Why_ does the watchdog trigger.
All periodic work in the fastpath (which you remove with this patch)
is supposed to execute in a few microseconds.
I don't think we want to fix this my removing the fastpath and always
taking the _expensive_ slowpath periodic work.
So why does the watchdog trigger for the fast periodic work?
We need to find out.
Removing the fastpath is just bad for overall latency.
The two fastpath periodic works are 15 and 30, if executed
standalone. If the 15 and/or 30 is execiuted alongside with
a 60sec work, it's all slowpath, of course.
> Signed-off-by: Larry Finger <Larry.Finger-tQ5ms3gMjBLk1uMJSBkQmQ@public.gmane.org>
> ---
>
> John,
>
> This patch relies on "[PATCH] bcm43xx: fix netdev watchdog timeouts", which
> was submitted on 9/14/06. It is important for this one, as well as those
> already queued, to make the 2.6.19 cutoff.
>
> Thanks,
>
> 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
> @@ -3136,67 +3136,32 @@ static void do_periodic_work(struct bcm4
> schedule_delayed_work(&bcm->periodic_work, HZ * 15);
> }
>
> -/* Estimate a "Badness" value based on the periodic work
> - * state-machine state. "Badness" is worse (bigger), if the
> - * periodic work will take longer.
> - */
> -static int estimate_periodic_work_badness(unsigned int state)
> -{
> - int badness = 0;
> -
> - if (state % 8 == 0) /* every 120 sec */
> - badness += 10;
> - if (state % 4 == 0) /* every 60 sec */
> - badness += 5;
> - if (state % 2 == 0) /* every 30 sec */
> - badness += 1;
> - if (state % 1 == 0) /* every 15 sec */
> - badness += 1;
> -
> -#define BADNESS_LIMIT 4
> - return badness;
> -}
> -
> static void bcm43xx_periodic_work_handler(void *d)
> {
> struct bcm43xx_private *bcm = d;
> unsigned long flags;
> u32 savedirqs = 0;
> - int badness;
> -
> - badness = estimate_periodic_work_badness(bcm->periodic_state);
> - if (badness > BADNESS_LIMIT) {
> - /* Periodic work will take a long time, so we want it to
> - * be preemtible.
> - */
> - mutex_lock(&bcm->mutex);
> - netif_tx_disable(bcm->net_dev);
> - spin_lock_irqsave(&bcm->irq_lock, flags);
> - bcm43xx_mac_suspend(bcm);
> - if (bcm43xx_using_pio(bcm))
> - bcm43xx_pio_freeze_txqueues(bcm);
> - savedirqs = bcm43xx_interrupt_disable(bcm, BCM43xx_IRQ_ALL);
> - spin_unlock_irqrestore(&bcm->irq_lock, flags);
> - bcm43xx_synchronize_irq(bcm);
> - } else {
> - /* Periodic work should take short time, so we want low
> - * locking overhead.
> - */
> - mutex_lock(&bcm->mutex);
> - spin_lock_irqsave(&bcm->irq_lock, flags);
> - }
>
> + /* Periodic work may take a long time, so we want it to
> + * be preemtible. In any case, we need to disable transmits.
> + */
> + mutex_lock(&bcm->mutex);
> + netif_tx_disable(bcm->net_dev);
> + spin_lock_irqsave(&bcm->irq_lock, flags);
> + bcm43xx_mac_suspend(bcm);
> + if (bcm43xx_using_pio(bcm))
> + bcm43xx_pio_freeze_txqueues(bcm);
> + savedirqs = bcm43xx_interrupt_disable(bcm, BCM43xx_IRQ_ALL);
> + spin_unlock_irqrestore(&bcm->irq_lock, flags);
> + bcm43xx_synchronize_irq(bcm);
> do_periodic_work(bcm);
> -
> - if (badness > BADNESS_LIMIT) {
> - spin_lock_irqsave(&bcm->irq_lock, flags);
> - tasklet_enable(&bcm->isr_tasklet);
> - bcm43xx_interrupt_enable(bcm, savedirqs);
> - if (bcm43xx_using_pio(bcm))
> - bcm43xx_pio_thaw_txqueues(bcm);
> - bcm43xx_mac_enable(bcm);
> - netif_wake_queue(bcm->net_dev);
> - }
> + spin_lock_irqsave(&bcm->irq_lock, flags);
> + tasklet_enable(&bcm->isr_tasklet);
> + bcm43xx_interrupt_enable(bcm, savedirqs);
> + if (bcm43xx_using_pio(bcm))
> + bcm43xx_pio_thaw_txqueues(bcm);
> + bcm43xx_mac_enable(bcm);
> + netif_wake_queue(bcm->net_dev);
> mmiowb();
> spin_unlock_irqrestore(&bcm->irq_lock, flags);
> mutex_unlock(&bcm->mutex);
>
--
Greetings Michael.
next prev parent reply other threads:[~2006-09-23 7:56 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-09-23 4:08 [PATCH] bcm43xx: further fix for periodic work errors Larry Finger
[not found] ` <4514B322.mail1K91A36N8-tQ5ms3gMjBLk1uMJSBkQmQ@public.gmane.org>
2006-09-23 7:56 ` Michael Buesch [this message]
[not found] ` <200609230956.05475.mb-fseUSCV1ubazQB+pC5nmwQ@public.gmane.org>
2006-09-23 19:06 ` Larry Finger
[not found] ` <451585D1.3080102-tQ5ms3gMjBLk1uMJSBkQmQ@public.gmane.org>
2006-09-23 19:41 ` Michael Buesch
2006-09-23 20:05 ` Larry Finger
[not found] ` <451593A0.8030104-tQ5ms3gMjBLk1uMJSBkQmQ@public.gmane.org>
2006-09-23 20:22 ` Michael Buesch
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=200609230956.05475.mb@bu3sch.de \
--to=mb-fseuscv1ubazqb+pc5nmwq@public.gmane.org \
--cc=Bcm43xx-dev-0fE9KPoRgkgATYTw5x5z8w@public.gmane.org \
--cc=Larry.Finger-tQ5ms3gMjBLk1uMJSBkQmQ@public.gmane.org \
--cc=linville-2XuSBdqkA4R54TAoqtyWWQ@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).