I reported it previously but i'm resending it as a regresion
More info on the bugzilla
http://bugzilla.kernel.org/show_bug.cgi?id=13362
I bisected it in the estable tree (it regresses too) and the revert
helps there but reverting the upstream commit in mainline does not help
to fix it completely...
--
Is God willing to prevent evil, but not able? Then he is not omnipotent.
Is he able, but not willing? Then he is malevolent. Is he both able and
willing? Then whence cometh evil? Is he neither able nor willing? Then
why call him God?
Epicurus
On Tuesday 26 May 2009, Alejandro Riveira Fern?ndez wrote:
> El mar, 26-05-2009 a las 10:58 +0200, Ivo van Doorn escribi?:
> > On Monday 25 May 2009, Alejandro Riveira Fern?ndez wrote:
>
> > > Would the output of this script[2] for 2.6.29.4 with and without the
> > > revert help you ?
> >
> > Yes please try it. but for 2.6.29 you probably need attached script instead.
> > I am not sure if it would produce something useful, because I think Johannes
> > assertion is right. With his patch the correct bitmask is send to the driver
> > and the driver actually needs _that_ bitmask without any editing
> > (rather then the incorrect one which was send before that patch).
>
> What causes the regression then?
No idea. Apparently the invalid bitmask is accepted by the device under
certain conditions. Which would be very odd.... But since dozens
of people reported this problem for 2.6.27 as well, it probably depends
heavily on the actual chipset revision or configuration.
> Anyway For the script to work what config options do I need? debugfs?
> Anything else ?
CONFIG_DEBUGFS
CONFIG_MAC80211_DEBUGFS
CONFIG_RT2X00_LIB_DEBUGFS
And thats it, make sure debugfs is mounted and just run the script.
The script will detect mount location and rt2x00 interface.
Ivo
El mar, 26-05-2009 a las 12:35 +0200, Ivo van Doorn escribió:
> > What causes the regression then?
>
> No idea. Apparently the invalid bitmask is accepted by the device under
> certain conditions. Which would be very odd.... But since dozens
> of people reported this problem for 2.6.27 as well, it probably depends
> heavily on the actual chipset revision or configuration.
>
> > Anyway For the script to work what config options do I need? debugfs?
> > Anything else ?
>
> CONFIG_DEBUGFS
> CONFIG_MAC80211_DEBUGFS
> CONFIG_RT2X00_LIB_DEBUGFS
>
> And thats it, make sure debugfs is mounted and just run the script.
> The script will detect mount location and rt2x00 interface.
That's what I get[1] with the good kernel but I think the script failed
because I got a very short output
$ sudo bash rt2x00_regdump.sh | xclip
kernel: 2.6.29.4-00258-ga2c0a36
driver: rt2500pci
version: 2.2.3
compiled: May 26 2009 13:05:03
dev_flags: 0x00000a2f
rt chip: 0201
rf chip: 0003
revision:00000004
csr length: 93
eeprom length: 256
bbp length: 64
rf length: 5
And nothing more...
>
> Ivo
Alejandro
[1] Had to install gawk mawk does not have --posix.
On Monday 25 May 2009, Alejandro Riveira Fern?ndez wrote:
> I reported it previously but i'm resending it as a regresion
>
> More info on the bugzilla
>
> http://bugzilla.kernel.org/show_bug.cgi?id=13362
>
> I bisected it in the estable tree (it regresses too) and the revert
> helps there but reverting the upstream commit in mainline does not help
> to fix it completely...
Bug 9273 - rt2500pci: low TCP throughput
http://bugzilla.kernel.org/show_bug.cgi?id=9273
Bug 443203 - Fedora rawhide + ralink = slow bit rate
https://bugzilla.redhat.com/show_bug.cgi?id=443203
[Hardy][Intrepid] Low bandwidth with rt2400 / rt2500 drivers
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/190515
I can't call this a regression, dozens people have reported the problems
ranging from kernels 2.6.25 to 2.6.29. Perhaps in your case it worked slightly
better once, but that was not the case for all other users.
Have you tried the "iwconfig wlan0 rate54M" workaround?
Ivo
Hi,
> > > What causes the regression then?
> >
> > No idea. Apparently the invalid bitmask is accepted by the device under
> > certain conditions. Which would be very odd.... But since dozens
> > of people reported this problem for 2.6.27 as well, it probably depends
> > heavily on the actual chipset revision or configuration.
> >
> > > Anyway For the script to work what config options do I need? debugfs?
> > > Anything else ?
> >
> > CONFIG_DEBUGFS
> > CONFIG_MAC80211_DEBUGFS
> > CONFIG_RT2X00_LIB_DEBUGFS
> >
> > And thats it, make sure debugfs is mounted and just run the script.
> > The script will detect mount location and rt2x00 interface.
>
>
> That's what I get[1] with the good kernel but I think the script failed
> because I got a very short output
Ok, that means it is the wrong script, try the other one from the download
location you previously refered to. I changed the API some time ago, and
am not sure which stable release that change will be in.
> [1] Had to install gawk mawk does not have --posix.
Right, that was still something I needed to work on. :)
Ivo
El lun, 25-05-2009 a las 13:23 +0200, Ivo van Doorn escribió:
> On Monday 25 May 2009, Alejandro Riveira Fernández wrote:
> > I reported it previously but i'm resending it as a regresion
> >
> > More info on the bugzilla
> >
> > http://bugzilla.kernel.org/show_bug.cgi?id=13362
> >
> > I bisected it in the estable tree (it regresses too) and the revert
> > helps there but reverting the upstream commit in mainline does not help
> > to fix it completely...
>
> Bug 9273 - rt2500pci: low TCP throughput
> http://bugzilla.kernel.org/show_bug.cgi?id=9273
>
> Bug 443203 - Fedora rawhide + ralink = slow bit rate
> https://bugzilla.redhat.com/show_bug.cgi?id=443203
>
> [Hardy][Intrepid] Low bandwidth with rt2400 / rt2500 drivers
> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/190515
>
> I can't call this a regression, dozens people have reported the problems
> ranging from kernels 2.6.25 to 2.6.29. Perhaps in your case it worked slightly
> better once, but that was not the case for all other users.
>
> Have you tried the "iwconfig wlan0 rate54M" workaround?
Yep during various releases I used that workaround but once I
switched to minstrel rate choosing alg (that's the neme isn't it) the
problem gone away and i got allways a good connection for several
releases and many kernels tried; till this patch. If I revert this patch
the problem goes away completly and reliably (i'm using 2.6.29.4 with
the patch reveted) so something has clearly regressed for me.
You can see my coments ( ariveira ) on rt2x00 forums regarding the
issues you mention (low speed that gets fixed forcing the rate) in the
long thread about rt2500pci low rate[1].
Checking the message i see that it was 2.6.27 when i began using
minstrel and got a rock solid connection in 2.6.27.x, 2.6.28.x and
2.6.29 minus 64e1b00c974ddeae6a60ebb02e1c487371905cea
The problem is not that I get a low rate on connect (1Mbit) that i can
easily fix with iwconfig the problem is that with 54M (and 48M and the
like) connections I get a bumpy and low speed connection.
So I honesty think it is not the same issue and I hope you read this as
an interesting data point and not just as a duplicate.
Would the output of this script[2] for 2.6.29.4 with and without the
revert help you ?
>
> Ivo
Thanks for the response
[1]
http://rt2x00.serialmonkey.com/phpBB/viewtopic.php?f=5&t=4579&start=45
[2] http://rt2x00.serialmonkey.com/phpBB/viewtopic.php?f=5&t=4660
On Monday 25 May 2009, Alejandro Riveira Fern?ndez wrote:
> El lun, 25-05-2009 a las 13:23 +0200, Ivo van Doorn escribi?:
> > On Monday 25 May 2009, Alejandro Riveira Fern?ndez wrote:
> > > I reported it previously but i'm resending it as a regresion
> > >
> > > More info on the bugzilla
> > >
> > > http://bugzilla.kernel.org/show_bug.cgi?id=13362
> > >
> > > I bisected it in the estable tree (it regresses too) and the revert
> > > helps there but reverting the upstream commit in mainline does not help
> > > to fix it completely...
> >
> > Bug 9273 - rt2500pci: low TCP throughput
> > http://bugzilla.kernel.org/show_bug.cgi?id=9273
> >
> > Bug 443203 - Fedora rawhide + ralink = slow bit rate
> > https://bugzilla.redhat.com/show_bug.cgi?id=443203
> >
> > [Hardy][Intrepid] Low bandwidth with rt2400 / rt2500 drivers
> > https://bugs.launchpad.net/ubuntu/+source/linux/+bug/190515
> >
> > I can't call this a regression, dozens people have reported the problems
> > ranging from kernels 2.6.25 to 2.6.29. Perhaps in your case it worked slightly
> > better once, but that was not the case for all other users.
> >
> > Have you tried the "iwconfig wlan0 rate54M" workaround?
>
> Yep during various releases I used that workaround but once I
> switched to minstrel rate choosing alg (that's the neme isn't it) the
> problem gone away and i got allways a good connection for several
> releases and many kernels tried; till this patch. If I revert this patch
> the problem goes away completly and reliably (i'm using 2.6.29.4 with
> the patch reveted) so something has clearly regressed for me.
>
> You can see my coments ( ariveira ) on rt2x00 forums regarding the
> issues you mention (low speed that gets fixed forcing the rate) in the
> long thread about rt2500pci low rate[1].
>
> Checking the message i see that it was 2.6.27 when i began using
> minstrel and got a rock solid connection in 2.6.27.x, 2.6.28.x and
> 2.6.29 minus 64e1b00c974ddeae6a60ebb02e1c487371905cea
>
> The problem is not that I get a low rate on connect (1Mbit) that i can
> easily fix with iwconfig the problem is that with 54M (and 48M and the
> like) connections I get a bumpy and low speed connection.
>
> So I honesty think it is not the same issue and I hope you read this as
> an interesting data point and not just as a duplicate.
>
> Would the output of this script[2] for 2.6.29.4 with and without the
> revert help you ?
Yes please try it. but for 2.6.29 you probably need attached script instead.
I am not sure if it would produce something useful, because I think Johannes
assertion is right. With his patch the correct bitmask is send to the driver
and the driver actually needs _that_ bitmask without any editing
(rather then the incorrect one which was send before that patch).
Ivo
El mar, 26-05-2009 a las 10:58 +0200, Ivo van Doorn escribió:
> On Monday 25 May 2009, Alejandro Riveira Fernández wrote:
> > Would the output of this script[2] for 2.6.29.4 with and without the
> > revert help you ?
>
> Yes please try it. but for 2.6.29 you probably need attached script instead.
> I am not sure if it would produce something useful, because I think Johannes
> assertion is right. With his patch the correct bitmask is send to the driver
> and the driver actually needs _that_ bitmask without any editing
> (rather then the incorrect one which was send before that patch).
What causes the regression then?
Anyway For the script to work what config options do I need? debugfs?
Anything else ?
>
> Ivo
--
It's easy to make malloc() return NULL under Windows: there is no fork()
system call, and nobody expects the machine to stay up anyway, so who
cares? When you say "I wrote a program that crashed Windows", people
just stare at you blankly and say "Hey, I got those with the system,
*for free*".
Linus Torvalds
El mar, 26-05-2009 a las 14:45 +0200, Ivo van Doorn escribió:
> Hi,
>
[...]
>
> Ok, that means it is the wrong script, try the other one from the download
> location you previously refered to. I changed the API some time ago, and
> am not sure which stable release that change will be in.
I inline the diff between the two dumps the dumps are attached to the
mail message
--- reg_dump_bad.txt 2009-05-26 17:16:03.078863719 +0200
+++ reg_dump_good.txt 2009-05-26 16:48:07.654117749 +0200
@@ -1,4 +1,4 @@
-kernel: 2.6.29.4-00257-g186f9b1
+kernel: 2.6.29.4-00258-ga2c0a36
driver: rt2500pci
version: 2.2.3
compiled: May 26 2009 13:05:03
@@ -23,14 +23,14 @@
7 :0x00000000
8 :0x000fff86
9 :0x00000980
-10 :0xb90c3000
+10 :0xbe0c8000
11 :0x070409a5
12 :0x06400640
13 :0x000000a0
14 :0x0000000b
15 :0x00000000
-16 :0x498f3f26
-17 :0x00000078
+16 :0xe59c4b51
+17 :0x00000077
18 :0x0013000a
19 :0x0156001c
20 :0x000005a0
@@ -38,26 +38,26 @@
22 :0x00000000
23 :0x00000000
24 :0x00000000
-25 :0x01614504
+25 :0x01603b04
26 :0x1808182c
-27 :0xb914b000
-28 :0xb9149000
-29 :0xb90bf000
-30 :0xb914a000
+27 :0xbe044000
+28 :0xbe9f4000
+29 :0xbebae000
+30 :0xbebc8000
31 :0x00000000
32 :0x0000007e
33 :0x0000182c
-34 :0xb90c3000
+34 :0xbe0c8000
35 :0x000003b8
36 :0xb3aab3af
37 :0x86870885
38 :0x8c8d8b8a
-39 :0x0000000f
-40 :0x00000000
+39 :0x00000f0f
+40 :0x00000001
41 :0x00000000
42 :0x0000009c
-43 :0x000033f7
-44 :0x0000028e
+43 :0x00000007
+44 :0x00000000
45 :0x0003ffff
46 :0x00000000
47 :0x00000000
@@ -70,25 +70,25 @@
54 :0x000001fe
55 :0x1aa83f21
56 :0x00213223
-57 :0x00000518
+57 :0x00000218
58 :0x9a009a11
59 :0x00000000
60 :0x00001150
61 :0x14062411
62 :0x00011e46
63 :0x0000c78f
-64 :0xb90c323c
-65 :0xb914b1b8
-66 :0xb90bf160
-67 :0xb9149000
+64 :0xbe0c82c0
+65 :0xbe044134
+66 :0xbebae1e4
+67 :0xbe9f4000
68 :0x00000020
-69 :0x00000001
-70 :0x000000f5
+69 :0x0000000d
+70 :0x000000d7
71 :0x000000aa
72 :0x00000001
73 :0x00000001
74 :0x00000000
-75 :0x0000381c
+75 :0x000363b1
76 :0x000500f0
77 :0x00000040
78 :0x000000f0
@@ -99,7 +99,7 @@
83 :0x7038140a
84 :0x1d21252d
85 :0x1919191d
-86 :0xb914b000
+86 :0xbe044000
87 :0x821a8202
88 :0x00000003
89 :0x00000000
@@ -367,13 +367,13 @@
bbp
0 :0x12
-1 :0xf3
-2 :0x02
+1 :0xe6
+2 :0x1a
3 :0x02
4 :0x19
-5 :0x0b
-6 :0x00
-7 :0x0e
+5 :0x08
+6 :0x01
+7 :0x2c
8 :0x00
9 :0x00
10 :0x09
@@ -409,16 +409,16 @@
40 :0x02
41 :0x60
42 :0x09
-43 :0x02
-44 :0x76
+43 :0x00
+44 :0x4e
45 :0x00
-46 :0x2d
+46 :0x5a
47 :0x14
48 :0x00
49 :0x01
50 :0x98
-51 :0x40
-52 :0x6e
+51 :0x3c
+52 :0x04
53 :0x10
54 :0x18
55 :0x05
>
> > [1] Had to install gawk mawk does not have --posix.
>
> Right, that was still something I needed to work on. :)
>
> Ivo
Alejandro
--
> All is fine except that I can reliably "oops" it simply by trying to
> read from /proc/apm (e.g. cat /proc/apm).
> oops output and ksymoops-2.3.4 output is attached.
> Is there anything else I can contribute?
The latitude and longtitude of the bios writers current position, and
a ballistic missile.
--Alan Cox LKML-December 08,2000
El mar, 02-06-2009 a las 23:53 +0200, Ivo van Doorn escribió:
> > So my chip works better with incorrect values written in its registers?
>
> Apparently, probably because some other register is set to an incorrect value,
> but I have no idea which one that would be.
Could the fact that i dual boot with windows (and use the windows
driver) have someting to do with it ?
>
> > What about other chips out there do they prefer wrong values too ;)
> > Maybe what we thought wrong values are not that wrong ?
>
> They are wrong. That exact register initialization is pretty straightforward
> in the original Ralink driver on which rt2x00 is based.
>
> Ivo
--
"I contend that we are both atheists. I just believe in one fewer god
than you do. When you understand why you dismiss all the other possible
gods, you will understand why I dismiss yours."
Stephen Henry Roberts
On Tuesday 02 June 2009, Alejandro Riveira Fern?ndez wrote:
> El mar, 02-06-2009 a las 18:34 +0200, Ivo van Doorn escribi?:
> > On Tuesday 02 June 2009, Alejandro Riveira Fern?ndez wrote:
>
> [...]
>
> > > ICMP ECHO REQUEST
> > >
> > > Any advance?
> >
> > Well I checked the dumps from the bugreport, but like I expected
> > the only difference is that with the slow speed the correct value
> > is written, and the fast speed the wrong value is written.
>
> So my chip works better with incorrect values written in its registers?
Apparently, probably because some other register is set to an incorrect value,
but I have no idea which one that would be.
> What about other chips out there do they prefer wrong values too ;)
> Maybe what we thought wrong values are not that wrong ?
They are wrong. That exact register initialization is pretty straightforward
in the original Ralink driver on which rt2x00 is based.
Ivo
On Tuesday 02 June 2009, Alejandro Riveira Fern?ndez wrote:
> El mar, 26-05-2009 a las 17:23 +0200, Alejandro Riveira Fern?ndez
> escribi?:
> > El mar, 26-05-2009 a las 14:45 +0200, Ivo van Doorn escribi?:
> > > Hi,
> > >
> > [...]
> > >
> > > Ok, that means it is the wrong script, try the other one from the download
> > > location you previously refered to. I changed the API some time ago, and
> > > am not sure which stable release that change will be in.
> >
> > I inline the diff between the two dumps the dumps are attached to the
> > mail message
>
> ICMP ECHO REQUEST
>
> Any advance?
Well I checked the dumps from the bugreport, but like I expected
the only difference is that with the slow speed the correct value
is written, and the fast speed the wrong value is written.
I couldn't find anything else interesting in it... :(
Ivo
El mar, 26-05-2009 a las 17:23 +0200, Alejandro Riveira Fernández
escribió:
> El mar, 26-05-2009 a las 14:45 +0200, Ivo van Doorn escribió:
> > Hi,
> >
> [...]
> >
> > Ok, that means it is the wrong script, try the other one from the download
> > location you previously refered to. I changed the API some time ago, and
> > am not sure which stable release that change will be in.
>
> I inline the diff between the two dumps the dumps are attached to the
> mail message
ICMP ECHO REQUEST
Any advance?
>
>
> --- reg_dump_bad.txt 2009-05-26 17:16:03.078863719 +0200
> +++ reg_dump_good.txt 2009-05-26 16:48:07.654117749 +0200
> @@ -1,4 +1,4 @@
> -kernel: 2.6.29.4-00257-g186f9b1
> +kernel: 2.6.29.4-00258-ga2c0a36
> driver: rt2500pci
> version: 2.2.3
> compiled: May 26 2009 13:05:03
[...]
> Alejandro
--
The idea that Bill Gates has appeared like a knight in shining armour to
lead all customers out of a mire of technological chaos neatly ignores
the fact that it was he who, by peddling second-rate technology, led
them into it in the first place.
Douglas Adams
El mar, 02-06-2009 a las 18:34 +0200, Ivo van Doorn escribió:
> On Tuesday 02 June 2009, Alejandro Riveira Fernández wrote:
[...]
> > ICMP ECHO REQUEST
> >
> > Any advance?
>
> Well I checked the dumps from the bugreport, but like I expected
> the only difference is that with the slow speed the correct value
> is written, and the fast speed the wrong value is written.
So my chip works better with incorrect values written in its registers?
/me confused
What about other chips out there do they prefer wrong values too ;)
Maybe what we thought wrong values are not that wrong ?
/me stops rambling
> I couldn't find anything else interesting in it... :(
Thanks anyway.
>
> Ivo
--
OOP to me means only messaging, local retention and protection and
hiding of state-process, and extreme late-binding of all things. It can
be done in Smalltalk and in LISP. There are possibly other systems in
which this is possible, but I'm not aware of them.
-- Alan Kay --
On Wednesday 03 June 2009, Alejandro Riveira Fern?ndez wrote:
> El mar, 02-06-2009 a las 23:53 +0200, Ivo van Doorn escribi?:
>
> > > So my chip works better with incorrect values written in its registers?
> >
> > Apparently, probably because some other register is set to an incorrect value,
> > but I have no idea which one that would be.
>
> Could the fact that i dual boot with windows (and use the windows
> driver) have someting to do with it ?
Don't think so, unless you notice a difference in behavior when you reboot
from Windows to Linux compared to making a cold-boot or reboot from Linux
to Linux.
Ivo