From: Larry Finger <Larry.Finger@lwfinger.net>
To: "Rafał Miłecki" <zajec5@gmail.com>
Cc: b43-dev <b43-dev@lists.infradead.org>,
linux-wireless@vger.kernel.org,
Juan Carlos Romero <juancarlos.romero@gmail.com>
Subject: Regression affecting b43 LP-PHY card
Date: Tue, 10 May 2011 13:31:12 -0500 [thread overview]
Message-ID: <4DC98470.10500@lwfinger.net> (raw)
In-Reply-To: <BANLkTin=cU_kCSFfznna69pkgTsSNVjJgw@mail.gmail.com>
On 05/09/2011 05:52 PM, Rafa? Mi?ecki wrote:
> Juan owns Lenovo affected by well-known LP-PHY DMA errors. His testing
> procedure is following:
> modprobe wl; connect; download sth small; rmmod wl;
> modprobe b43; download 2GB
>
> When working on DMA errors we discovered that wireless-testing is not
> working well for him. Even after performing above procedure his
> machine disconnects quickly and he is not able to reconnect. We tested
> 2.6.39-rc6 from tarball and it was working fine. I'd like to highlight
> here, that we were switching between mainline and wireless-testing few
> times. It is not a random issue.
>
> I suspected this regression could be caused by my recent ssb patches.
> So I reverted all of them but this didn't help.
>
> In this situation we decided to bisect. I was a little afraid of last
> merges so we took older 2.6.38 as GOOD (we tested this twice) and
> wireless-testing commit before my ssb changes as BAD. Today Juan
> finished bisecting kernel:
> http://pastebin.com/HSKbRzpB
>
> According to his bisection the first bad commit is
> e06383db9ec591696a06654257474b85bac1f8cb [0]:
> hrtimers: extend hrtimer base code to handle more then 2 clockids
>
> Does it make any sense to you? Could this be some timing issue?
>
> It was too late to test this today, we (Juan) will work on this
> tomorrow. It's impossible to revert this commit from HEAD of
> wireless-testing, so my idea is to checkout commit, test, revert,
> test.
>
> Did anyone else experience any similar problems with latest wireless-testing?
I did some testing over the weekend using the LP-PHY device in my HP Mini 110
netbook. This one does not have any DMA issues, but b43 generates PHY
transmission errors and dies when I try to copy a file over my LAN. The source
material is contained on an NFS-mounted volume. The machine that exports the
volume is connected by wire to the router/switch. When I get a file from the
Internet, there are no problems. In the latter case, the transfer rate of the
download is up to 1.2 MB/s. I don't know what the peak rate is for the NFS copy
operation.
I was able to test kernels from the wireless-testing tree back to v2.6.36. All
behaved the same, thus my problem is not a regression.
Larry
WARNING: multiple messages have this Message-ID (diff)
From: Larry Finger <Larry.Finger@lwfinger.net>
To: "Rafał Miłecki" <zajec5@gmail.com>
Cc: b43-dev <b43-dev@lists.infradead.org>,
linux-wireless@vger.kernel.org,
Juan Carlos Romero <juancarlos.romero@gmail.com>
Subject: Re: Regression affecting b43 LP-PHY card
Date: Tue, 10 May 2011 13:31:12 -0500 [thread overview]
Message-ID: <4DC98470.10500@lwfinger.net> (raw)
In-Reply-To: <BANLkTin=cU_kCSFfznna69pkgTsSNVjJgw@mail.gmail.com>
On 05/09/2011 05:52 PM, Rafał Miłecki wrote:
> Juan owns Lenovo affected by well-known LP-PHY DMA errors. His testing
> procedure is following:
> modprobe wl; connect; download sth small; rmmod wl;
> modprobe b43; download 2GB
>
> When working on DMA errors we discovered that wireless-testing is not
> working well for him. Even after performing above procedure his
> machine disconnects quickly and he is not able to reconnect. We tested
> 2.6.39-rc6 from tarball and it was working fine. I'd like to highlight
> here, that we were switching between mainline and wireless-testing few
> times. It is not a random issue.
>
> I suspected this regression could be caused by my recent ssb patches.
> So I reverted all of them but this didn't help.
>
> In this situation we decided to bisect. I was a little afraid of last
> merges so we took older 2.6.38 as GOOD (we tested this twice) and
> wireless-testing commit before my ssb changes as BAD. Today Juan
> finished bisecting kernel:
> http://pastebin.com/HSKbRzpB
>
> According to his bisection the first bad commit is
> e06383db9ec591696a06654257474b85bac1f8cb [0]:
> hrtimers: extend hrtimer base code to handle more then 2 clockids
>
> Does it make any sense to you? Could this be some timing issue?
>
> It was too late to test this today, we (Juan) will work on this
> tomorrow. It's impossible to revert this commit from HEAD of
> wireless-testing, so my idea is to checkout commit, test, revert,
> test.
>
> Did anyone else experience any similar problems with latest wireless-testing?
I did some testing over the weekend using the LP-PHY device in my HP Mini 110
netbook. This one does not have any DMA issues, but b43 generates PHY
transmission errors and dies when I try to copy a file over my LAN. The source
material is contained on an NFS-mounted volume. The machine that exports the
volume is connected by wire to the router/switch. When I get a file from the
Internet, there are no problems. In the latter case, the transfer rate of the
download is up to 1.2 MB/s. I don't know what the peak rate is for the NFS copy
operation.
I was able to test kernels from the wireless-testing tree back to v2.6.36. All
behaved the same, thus my problem is not a regression.
Larry
next prev parent reply other threads:[~2011-05-10 18:31 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-05-09 22:52 Regression affecting b43 LP-PHY card Rafał Miłecki
2011-05-09 22:52 ` Rafał Miłecki
2011-05-09 22:58 ` Ben Greear
2011-05-09 22:58 ` Ben Greear
2011-05-10 18:31 ` Larry Finger [this message]
2011-05-10 18:31 ` Larry Finger
2011-05-10 18:57 ` [hrtimers] " Rafał Miłecki
2011-05-10 18:57 ` Rafał Miłecki
2011-05-10 19:06 ` John Stultz
2011-05-10 19:45 ` Rafał Miłecki
2011-05-10 19:45 ` Rafał Miłecki
2011-05-10 21:48 ` Rafał Miłecki
2011-05-10 21:48 ` Rafał Miłecki
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=4DC98470.10500@lwfinger.net \
--to=larry.finger@lwfinger.net \
--cc=b43-dev@lists.infradead.org \
--cc=juancarlos.romero@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.