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
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.
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.