From: "Michael Büsch" <m@bues.ch>
To: "Rafał Miłecki" <zajec5@gmail.com>
Cc: Larry Finger <Larry.Finger@lwfinger.net>,
linux-wireless@vger.kernel.org, b43-dev@lists.infradead.org,
isedev@gmail.com
Subject: [PATCH] b43: A fix for DMA transmission sequence errors
Date: Sat, 23 Mar 2013 11:35:17 +0100 [thread overview]
Message-ID: <20130323113517.01906b0b@milhouse> (raw)
In-Reply-To: <CACna6rz75ecyy5CdaJfi=dRjrTh_Rg793Ub+-0QdVnCZNyV+Lg@mail.gmail.com>
On Sat, 23 Mar 2013 00:27:30 +0100
Rafa? Mi?ecki <zajec5@gmail.com> wrote:
> Today I've plugged my 14e4:4315 and (unfortunately?) it's working
> pretty well. I hoped to reproduce some problems but failed to do so. I
> was transmitting for an hour with average speed 11MiB/s and didn't
> notice any DMA issues.
>
> I was using iperf with interval of 60 seconds and only 3 results
> showed some problems (8.5MiB/s, 2.5MiB/s, 4.5MiB/s). No disconnections
> however and no DMA errors. I just got "Group rekeying completed..." in
> wpa_supplicant.
>
> So as I can't reproduce this, I can't find any other fix for this
> issue, and there's no reason to stop this workaround. I'll just apply
> it and test over weekend to check for any regressions, but they are
> highly unlikely.
I don't really believe in this being a firmware bug.
Some b43 DMA engines (all?) have some alignment and page-boundary-crossing
constraints. I would rather guess that on some kernels with some options
turned on, alignment and/or boundary constraints are violated every
now and then. (and thus the packet never reaches the firmware).
I don't remember the details, though. Too long since I worked on that.
But a few sanity checks could probably be added to the code to check
this hypothesis.
Does the failing kernel/machine have any special things w.r.t. memory?
Like iommu, hugepages, whetever...
--
Michael
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/b43-dev/attachments/20130323/d5af58ad/attachment-0001.sig>
WARNING: multiple messages have this Message-ID (diff)
From: "Michael Büsch" <m@bues.ch>
To: "Rafał Miłecki" <zajec5@gmail.com>
Cc: Larry Finger <Larry.Finger@lwfinger.net>,
linux-wireless@vger.kernel.org, b43-dev@lists.infradead.org,
isedev@gmail.com
Subject: Re: [PATCH] b43: A fix for DMA transmission sequence errors
Date: Sat, 23 Mar 2013 11:35:17 +0100 [thread overview]
Message-ID: <20130323113517.01906b0b@milhouse> (raw)
In-Reply-To: <CACna6rz75ecyy5CdaJfi=dRjrTh_Rg793Ub+-0QdVnCZNyV+Lg@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1426 bytes --]
On Sat, 23 Mar 2013 00:27:30 +0100
Rafał Miłecki <zajec5@gmail.com> wrote:
> Today I've plugged my 14e4:4315 and (unfortunately?) it's working
> pretty well. I hoped to reproduce some problems but failed to do so. I
> was transmitting for an hour with average speed 11MiB/s and didn't
> notice any DMA issues.
>
> I was using iperf with interval of 60 seconds and only 3 results
> showed some problems (8.5MiB/s, 2.5MiB/s, 4.5MiB/s). No disconnections
> however and no DMA errors. I just got "Group rekeying completed..." in
> wpa_supplicant.
>
> So as I can't reproduce this, I can't find any other fix for this
> issue, and there's no reason to stop this workaround. I'll just apply
> it and test over weekend to check for any regressions, but they are
> highly unlikely.
I don't really believe in this being a firmware bug.
Some b43 DMA engines (all?) have some alignment and page-boundary-crossing
constraints. I would rather guess that on some kernels with some options
turned on, alignment and/or boundary constraints are violated every
now and then. (and thus the packet never reaches the firmware).
I don't remember the details, though. Too long since I worked on that.
But a few sanity checks could probably be added to the code to check
this hypothesis.
Does the failing kernel/machine have any special things w.r.t. memory?
Like iommu, hugepages, whetever...
--
Michael
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
next prev parent reply other threads:[~2013-03-23 10:35 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-03-20 19:02 [PATCH] b43: A fix for DMA transmission sequence errors Larry Finger
2013-03-22 23:27 ` Rafał Miłecki
2013-03-22 23:27 ` Rafał Miłecki
2013-03-23 10:35 ` Michael Büsch [this message]
2013-03-23 10:35 ` Michael Büsch
2013-03-23 15:53 ` Chris Vine
2013-03-23 15:53 ` Chris Vine
2013-03-23 17:26 ` Rafał Miłecki
2013-03-23 17:26 ` Rafał Miłecki
2013-03-23 17:28 ` Rafał Miłecki
2013-03-23 17:28 ` Rafał Miłecki
2013-03-23 17:43 ` Michael Büsch
2013-03-23 17:43 ` Michael Büsch
2013-03-23 18:01 ` Rafał Miłecki
2013-03-23 18:01 ` Rafał Miłecki
2013-03-23 18:20 ` ISE Development
2013-03-23 18:20 ` ISE Development
2013-03-24 21:51 ` Chris Vine
2013-03-24 21:51 ` Chris Vine
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=20130323113517.01906b0b@milhouse \
--to=m@bues.ch \
--cc=Larry.Finger@lwfinger.net \
--cc=b43-dev@lists.infradead.org \
--cc=isedev@gmail.com \
--cc=linux-wireless@vger.kernel.org \
--cc=zajec5@gmail.com \
/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.