From: Michael Buesch <mb@bu3sch.de>
To: Larry Finger <Larry.Finger@lwfinger.net>
Cc: Broadcom Linux <bcm43xx-dev@lists.berlios.de>,
wireless <linux-wireless@vger.kernel.org>,
fback+bcm@fback.net
Subject: Re: [RFC/T] b43: to few loop tries in do_dummy_tx
Date: Mon, 29 Sep 2008 20:38:37 +0200 [thread overview]
Message-ID: <200809292038.37939.mb@bu3sch.de> (raw)
In-Reply-To: <48E11F1E.50705@lwfinger.net>
On Monday 29 September 2008 20:31:58 Larry Finger wrote:
> Michael,
>
> I have started modifying my copy of b43 to see if I can locate any
> coding problems that might be causing the PHY transmission errors. To
> start with, I am checking all the sections that use udelay. The main
> reason is that when a bug in the CPU timer cut all delays in half, I
> got these errors in b43legacy. I also noted the report this morning
> that compiler and toolchain versions seem to be important.
>
> One of the first places I looked was in do_dummy_tx. When I checked
> the spin-on-condition loops in this routine, I found that the 3rd
> always used the maximum number of loops and exited before the
> condition was met. I increased the number of possible loops from 10 to
> 20 and found that it always takes 17 or 18 passes for the condition to
> be met on my machine.
>
> The existing code matches specs - I even checked the code in
> 4.150.10.5. It is too early to tell if this has anything to do with
> the errors, but I suggest the following change:
>
> diff --git a/drivers/net/wireless/b43/main.c
> b/drivers/net/wireless/b43/main.c
> index 7205a93..af60122 100644
> --- a/drivers/net/wireless/b43/main.c
> +++ b/drivers/net/wireless/b43/main.c
> @@ -814,7 +814,7 @@ void b43_dummy_transmission(struct b43_wldev *dev)
> break;
> udelay(10);
> }
> - for (i = 0x00; i < 0x0A; i++) {
> + for (i = 0x00; i < 0x19; i++) {
> value = b43_read16(dev, 0x0690);
> if (!(value & 0x0100))
> break;
>
> Using 25 passes gives a little margin for CPUs that are much faster
> than mine. Perhaps the margin should even be bigger.
Yeah, feel free to submit this to John.
Dummy-tx _can_ for sure trigger PHY TX errors. I already saw that
in my experiments, too. It also makes sense, as dummy-tx is poking
with the lowlevel TX hardware.
So if a loop exists early it may leave TX hardware in an inconsistent state.
Actually, I do know since the very first days of bcm43xx that the
loop counts are not big enough in some of these loops. But I didn't
change it, as it was said the current counts match the specs.
However, I think it's perfectly valid to raise the values.
Please do so, thanks a lot.
--
Greetings Michael.
next prev parent reply other threads:[~2008-09-29 18:39 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-09-29 18:31 [RFC/T] b43: to few loop tries in do_dummy_tx Larry Finger
2008-09-29 18:38 ` Michael Buesch [this message]
2008-09-29 21:16 ` Peter Stuge
2008-09-29 21:28 ` Larry Finger
2008-09-30 5:50 ` Peter Stuge
2008-09-30 13:28 ` Michael Buesch
2008-09-30 13:46 ` gavron
2008-09-30 13:54 ` Michael Buesch
2008-09-30 14:11 ` Holger Schurig
2008-09-30 14:22 ` Michael Buesch
2008-09-30 14:13 ` Peter Stuge
2008-09-30 14:21 ` Michael Buesch
2008-09-30 13:26 ` Michael Buesch
2008-09-30 16:34 ` Artem Antonov
2008-09-30 20:02 ` Stefanik Gábor
2008-09-30 22:11 ` 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=200809292038.37939.mb@bu3sch.de \
--to=mb@bu3sch.de \
--cc=Larry.Finger@lwfinger.net \
--cc=bcm43xx-dev@lists.berlios.de \
--cc=fback+bcm@fback.net \
--cc=linux-wireless@vger.kernel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.