Bug 13362
Summary: | rt2x00: slow wifi with correct basic rate bitmap | ||
---|---|---|---|
Product: | Networking | Reporter: | Alejandro Riveira (ariveira) |
Component: | Wireless | Assignee: | networking_wireless (networking_wireless) |
Status: | RESOLVED OBSOLETE | ||
Severity: | normal | CC: | aeriksson, alan, chrisw, florian, foxy, gwingerde, hoye, ilidrissiamine, IvDoorn, linville, loic-kernel, lukasz, ozan, papukaija, rjw, segoe |
Priority: | P1 | ||
Hardware: | All | ||
OS: | Linux | ||
Kernel Version: | 3.3.8 | Subsystem: | |
Regression: | Yes | Bisected commit-id: | |
Bug Depends on: | |||
Bug Blocks: | 13070 | ||
Attachments: |
diff of the regdumps of the card in good and bad configuration
Entire bad regdump Entire good regdump Some hardware info Fix ACK timeouts causing too many failures for TX frames. |
Description
Alejandro Riveira
2009-05-22 13:32:35 UTC
For the record, even if that patch causes the problem that's at best a hint that something is wrong with the basic rate bitmap usage in rt2x00, not with the patch. I've verified that after the patch the basic rate bitmap is handed to the driver correctly according to what the AP advertised. This might be a duplicate of 13009? (In reply to comment #1) > For the record, even if that patch causes the problem that's at best a hint > that something is wrong with the basic rate bitmap usage in rt2x00, not with > the patch. I've verified that after the patch the basic rate bitmap is handed > to the driver correctly according to what the AP advertised. well i dunno i'm just a user... if the problem lies elsewhere then i'm more than happy to test any patch. what i want is this fixed if possible > > This might be a duplicate of 13009? I tested ubuntu 2.6.27 and it did not have this problem nor did 2.6.28 or 2.6.29[1] till the backported patch so i do not think is duplicate Thanks for the efforts so far. [1] the bug says the problem appears in 2.6.27 To add another data point reverting 64e1b00c974ddeae6a60ebb02e1c487371905cea does fix the issue in 2.6.29.4 Maybe nest step is to check if reverting 7e0986c17f695952ce5d61ed793ce048ba90a661 also fixes it in 2.6.30-rc6 I tried 2.6.30-rc7 with 7e0986c17f695952ce5d61ed793ce048ba90a661 reverted and althought the speed increases i do not get all the bandwidth i get with 2.6.29 series... And the bitrates are somewhat "bumpy" against a reliable ftp server the same feeling but with higher bitrates (150-250 kiB vs 30-80 kiB) I get with a bad 2.6.29 kernel... So i'm open to other things to try. i forget to mention that 2.6.30-rc7 without the patch reverted has the same behavior as bad 2.6.29 i.e. bumpy 30-80 kiB. i forget to mention that 2.6.30-rc7 without the patch reverted has the same behavior as bad 2.6.29 i.e. bumpy 30-80 kiB. Have you tried setting a fixed rate? iwconfig wlan0 rate 54M You might try lower rates, even 11M or 5.5M. Do any of the fixed rates help? To actually fix the bitrate and bypass the rate control algorithm, use iwconfig wlan0 rate 54M fixed (In reply to comment #7) > Have you tried setting a fixed rate? > > iwconfig wlan0 rate 54M > > You might try lower rates, even 11M or 5.5M. Do any of the fixed rates help? This does not help as it did when i was not using misntrel prior to 2.6.27 See my exchange with Ivo here http://lkml.org/lkml/2009/5/25/163 for other things I tried and a bit more info. (In reply to comment #8) > To actually fix the bitrate and bypass the rate control algorithm, use > > iwconfig wlan0 rate 54M fixed Tried it right now in the bad kernel the "fixed" keyword doesn't help either thanks for the tips Created attachment 21641 [details]
diff of the regdumps of the card in good and bad configuration
Created with a script by Ivo
Created attachment 21642 [details]
Entire bad regdump
Created with script by Ivo
Created attachment 21643 [details]
Entire good regdump
Created with a script by Ivo
On Sunday 31 May 2009, Johannes Berg wrote:
> On Sun, 2009-05-31 at 00:39 +0200, Alejandro Riveira Fernández wrote:
> > El Sat, 30 May 2009 21:37:34 +0200 (CEST)
> > "Rafael J. Wysocki" <rjw@sisk.pl> escribió:
> >
> > > This message has been generated automatically as a part of a report
> > > of recent regressions.
> > >
> > > The following bug entry is on the current list of known regressions
> > > from 2.6.29. Please verify if it still should be listed and let me know
> > > (either way).
> >
> > It should be listed.
>
> But it should definitely be retitled -- the commit bisect pointed out
> has little to do with the problem. And Handled-by should point to Ivo
> since he was asking for debugging info and stuff.
>
> Retitle to "rt2x00: slow wifi with correct basic rate bitmap" or
> something like that, it's not a bug in mac80211.
On Sunday 07 June 2009, Alejandro Riveira Fernández wrote:
> El Sun, 7 Jun 2009 11:52:52 +0200 (CEST)
> "Rafael J. Wysocki" <rjw@sisk.pl> escribió:
>
> > This message has been generated automatically as a part of a report
> > of recent regressions.
> >
> > The following bug entry is on the current list of known regressions
> > from 2.6.29. Please verify if it still should be listed and let me know
> > (either way).
>
> Well the problem is still there afaics.
2.6.30 final still shows the problem. (In reply to comment #4) > I tried 2.6.30-rc7 with 7e0986c17f695952ce5d61ed793ce048ba90a661 reverted and > althought the speed increases i do not get all the bandwidth i get with > 2.6.29 > series... > And the bitrates are somewhat "bumpy" against a reliable ftp server > the same feeling but with higher bitrates (150-250 kiB vs 30-80 kiB) I get > with > a bad 2.6.29 kernel... > > So i'm open to other things to try. Final 2.6.30 with this revert has good behaviour so maybe i did some mistake testing rc7... I am going to add 2.6.30 as affected kernel I can confirm this in 2.6.30 too. "iwconfig wlan0 rate 54M", fixes it for a while, but eventually it will be back to 1Mb. The Link Quality is also varying a lot between 40 and 70% and never stays in the same values. "iwconfig wlan0 power off" seems to help a bit with stability. On the "bumpy" bitrates, i often get corrupted files because of this. Both ndiswrapper and the legacy driver work fine though. http://bugs.pardus.org.tr/show_bug.cgi?id=10276 Here's a similar user report which complains about the same issue with an Eminent wireless dongle (rt73usb). The user reports that the "iwconfig wlan0 rate 54M fixed" fixes the issue for a while and then the bandwidth tears down again. Created attachment 22325 [details]
Some hardware info
I am also using the rt2500pci module and experiencing slow speeds (40-80Kbps) and recently the network even disconnects sometimes.
I used to use the legacy driver without problems for many years, then the rt2x00 series worked somewhat when specifying 54M rate. But now, in 2.6.30.1 kernel (and maybe some 2.6.29s) it's worse.
On Sunday 02 August 2009, Alejandro Riveira Fernández wrote:
> El Sun, 26 Jul 2009 22:45:27 +0200 (CEST)
> "Rafael J. Wysocki" <rjw@sisk.pl> escribió:
>
> > This message has been generated automatically as a part of a report
> > of regressions introduced between 2.6.29 and 2.6.30.
> >
> > The following bug entry is on the current list of known regressions
> > introduced between 2.6.29 and 2.6.30. Please verify if it still should
> > be listed and let me know (either way).
>
> Sorry for the delay i did not have the time to test 2.6.31-rc* until now.
> Tried 2.6.31-rc5 the problem persist. The revert still fixes the issue; so
> the bug should be still present.
>
> >
> >
> > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13362
> > Subject : rt2x00: slow wifi with correct basic rate bitmap
> > Submitter : Alejandro Riveira <ariveira@gmail.com>
> > Date : 2009-05-22 13:32 (66 days old)
Created attachment 22991 [details]
Fix ACK timeouts causing too many failures for TX frames.
Please try this patch.
El Thu, 3 Sep 2009 19:04:49 GMT bugzilla-daemon@bugzilla.kernel.org escribió: > http://bugzilla.kernel.org/show_bug.cgi?id=13362 > > > > > > --- Comment #23 from Ivo van Doorn <IvDoorn@gmail.com> 2009-09-03 19:04:45 > --- > Created an attachment (id=22991) > --> (http://bugzilla.kernel.org/attachment.cgi?id=22991) > Fix ACK timeouts causing too many failures for TX frames. > > Please try this patch. I tried to apply on top of 2.6.30.5 but it fails $ git apply --check ../rt2500_fix.patch error: patch failed: drivers/net/wireless/rt2x00/rt2400pci.c:331 error: drivers/net/wireless/rt2x00/rt2400pci.c: patch does not apply error: patch failed: drivers/net/wireless/rt2x00/rt2500pci.c:337 error: drivers/net/wireless/rt2x00/rt2500pci.c: patch does not apply error: patch failed: drivers/net/wireless/rt2x00/rt2x00config.c:94 error: drivers/net/wireless/rt2x00/rt2x00config.c: patch does not apply error: patch failed: drivers/net/wireless/rt2x00/rt61pci.c:598 error: drivers/net/wireless/rt2x00/rt61pci.c: patch does not apply error: patch failed: drivers/net/wireless/rt2x00/rt73usb.c:561 error: drivers/net/wireless/rt2x00/rt73usb.c: patch does not apply What version of the kernel is thid patch for ? Thanks I made it for wireless-testing or rt2x00.git, but should have applied with a little buzz to 2.6.30. Could you try manually applying the patch? The only thing you need for rt2500pci is: diff --git a/drivers/net/wireless/rt2x00/rt2500pci.c b/drivers/net/wireless/rt2x00/rt2500pci.c index 4186582..2e872ac 100644 --- a/drivers/net/wireless/rt2x00/rt2500pci.c +++ b/drivers/net/wireless/rt2x00/rt2500pci.c @@ -337,9 +337,8 @@ static void rt2500pci_config_erp(struct rt2x00_dev *rt2x00dev, preamble_mask = erp->short_preamble << 3; rt2x00pci_register_read(rt2x00dev, TXCSR1, ®); - rt2x00_set_field32(®, TXCSR1_ACK_TIMEOUT, erp->ack_timeout); - rt2x00_set_field32(®, TXCSR1_ACK_CONSUME_TIME, - erp->ack_consume_time); + rt2x00_set_field32(®, TXCSR1_ACK_TIMEOUT, 0x162); + rt2x00_set_field32(®, TXCSR1_ACK_CONSUME_TIME, 0xa2); rt2x00_set_field32(®, TXCSR1_TSF_OFFSET, IEEE80211_HEADER); rt2x00_set_field32(®, TXCSR1_AUTORESPONDER, 1); rt2x00pci_register_write(rt2x00dev, TXCSR1, reg); El Fri, 4 Sep 2009 18:55:10 GMT bugzilla-daemon@bugzilla.kernel.org escribió: > http://bugzilla.kernel.org/show_bug.cgi?id=13362 > > > > > > --- Comment #25 from Ivo van Doorn <IvDoorn@gmail.com> 2009-09-04 18:55:06 > --- > I made it for wireless-testing or rt2x00.git, but should have applied with a > little buzz to 2.6.30. > > Could you try manually applying the patch? The only thing you need for > rt2500pci is: Ok will do. or maybe use patch directly would do the trick. > > diff --git a/drivers/net/wireless/rt2x00/rt2500pci.c > b/drivers/net/wireless/rt2x00/rt2500pci.c > index 4186582..2e872ac 100644 > --- a/drivers/net/wireless/rt2x00/rt2500pci.c > +++ b/drivers/net/wireless/rt2x00/rt2500pci.c > @@ -337,9 +337,8 @@ static void rt2500pci_config_erp(struct rt2x00_dev > *rt2x00dev, > preamble_mask = erp->short_preamble << 3; > > rt2x00pci_register_read(rt2x00dev, TXCSR1, ®); > - rt2x00_set_field32(®, TXCSR1_ACK_TIMEOUT, erp->ack_timeout); > - rt2x00_set_field32(®, TXCSR1_ACK_CONSUME_TIME, > - erp->ack_consume_time); > + rt2x00_set_field32(®, TXCSR1_ACK_TIMEOUT, 0x162); > + rt2x00_set_field32(®, TXCSR1_ACK_CONSUME_TIME, 0xa2); > rt2x00_set_field32(®, TXCSR1_TSF_OFFSET, IEEE80211_HEADER); > rt2x00_set_field32(®, TXCSR1_AUTORESPONDER, 1); > rt2x00pci_register_write(rt2x00dev, TXCSR1, reg); > Bugzilla is rejecting my mails so... i paste this here
> http://bugzilla.kernel.org/show_bug.cgi?id=13362
>
>
>
>
>
> --- Comment #25 from Ivo van Doorn <IvDoorn@gmail.com> 2009-09-04 18:55:06
> ---
> I made it for wireless-testing or rt2x00.git, but should have applied with a
> little buzz to 2.6.30.
>
O finally tried. i applied this patch [1] but it does not fix it for me :(
[1]
diff --git a/drivers/net/wireless/rt2x00/rt2500pci.c
b/drivers/net/wireless/rt2x00/rt2500pci.c index 276a823..e71d44b 100644
--- a/drivers/net/wireless/rt2x00/rt2500pci.c
+++ b/drivers/net/wireless/rt2x00/rt2500pci.c
@@ -341,10 +341,15 @@ static void rt2500pci_config_erp(struct rt2x00_dev
*rt2x00dev, preamble_mask = erp->short_preamble << 3;
rt2x00pci_register_read(rt2x00dev, TXCSR1, ®);
- rt2x00_set_field32(®, TXCSR1_ACK_TIMEOUT,
- erp->ack_timeout);
- rt2x00_set_field32(®, TXCSR1_ACK_CONSUME_TIME,
- erp->ack_consume_time);
+
+/*
+ * rt2x00_set_field32(®, TXCSR1_ACK_TIMEOUT,
+ * erp->ack_timeout);
+ * rt2x00_set_field32(®, TXCSR1_ACK_CONSUME_TIME,
+ * erp->ack_consume_time);
+ */
+ rt2x00_set_field32(®, TXCSR1_ACK_TIMEOUT, 0x162);
+ rt2x00_set_field32(®, TXCSR1_ACK_CONSUME_TIME, 0xa2);
rt2x00pci_register_write(rt2x00dev, TXCSR1, reg);
rt2x00pci_register_read(rt2x00dev, ARCSR2, ®);
Now i switched to 2.6.31 the revert is still needed (not a surprise but anyway just FYI). Alejandro .- El Fri, 4 Sep 2009 18:55:10 GMT bugzilla-daemon@bugzilla.kernel.org escribió: > http://bugzilla.kernel.org/show_bug.cgi?id=13362 > > > > > > --- Comment #25 from Ivo van Doorn <IvDoorn@gmail.com> 2009-09-04 18:55:06 > --- > I made it for wireless-testing or rt2x00.git, but should have applied with a > little buzz to 2.6.30. > O finally tried. i applied this patch [1] but it does not fix it for me :( [1] diff --git a/drivers/net/wireless/rt2x00/rt2500pci.c b/drivers/net/wireless/rt2x00/rt2500pci.c index 276a823..e71d44b 100644 --- a/drivers/net/wireless/rt2x00/rt2500pci.c +++ b/drivers/net/wireless/rt2x00/rt2500pci.c @@ -341,10 +341,15 @@ static void rt2500pci_config_erp(struct rt2x00_dev *rt2x00dev, preamble_mask = erp->short_preamble << 3; rt2x00pci_register_read(rt2x00dev, TXCSR1, ®); - rt2x00_set_field32(®, TXCSR1_ACK_TIMEOUT, - erp->ack_timeout); - rt2x00_set_field32(®, TXCSR1_ACK_CONSUME_TIME, - erp->ack_consume_time); + +/* + * rt2x00_set_field32(®, TXCSR1_ACK_TIMEOUT, + * erp->ack_timeout); + * rt2x00_set_field32(®, TXCSR1_ACK_CONSUME_TIME, + * erp->ack_consume_time); + */ + rt2x00_set_field32(®, TXCSR1_ACK_TIMEOUT, 0x162); + rt2x00_set_field32(®, TXCSR1_ACK_CONSUME_TIME, 0xa2); rt2x00pci_register_write(rt2x00dev, TXCSR1, reg); rt2x00pci_register_read(rt2x00dev, ARCSR2, ®); I can confirm the bug exists in Ubuntu 9.10 Karmic. Ok; compiled 2.6.32 today and it still needs the revert. Just for the sake of completness becouse i know it wont be fixed anytime soon :( Why problem still exist in 2.6.32 and even 2.6.33-rc2? I'm pretty desperate, because only rt2500 work in some buggy motherboard, but it's terribly slow + need to be set power to off. 02:09.0 0280: 1814:0201 (rev 01) Subsystem: 1814:2560 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=slow >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- Latency: 64, Cache Line Size: 32 bytes Interrupt: pin A routed to IRQ 19 Region 0: Memory at c0120000 (32-bit, non-prefetchable) [size=8K] Capabilities: [40] Power Management version 2 Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 PME-Enable- DSel=0 DScale=0 PME- Kernel driver in use: rt2500pci Kernel modules: rt2500pci Terribly slow connection - 200Kbit VS other cards with 2Mbit (even after disable power save). Computer: x86, 512M RAM, ATI R200 Gertjan, Ivo -- anything more to add here? Nothing new in 2.6.33; still slow by default and still the revert fixes it. Using Ubuntu 10.04 with upgraded kernel2.6.32-22 and following /etc/rc.local I no longer need the rate fix for rt2500. I note the following FWIW. iwconfig shows rate at 1M at first. Do a broadband speed test and get nearly 15Mbps. iwconfig shortly thereafter shows 54M. iwconfig some time late shows 1M again. In my case, I think the rt2500 rate problem may be gone. In its place I have a minor nuisance with a pm problem spamming kern.log, which I've 'fixed-well-enough-for-my-purposes' with another /etc/rc.local line. #! /bin/sh # this is /etc/rc.local; # it is called-by /etc/init.d/rc.local in Ubuntu 10.04 # don't forget to chmod 755 /etc/rc.local # configure rt2500pci power mgmt -> off & rate -> 54MHz iwconfig wlan0 power off #iwconfig wlan0 rate 54M exit 0 yeti No change for me. Lucid as well. There is a bug reported downstream at Launchpad similar to this one: https://bugs.edge.launchpad.net/ubuntu/+source/linux/+bug/433972 It seems the problem persists with 2.6.35 and 2.6.36-rc3. Gertjan and Ivo, ping? I'm not hearing any other similar reports. Is this issue still relevant for 2.6.37 or later? The kernel has been just released. Let it make its way into any major distro before people report whether the issue is fixed. Perhaps you could simply test 2.6.37 without waiting? :-) It's still there, or at least nothing has changed in my setup when I moved to 2.6.37 (vanilla, on gentoo). My card routinely drops to 100KB/s download after a couple of minutes from the expected and achieved >~500 KB/s (my cable download is 5Mbps). I'd be happy to see that fixed. Any details I can provide? It's an rt2500pci on an old PII box. I finally tested again an unpatched kernel ( un-reverted? :P ) and I still have the same problem. I tested 2.6.37.1 version. Same hardware and AP as before. Still buggy on 3.3.8 with gentoo. Signal is always -100 dbM and constantly losing the connection. This bug relates to a very old kernel. Closing as obsolete. |