Bug 13362

Summary: rt2x00: slow wifi with correct basic rate bitmap
Product: Networking Reporter: Alejandro Riveira (ariveira)
Component: WirelessAssignee: 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
I have a rt2500pci card that uses rt2x00 drivers

 I noticed that my wifi connection has slowed when stitching
from 2.6.29.1 to 2.6.29.4 (it is also slow on 30-rc6)
Also 2.6.27 (ubuntu) does not suffer it.

 
 The slowness is enoughto notice it when connecting through a 3MBit
 Adsl connection i.e. with the patch i get 30 40 60 ...
 80 kiB maximum without it full 310 KiB so it is an issue
 for me (i have inet <-> modem-router <-> myPC only so i can
 not test with another pc)

  My Ap is set to "mixed" but i connect at G speeds ie iwconfig show 54M or 48M
 or 36M but the connection is slow nonetheless 
 

 I bisected and came to the following commit as the culprit

 I can test patches and if you need more info just ask.

$ git bisect good
64e1b00c974ddeae6a60ebb02e1c487371905cea is first bad commit
commit 64e1b00c974ddeae6a60ebb02e1c487371905cea
Author: Johannes Berg <johannes@sipsolutions.net>
Date:   Fri Apr 24 16:05:16 2009 +0000

    mac80211: fix basic rate bitmap calculation
    
    upstream commit: 7e0986c17f695952ce5d61ed793ce048ba90a661
    
    "mac80211: fix basic rates setting from association response"
    introduced a copy/paste error.
    
    Unfortunately, this not just leads to wrong data being passed
    to the driver but is remotely exploitable for some hardware or
    driver combinations.
    
    Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
    Signed-off-by: John W. Linville <linville@tuxdriver.com>
    Signed-off-by: Chris Wright <chrisw@sous-sol.org>

:040000 040000 e9e479210b46ae45f9c84badd57039df44d4077c
ea0b719e549849446e62e065b2570fab5a801895 M      net

 Bisect Log
$ git bisect log
git bisect start
# bad: [186f9b18b94afd0b75a8ec1b394b0f119d479eb6] Linux 2.6.29.4
git bisect bad 186f9b18b94afd0b75a8ec1b394b0f119d479eb6
# good: [8e0ee43bc2c3e19db56a4adaa9a9b04ce885cd84] Linux 2.6.29
git bisect good 8e0ee43bc2c3e19db56a4adaa9a9b04ce885cd84
# good: [fda28853bc4bc053ef2fafb5c7d2a26e6ce4b4bf] KVM: Fix missing smp tlb flush in invlpg
git bisect good fda28853bc4bc053ef2fafb5c7d2a26e6ce4b4bf
# bad: [7843dcfe1115e9412e6e83492e17f9c75b5a062d] mv643xx_eth: OOM handling fixes
git bisect bad 7843dcfe1115e9412e6e83492e17f9c75b5a062d
# bad: [87b59eac0914ab407df57fe23d880dccd9a9436d] virtio-rng: Remove false BUG for spurious callbacks
git bisect bad 87b59eac0914ab407df57fe23d880dccd9a9436d
# good: [24016c735e651f179692432f18176348caeb82b0] scsi: mpt: suppress debugobjects warning
git bisect good 24016c735e651f179692432f18176348caeb82b0
# good: [5c47524b514b5bb3732c3b893338a210d67da3cd] thinkpad-acpi: fix LED blinking through timer trigger
git bisect good 5c47524b514b5bb3732c3b893338a210d67da3cd
# bad: [d595990048ad17ba7b0ad50438ed64f88b7c25ca] KVM: MMU: disable global page optimization
git bisect bad d595990048ad17ba7b0ad50438ed64f88b7c25ca
# bad: [64e1b00c974ddeae6a60ebb02e1c487371905cea] mac80211: fix basic rate bitmap calculation
git bisect bad 64e1b00c974ddeae6a60ebb02e1c487371905cea
# good: [d2d83e1f527b6b0faf15d54b22c032ed5812d054] ALSA: us122l: add snd_us122l_free()
git bisect good d2d83e1f527b6b0faf15d54b22c032ed5812d054
Comment 1 Johannes Berg 2009-05-22 14:02:57 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?
Comment 2 Alejandro Riveira 2009-05-22 14:16:39 UTC
(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
Comment 3 Alejandro Riveira 2009-05-22 15:44:30 UTC
  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
Comment 4 Alejandro Riveira 2009-05-25 10:17:25 UTC
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.
Comment 5 Alejandro Riveira 2009-05-25 10:25:50 UTC
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.
Comment 6 Alejandro Riveira 2009-05-25 10:32:20 UTC
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.
Comment 7 John W. Linville 2009-05-27 07:42:30 UTC
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?
Comment 8 Johannes Berg 2009-05-27 07:47:25 UTC
To actually fix the bitrate and bypass the rate control algorithm, use

  iwconfig wlan0 rate 54M fixed
Comment 9 Alejandro Riveira 2009-05-27 12:40:14 UTC
(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.
Comment 10 Alejandro Riveira 2009-05-27 12:53:59 UTC
(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
Comment 11 Alejandro Riveira 2009-05-30 23:07:08 UTC
Created attachment 21641 [details]
diff of the regdumps of the card in good and bad configuration

Created with a script by Ivo
Comment 12 Alejandro Riveira 2009-05-30 23:08:06 UTC
Created attachment 21642 [details]
Entire bad regdump

Created with script by Ivo
Comment 13 Alejandro Riveira 2009-05-30 23:08:46 UTC
Created attachment 21643 [details]
Entire good regdump

Created with a script by Ivo
Comment 14 Rafael J. Wysocki 2009-06-01 20:27:34 UTC
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.
Comment 15 Rafael J. Wysocki 2009-06-07 21:04:59 UTC
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.
Comment 16 Alejandro Riveira 2009-06-10 14:12:20 UTC
2.6.30 final still shows the problem.
Comment 17 Alejandro Riveira 2009-06-10 14:36:27 UTC
(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
Comment 18 Martin Segoe 2009-06-23 18:29:30 UTC
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.
Comment 19 Ozan Caglayan 2009-07-07 06:12:45 UTC
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).
Comment 20 Ozan Caglayan 2009-07-10 16:43:34 UTC
The user reports that the "iwconfig wlan0 rate 54M fixed" fixes the issue for a while and then the bandwidth tears down again.
Comment 21 mft 2009-07-12 18:21:44 UTC
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.
Comment 22 Rafael J. Wysocki 2009-08-02 20:30:07 UTC
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)
Comment 23 Ivo van Doorn 2009-09-03 19:04:45 UTC
Created attachment 22991 [details]
Fix ACK timeouts causing too many failures for TX frames.

Please try this patch.
Comment 24 Alejandro Riveira 2009-09-04 13:24:26 UTC
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
Comment 25 Ivo van Doorn 2009-09-04 18:55:06 UTC
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, &reg);
-	rt2x00_set_field32(&reg, TXCSR1_ACK_TIMEOUT, erp->ack_timeout);
-	rt2x00_set_field32(&reg, TXCSR1_ACK_CONSUME_TIME,
-			   erp->ack_consume_time);
+	rt2x00_set_field32(&reg, TXCSR1_ACK_TIMEOUT, 0x162);
+	rt2x00_set_field32(&reg, TXCSR1_ACK_CONSUME_TIME, 0xa2);
 	rt2x00_set_field32(&reg, TXCSR1_TSF_OFFSET, IEEE80211_HEADER);
 	rt2x00_set_field32(&reg, TXCSR1_AUTORESPONDER, 1);
 	rt2x00pci_register_write(rt2x00dev, TXCSR1, reg);
Comment 26 Alejandro Riveira 2009-09-04 19:38:02 UTC
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, &reg);
> -    rt2x00_set_field32(&reg, TXCSR1_ACK_TIMEOUT, erp->ack_timeout);
> -    rt2x00_set_field32(&reg, TXCSR1_ACK_CONSUME_TIME,
> -               erp->ack_consume_time);
> +    rt2x00_set_field32(&reg, TXCSR1_ACK_TIMEOUT, 0x162);
> +    rt2x00_set_field32(&reg, TXCSR1_ACK_CONSUME_TIME, 0xa2);
>      rt2x00_set_field32(&reg, TXCSR1_TSF_OFFSET, IEEE80211_HEADER);
>      rt2x00_set_field32(&reg, TXCSR1_AUTORESPONDER, 1);
>      rt2x00pci_register_write(rt2x00dev, TXCSR1, reg);
>
Comment 27 Alejandro Riveira 2009-09-10 09:56:57 UTC
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, &reg);
-	rt2x00_set_field32(&reg, TXCSR1_ACK_TIMEOUT,
-			   erp->ack_timeout);
-	rt2x00_set_field32(&reg, TXCSR1_ACK_CONSUME_TIME,
-			   erp->ack_consume_time);
+
+/*
+ *	rt2x00_set_field32(&reg, TXCSR1_ACK_TIMEOUT,
+ *			   erp->ack_timeout);
+ *	rt2x00_set_field32(&reg, TXCSR1_ACK_CONSUME_TIME,
+ *			   erp->ack_consume_time);
+ */
+	rt2x00_set_field32(&reg, TXCSR1_ACK_TIMEOUT, 0x162);
+	rt2x00_set_field32(&reg, TXCSR1_ACK_CONSUME_TIME, 0xa2);
 	rt2x00pci_register_write(rt2x00dev, TXCSR1, reg);
 
 	rt2x00pci_register_read(rt2x00dev, ARCSR2, &reg);
Comment 28 Alejandro Riveira 2009-09-10 20:39:37 UTC
Now i switched to 2.6.31 the revert is still needed (not a surprise 
but anyway just FYI).

Alejandro .-
Comment 29 Alejandro Riveira 2009-09-10 22:26:35 UTC
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, &reg);
-	rt2x00_set_field32(&reg, TXCSR1_ACK_TIMEOUT,
-			   erp->ack_timeout);
-	rt2x00_set_field32(&reg, TXCSR1_ACK_CONSUME_TIME,
-			   erp->ack_consume_time);
+
+/*
+ *	rt2x00_set_field32(&reg, TXCSR1_ACK_TIMEOUT,
+ *			   erp->ack_timeout);
+ *	rt2x00_set_field32(&reg, TXCSR1_ACK_CONSUME_TIME,
+ *			   erp->ack_consume_time);
+ */
+	rt2x00_set_field32(&reg, TXCSR1_ACK_TIMEOUT, 0x162);
+	rt2x00_set_field32(&reg, TXCSR1_ACK_CONSUME_TIME, 0xa2);
 	rt2x00pci_register_write(rt2x00dev, TXCSR1, reg);
 
 	rt2x00pci_register_read(rt2x00dev, ARCSR2, &reg);
Comment 30 Foxy 2009-10-22 20:34:22 UTC
I can confirm the bug exists in Ubuntu 9.10 Karmic.
Comment 31 Alejandro Riveira 2009-12-04 15:31:18 UTC
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 :(
Comment 32 David Heidelberg (okias) 2010-01-04 19:53:54 UTC
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
Comment 33 John W. Linville 2010-02-26 16:55:44 UTC
Gertjan, Ivo -- anything more to add here?
Comment 34 Alejandro Riveira 2010-03-06 12:43:11 UTC
Nothing new in 2.6.33; still slow by default and still
the revert fixes it.
Comment 35 yeti 2010-05-07 16:13:20 UTC
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
Comment 36 Foxy 2010-05-09 21:37:44 UTC
No change for me. Lucid as well.
Comment 37 Mohamed Amine IL Idrissi 2010-08-30 22:05:15 UTC
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.
Comment 38 John W. Linville 2010-11-23 16:41:21 UTC
Gertjan and Ivo, ping?
Comment 39 John W. Linville 2011-01-18 18:57:20 UTC
I'm not hearing any other similar reports.  Is this issue still relevant for 2.6.37 or later?
Comment 40 Foxy 2011-01-20 19:50:31 UTC
The kernel has been just released. Let it make its way into any major distro before people report whether the issue is fixed.
Comment 41 John W. Linville 2011-01-20 21:07:51 UTC
Perhaps you could simply test 2.6.37 without waiting? :-)
Comment 42 aeriksson 2011-01-20 21:14:40 UTC
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.
Comment 43 Alejandro Riveira 2011-02-18 11:54:55 UTC
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.
Comment 44 Łukasz Żarnowiecki 2012-07-09 14:42:02 UTC
Still buggy on 3.3.8 with gentoo. Signal is always -100 dbM and constantly losing the connection.
Comment 45 Alan 2015-02-19 15:29:34 UTC
This bug relates to a very old kernel. Closing as obsolete.