Hello
Is the last kernel code working with RaLink RT2500 802.11g Cardbus/mini-PCI?
In my machine don't work, but with the serialmonkey driver is well.
(http://rt2x00.serialmonkey.com/rt2500-cvs-daily.tar.gz)
Somebody can help me to configure the rt2x00 driver in order to run
ieee80211 module.
Thanks
FMAY
The configuration (kernel 2.6.23.1) seems OK (mac80211 132112 4
rc80211_simple,rt2500pci,rt2x00pci,rt2x00lib), but when I try to connect
with another machine in a simples Ad-Hoc mode, don't transmit anything,
remaining invisible with 'iwlist scan' command. While with the
serialmonkey driver run OK.
> Hi,
>
>> Is the last kernel code working with RaLink RT2500 802.11g
>> Cardbus/mini-PCI?
>
> With 'latest' do you mean:
> latest 2.6.25-rc kernel?
> latest wireless-testing git snapshot
> latest rt2x00 git snapshot
>
> The latter 2 should work fine, the first one has known issues
> but the state variates per person.
>
>> In my machine don't work, but with the serialmonkey driver is well.
>>
>> (http://rt2x00.serialmonkey.com/rt2500-cvs-daily.tar.gz)
>>
>> Somebody can help me to configure the rt2x00 driver in order to run
>> ieee80211 module.
>
> How are you configuring the interface?
> What tools are you using?
> Do you get error messages?
> Is there any other information that might be usefull for understanding
> this bug?
>
> Ivo
>
>
Hi,
> Is the last kernel code working with RaLink RT2500 802.11g Cardbus/mini-PCI?
With 'latest' do you mean:
latest 2.6.25-rc kernel?
latest wireless-testing git snapshot
latest rt2x00 git snapshot
The latter 2 should work fine, the first one has known issues
but the state variates per person.
> In my machine don't work, but with the serialmonkey driver is well.
>
> (http://rt2x00.serialmonkey.com/rt2500-cvs-daily.tar.gz)
>
> Somebody can help me to configure the rt2x00 driver in order to run
> ieee80211 module.
How are you configuring the interface?
What tools are you using?
Do you get error messages?
Is there any other information that might be usefull for understanding this bug?
Ivo
On Wednesday 02 April 2008, Thomas B=E4chler wrote:
> Ivo van Doorn schrieb:
> > Hi,
> >=20
> >>>> Is the last kernel code working with RaLink RT2500 802.11g Cardb=
us/mini-PCI?
> >>> With 'latest' do you mean:
> >>> latest 2.6.25-rc kernel?
> >>> latest wireless-testing git snapshot
> >>> latest rt2x00 git snapshot
> >>>
> >>> The latter 2 should work fine, the first one has known issues
> >>> but the state variates per person.
> >> I was complaining about speed a while ago, so after reading this p=
ost, I=20
> >> thought I should try again and tell you:
> >>
> >> The version in wireless-testing seems to work great, a test downlo=
ad=20
> >> gave me 1.24MB/s, which is about the same speed I get with my (Int=
el=20
> >> wireless) laptop. I am using rt2500pci.
> >>
> >> Does the above mean that the stock driver in 2.6.25 will still be =
slow?
> >=20
> > Most likely yes.
> > Although I hear mixed reports, some say it depends on the rate sele=
ction
> > algorithm, some claim rt2x00 in 2.6.24 is faster then wireless-test=
ing and
> > others claim the exact opposite.
> > At the moment it is hard to tell, but I haven't collected data yet =
with specific
> > information about the used rate selection module and exact data tra=
nsfer
> > numbers.
> >=20
> > Ivo
> >=20
>=20
> I rebuilt 2.6.25-rc8 (again) to use the 'simple' algorithm instead of=
=20
> the 'PID' algorithm by default. rt2500pci is still fast!
Good to hear. :)
Thanks for the test.
Ivo
Ivo van Doorn schrieb:
>> Bad news again:
>>
>> With 2.6.25-rc8, rt2500pci is fast. When I apply this patch:
>> ftp://ftp.kernel.org/pub/linux/kernel/v2.6/snapshots/patch-2.6.25-rc8-git8.bz2
>> on top of rc8, then it is slow again. I can't make sense of it, maybe
>> you can.
>
> Not really, looking at that patchset neither rt2x00 or mac80211 had any patches
> that could influence packet flow.. :S
>
> Ivo
I compiled half a dozen kernels and now figured it out. This is the
patch that causes rt2500pci to be slow. If I revert it, it is fast again:
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=d43c7b37ad787173d08683f05eadeea0398fefdf
I'd love to see this fixed before 2.6.25 is released, as it's a
regression compared to -rc8.
Ivo van Doorn schrieb:
>>>> Does the above mean that the stock driver in 2.6.25 will still be slow?
>>> Most likely yes.
>>> Although I hear mixed reports, some say it depends on the rate selection
>>> algorithm, some claim rt2x00 in 2.6.24 is faster then wireless-testing and
>>> others claim the exact opposite.
>>> At the moment it is hard to tell, but I haven't collected data yet with specific
>>> information about the used rate selection module and exact data transfer
>>> numbers.
>>>
>>> Ivo
>>>
>> I rebuilt 2.6.25-rc8 (again) to use the 'simple' algorithm instead of
>> the 'PID' algorithm by default. rt2500pci is still fast!
>
> Good to hear. :)
>
> Thanks for the test.
>
> Ivo
Bad news again:
With 2.6.25-rc8, rt2500pci is fast. When I apply this patch:
ftp://ftp.kernel.org/pub/linux/kernel/v2.6/snapshots/patch-2.6.25-rc8-git8.bz2
on top of rc8, then it is slow again. I can't make sense of it, maybe
you can.
Hi,
> The configuration (kernel 2.6.23.1) seems OK (mac80211 132112 4
> rc80211_simple,rt2500pci,rt2x00pci,rt2x00lib),
I still have the same question, what version?
kernel 2.6.23 does not contain rt2x00, so what version are you using?
> but when I try to connect
> with another machine in a simples Ad-Hoc mode, don't transmit anything,
> remaining invisible with 'iwlist scan' command. While with the
> serialmonkey driver run OK.
Again same questions:
How are you configuring the interface?
What tools are you using?
Do you get an error messages?
Is there any other information that might be useful for understanding this bug?
Ivo
Le Wed, 2 Apr 2008 08:05:54 -0300 (BRT),
"Felipe Maya" <[email protected]> a =C3=A9crit :
> filename: =20
> /lib/modules/2.6.23.1/kernel/drivers/net/wireless/rt2x00/rt2500pci.ko
> license: GPL
> description: Ralink RT2500 PCI & PCMCIA Wireless LAN driver.
> version: 2.0.8
> author: http://rt2x00.serialmonkey.com
> srcversion: C8DB886C372334BFB58A7F5
> alias: pci:v00001814d00000201sv*sd*bc*sc*i*
> depends: rt2x00pci,rt2x00lib,mac80211,eeprom_93cx6
> vermagic: 2.6.23.1 SMP mod_unload 686 4KSTACKS
Don't tell me, tell the list.
Even then, I am not sure this is enough info to help you, since there
are no obvious error messages.
Maybe this is simply ad-hoc mode being broken in rt2x00, I think this
code is too new. You could try with a way more recent kernel
(the wireless-testing tree suggested above), or check that the legacy
driver does ad-hoc (I think it does).
Ivo van Doorn schrieb:
> Hi,
>
>>>> Is the last kernel code working with RaLink RT2500 802.11g Cardbus/mini-PCI?
>>> With 'latest' do you mean:
>>> latest 2.6.25-rc kernel?
>>> latest wireless-testing git snapshot
>>> latest rt2x00 git snapshot
>>>
>>> The latter 2 should work fine, the first one has known issues
>>> but the state variates per person.
>> I was complaining about speed a while ago, so after reading this post, I
>> thought I should try again and tell you:
>>
>> The version in wireless-testing seems to work great, a test download
>> gave me 1.24MB/s, which is about the same speed I get with my (Intel
>> wireless) laptop. I am using rt2500pci.
>>
>> Does the above mean that the stock driver in 2.6.25 will still be slow?
>
> Most likely yes.
> Although I hear mixed reports, some say it depends on the rate selection
> algorithm, some claim rt2x00 in 2.6.24 is faster then wireless-testing and
> others claim the exact opposite.
> At the moment it is hard to tell, but I haven't collected data yet with specific
> information about the used rate selection module and exact data transfer
> numbers.
>
> Ivo
>
Okay, I tried again with 2.6.25-rc8 from linux-2.6 git. Speed is still
great. However, with both wireless-testing and linux-2.6 I seem to be
using the 'pid' algorithm:
phy0: Selected rate control algorithm 'pid'
With 2.6.24 I seem to be using the 'simple' rate control algorithm. I
don't know how to switch rate control algorithms without rebuilding
though, so I can't test 'simple' with 2.6.25.
Hi,
> >> Is the last kernel code working with RaLink RT2500 802.11g Cardbus/mini-PCI?
> >
> > With 'latest' do you mean:
> > latest 2.6.25-rc kernel?
> > latest wireless-testing git snapshot
> > latest rt2x00 git snapshot
> >
> > The latter 2 should work fine, the first one has known issues
> > but the state variates per person.
>
> I was complaining about speed a while ago, so after reading this post, I
> thought I should try again and tell you:
>
> The version in wireless-testing seems to work great, a test download
> gave me 1.24MB/s, which is about the same speed I get with my (Intel
> wireless) laptop. I am using rt2500pci.
>
> Does the above mean that the stock driver in 2.6.25 will still be slow?
Most likely yes.
Although I hear mixed reports, some say it depends on the rate selection
algorithm, some claim rt2x00 in 2.6.24 is faster then wireless-testing and
others claim the exact opposite.
At the moment it is hard to tell, but I haven't collected data yet with specific
information about the used rate selection module and exact data transfer
numbers.
Ivo
> How are you configuring the interface?
> What tools are you using?
ifconfig wlan0 up
iwconfig wlan0 essid COLOMBIA mode Ad-Hoc channel 3
ifconfig wlan0 192.168.1.1 netmask 255.255.255.0
> Do you get an error messages?
No errors, zero Tx
> Is there any other information that might be useful for understanding this
> bug?
//cat /proc/net/wireless
Inter-| sta-| Quality | Discarded packets |
Missed | WE
face | tus | link level noise | nwid crypt frag retry misc |
beacon | 22
wlan0: 0000 0 0 0 0 0 0 0 0 0
//cat /proc/net/arp
IP address HW type Flags HW address Mask
Device
201.36.161.1 0x1 0x2 00:05:5F:EA:1C:54 * eth0
//common dmesg
wlan0: Trigger new scan to find an IBSS to join
wlan0: no IPv6 routers present
wlan0: Creating new IBSS network, BSSID 6e:fb:bb:15:2d:9d
wlan0: Configured IBSS beacon template based on scan results
wlan0: No active IBSS STAs - trying to scan for other IBSS networks with
same SSID (merge)
Ivo van Doorn schrieb:
>> Is the last kernel code working with RaLink RT2500 802.11g Cardbus/mini-PCI?
>
> With 'latest' do you mean:
> latest 2.6.25-rc kernel?
> latest wireless-testing git snapshot
> latest rt2x00 git snapshot
>
> The latter 2 should work fine, the first one has known issues
> but the state variates per person.
I was complaining about speed a while ago, so after reading this post, I
thought I should try again and tell you:
The version in wireless-testing seems to work great, a test download
gave me 1.24MB/s, which is about the same speed I get with my (Intel
wireless) laptop. I am using rt2500pci.
Does the above mean that the stock driver in 2.6.25 will still be slow?
Hi,
> "Felipe Maya" <[email protected]> a =E9crit :
> > filename:
> > /lib/modules/2.6.23.1/kernel/drivers/net/wireless/rt2x00/rt2500pci=
=2Eko
> > license: GPL
> > description: Ralink RT2500 PCI & PCMCIA Wireless LAN driver.
> > version: 2.0.8
I don't know where you pulled this kernel from, but this must be a kern=
el
belonging to a particular distro, since rt2x00 was not included in
kernel 2.6.23.
The initial release in 2.6.24 had adhoc mode disabled because it was kn=
own
to be broken, apparently that patch was missing from the version your d=
istro
included.
I would recommend grabbing either wireless-testing.git or rt2x00.git
which contains
the latest version of rt2x00 where adhoc mode has been enabled again
(for testing).
Using 2.6.24 or 2.6.25 won't help since adhoc is disabled in both kerne=
ls.
Another option would be using the legacy drivers which can also handle =
adhoc and
support older kernels.
Ivo
Johannes Berg schrieb:
> Even using use_short_preamble wrongly shouldn't give much of a drop in
> network speed. I fear there's another bug. Is your AP even
> short-preamble capable? Maybe that's the problem, your AP isn't
> announcing short preamble but we're enabling it by that code? I haven't
> looked in too much detail yet though.
It's a WRT54GL, so I suppose it supports it. On my laptop (iwl3945), I get
wlan0: switched to short barker preamble (BSSID=00:1d:7e:43:14:a7)
after connecting to the wireless and everything is still okay and fast.
On Tue, 01 Apr 2008 10:51:36 +0200, Ivo Van Doorn said:
> Hi,
>
>> The configuration (kernel 2.6.23.1) seems OK (mac80211 132112 4
>> rc80211_simple,rt2500pci,rt2x00pci,rt2x00lib),
>
> I still have the same question, what version? kernel 2.6.23 does not
> contain rt2x00, so what version are you using?
modinfo rt2500pci is a good command to type.
> Short preamble actually gives you quite better throughput, you are
> cutting 96 usec from each packet.
Right, but it doesn't really get to "unusable". Depends on your
definition of usable I guess, but with typical internet connection
speeds being usually around 1-10mbit (at least around here)...
johannes
Ivo van Doorn schrieb:
>>> No, wait, I'm confused, the original patch is correct. As far as I can
>>> tell, the code there is correct. The bug in that code was actually
>>> introduced by me based on the wrong thinking I just did again.
>> I figured as much from the original commit message. So rt2500pci works
>> properly when the use_short_preamble has the wrong value, and breaks
>> when it has the right one.
>> By the way, 2.6.25-rc8 was the first time that rt2500pci was ever fast
>> enough to be usable at all for me, so the bug you introduced seemed to
>> be the fix for my speed problems (which is odd). My guess is that
>> rt2500pci treats use_short_preamble wrong.
>
> Could you test this with the below patch?
> This enables short_preamble for all rt2x00 drivers regardless of what mac80211 issues.
What tree is this against? It doesn't apply to linux-2.6.git
(2.6.25-rc9), which was the one I was talking about all the time. I did
not test the wireless-testing or rt2x00 tree.
On Sat, 2008-04-12 at 19:54 +0200, Thomas Bächler wrote:
> Ivo van Doorn schrieb:
> >> Bad news again:
> >>
> >> With 2.6.25-rc8, rt2500pci is fast. When I apply this patch:
> >> ftp://ftp.kernel.org/pub/linux/kernel/v2.6/snapshots/patch-2.6.25-rc8-git8.bz2
> >> on top of rc8, then it is slow again. I can't make sense of it, maybe
> >> you can.
> >
> > Not really, looking at that patchset neither rt2x00 or mac80211 had any patches
> > that could influence packet flow.. :S
> >
> > Ivo
>
> I compiled half a dozen kernels and now figured it out. This is the
> patch that causes rt2500pci to be slow. If I revert it, it is fast again:
> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=d43c7b37ad787173d08683f05eadeea0398fefdf
>
> I'd love to see this fixed before 2.6.25 is released, as it's a
> regression compared to -rc8.
That's odd. But that patch looks a bit fishy now that I look at it, care
to try below change (manually, this isn't a patch)?
johannes
bool use_protection = (erp_value & WLAN_ERP_USE_PROTECTION) != 0;
- bool use_short_preamble = (erp_value & WLAN_ERP_BARKER_PREAMBLE) == 0;
+ bool use_short_preamble = (erp_value & WLAN_ERP_BARKER_PREAMBLE) != 0;
DECLARE_MAC_BUF(mac);
> I figured as much from the original commit message. So rt2500pci works
> properly when the use_short_preamble has the wrong value, and breaks
> when it has the right one.
> By the way, 2.6.25-rc8 was the first time that rt2500pci was ever fast
> enough to be usable at all for me, so the bug you introduced seemed to
> be the fix for my speed problems (which is odd). My guess is that
> rt2500pci treats use_short_preamble wrong.
Even using use_short_preamble wrongly shouldn't give much of a drop in
network speed. I fear there's another bug. Is your AP even
short-preamble capable? Maybe that's the problem, your AP isn't
announcing short preamble but we're enabling it by that code? I haven't
looked in too much detail yet though.
johannes
On Friday 11 April 2008, Thomas B=E4chler wrote:
> Ivo van Doorn schrieb:
> >>>> Does the above mean that the stock driver in 2.6.25 will still b=
e slow?
> >>> Most likely yes.
> >>> Although I hear mixed reports, some say it depends on the rate se=
lection
> >>> algorithm, some claim rt2x00 in 2.6.24 is faster then wireless-te=
sting and
> >>> others claim the exact opposite.
> >>> At the moment it is hard to tell, but I haven't collected data ye=
t with specific
> >>> information about the used rate selection module and exact data t=
ransfer
> >>> numbers.
> >>>
> >>> Ivo
> >>>
> >> I rebuilt 2.6.25-rc8 (again) to use the 'simple' algorithm instead=
of=20
> >> the 'PID' algorithm by default. rt2500pci is still fast!
> >=20
> > Good to hear. :)
> >=20
> > Thanks for the test.
> >=20
> > Ivo
>=20
> Bad news again:
>=20
> With 2.6.25-rc8, rt2500pci is fast. When I apply this patch:
> ftp://ftp.kernel.org/pub/linux/kernel/v2.6/snapshots/patch-2.6.25-rc8=
-git8.bz2
> on top of rc8, then it is slow again. I can't make sense of it, maybe=
=20
> you can.
Not really, looking at that patchset neither rt2x00 or mac80211 had any=
patches
that could influence packet flow.. :S
Ivo
On Sunday 13 April 2008, Thomas B=C3=A4chler wrote:
> Johannes Berg schrieb:
> >>> I compiled half a dozen kernels and now figured it out. This is t=
he=20
> >>> patch that causes rt2500pci to be slow. If I revert it, it is fas=
t again:
> >>> http://git.kernel.org/?p=3Dlinux/kernel/git/torvalds/linux-2.6.gi=
t;a=3Dcommitdiff;h=3Dd43c7b37ad787173d08683f05eadeea0398fefdf
> >=20
> >> That's odd. But that patch looks a bit fishy now that I look at it=
, care
> >> to try below change (manually, this isn't a patch)?
> >>
> >> johannes
> >>
> >> bool use_protection =3D (erp_value & WLAN_ERP_USE_PROTECTI=
ON) !=3D 0;
> >> - bool use_short_preamble =3D (erp_value & WLAN_ERP_BARKER_P=
REAMBLE) =3D=3D 0;
> >> =EF=BB=BF=EF=BB=BF+ bool use_short_preamble =3D (erp_value &=
WLAN_ERP_BARKER_PREAMBLE) !=3D 0;
> >> DECLARE_MAC_BUF(mac);
> >=20
> > No, wait, I'm confused, the original patch is correct. As far as I =
can
> > tell, the code there is correct. The bug in that code was actually
> > introduced by me based on the wrong thinking I just did again.
>=20
> I figured as much from the original commit message. So rt2500pci work=
s=20
> properly when the use_short_preamble has the wrong value, and breaks=20
> when it has the right one.
> By the way, 2.6.25-rc8 was the first time that rt2500pci was ever fas=
t=20
> enough to be usable at all for me, so the bug you introduced seemed t=
o=20
> be the fix for my speed problems (which is odd). My guess is that=20
> rt2500pci treats use_short_preamble wrong.
Could you test this with the below patch?
This enables short_preamble for all rt2x00 drivers regardless of what m=
ac80211 issues.
---
diff --git a/drivers/net/wireless/rt2x00/rt2x00config.c b/drivers/net/w=
ireless/rt2x00/rt2x00config.c
index a9930a0..1c24f5a 100644
--- a/drivers/net/wireless/rt2x00/rt2x00config.c
+++ b/drivers/net/wireless/rt2x00/rt2x00config.c
@@ -83,7 +83,7 @@ void rt2x00lib_config_erp(struct rt2x00_dev *rt2x00de=
v,
=20
memset(&erp, 0, sizeof(erp));
=20
- erp.short_preamble =3D bss_conf->use_short_preamble;
+ erp.short_preamble =3D 1;
erp.ack_timeout =3D PLCP + get_duration(ACK_SIZE, 10);
erp.ack_consume_time =3D SIFS + PLCP + get_duration(ACK_SIZE, 10);
=20
@@ -92,7 +92,7 @@ void rt2x00lib_config_erp(struct rt2x00_dev *rt2x00de=
v,
else
erp.ack_timeout +=3D DIFS;
=20
- if (bss_conf->use_short_preamble) {
+ if (1) {
erp.ack_timeout +=3D SHORT_PREAMBLE;
erp.ack_consume_time +=3D SHORT_PREAMBLE;
} else {
> > I compiled half a dozen kernels and now figured it out. This is the
> > patch that causes rt2500pci to be slow. If I revert it, it is fast again:
> > http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=d43c7b37ad787173d08683f05eadeea0398fefdf
> That's odd. But that patch looks a bit fishy now that I look at it, care
> to try below change (manually, this isn't a patch)?
>
> johannes
>
> bool use_protection = (erp_value & WLAN_ERP_USE_PROTECTION) != 0;
> - bool use_short_preamble = (erp_value & WLAN_ERP_BARKER_PREAMBLE) == 0;
> + bool use_short_preamble = (erp_value & WLAN_ERP_BARKER_PREAMBLE) != 0;
> DECLARE_MAC_BUF(mac);
No, wait, I'm confused, the original patch is correct. As far as I can
tell, the code there is correct. The bug in that code was actually
introduced by me based on the wrong thinking I just did again.
johannes
On Monday 14 April 2008, Thomas B=E4chler wrote:
> Ivo van Doorn schrieb:
> >>> No, wait, I'm confused, the original patch is correct. As far as =
I can
> >>> tell, the code there is correct. The bug in that code was actuall=
y
> >>> introduced by me based on the wrong thinking I just did again.
> >> I figured as much from the original commit message. So rt2500pci w=
orks=20
> >> properly when the use_short_preamble has the wrong value, and brea=
ks=20
> >> when it has the right one.
> >> By the way, 2.6.25-rc8 was the first time that rt2500pci was ever =
fast=20
> >> enough to be usable at all for me, so the bug you introduced seeme=
d to=20
> >> be the fix for my speed problems (which is odd). My guess is that=20
> >> rt2500pci treats use_short_preamble wrong.
> >=20
> > Could you test this with the below patch?
> > This enables short_preamble for all rt2x00 drivers regardless of wh=
at mac80211 issues.
>=20
> What tree is this against? It doesn't apply to linux-2.6.git=20
> (2.6.25-rc9), which was the one I was talking about all the time. I d=
id=20
> not test the wireless-testing or rt2x00 tree.
Hmm, it was against the rt2x00.git tree (which means it should apply to=
wireless-testing,
wireless-2.6.26 and the -mm tree).
Anyway it doesn't matter at this time, could you try below patch instea=
d?
I found 1 irregularity in the handling of preamble settings compared to=
the legacy code.
(This patch is against latest linux-2.6.git)
---
diff --git a/drivers/net/wireless/rt2x00/rt2500pci.c b/drivers/net/wire=
less/rt2x00/rt2500pci.c
index 91e87b5..9a87e83 100644
--- a/drivers/net/wireless/rt2x00/rt2500pci.c
+++ b/drivers/net/wireless/rt2x00/rt2500pci.c
@@ -309,7 +309,7 @@ static void rt2500pci_config_preamble(struct rt2x00=
_dev *rt2x00dev,
rt2x00pci_register_write(rt2x00dev, TXCSR1, reg);
=20
rt2x00pci_register_read(rt2x00dev, ARCSR2, ®);
- rt2x00_set_field32(®, ARCSR2_SIGNAL, 0x00 | preamble_mask);
+ rt2x00_set_field32(®, ARCSR2_SIGNAL, 0x00);
rt2x00_set_field32(®, ARCSR2_SERVICE, 0x04);
rt2x00_set_field32(®, ARCSR2_LENGTH, get_duration(ACK_SIZE, 10));
rt2x00pci_register_write(rt2x00dev, ARCSR2, reg);
Ivo van Doorn schrieb:
> Hi,
>
>>>> Is the last kernel code working with RaLink RT2500 802.11g Cardbus/mini-PCI?
>>> With 'latest' do you mean:
>>> latest 2.6.25-rc kernel?
>>> latest wireless-testing git snapshot
>>> latest rt2x00 git snapshot
>>>
>>> The latter 2 should work fine, the first one has known issues
>>> but the state variates per person.
>> I was complaining about speed a while ago, so after reading this post, I
>> thought I should try again and tell you:
>>
>> The version in wireless-testing seems to work great, a test download
>> gave me 1.24MB/s, which is about the same speed I get with my (Intel
>> wireless) laptop. I am using rt2500pci.
>>
>> Does the above mean that the stock driver in 2.6.25 will still be slow?
>
> Most likely yes.
> Although I hear mixed reports, some say it depends on the rate selection
> algorithm, some claim rt2x00 in 2.6.24 is faster then wireless-testing and
> others claim the exact opposite.
> At the moment it is hard to tell, but I haven't collected data yet with specific
> information about the used rate selection module and exact data transfer
> numbers.
>
> Ivo
>
I rebuilt 2.6.25-rc8 (again) to use the 'simple' algorithm instead of
the 'PID' algorithm by default. rt2500pci is still fast!
Johannes Berg schrieb:
>>> I compiled half a dozen kernels and now figured it out. This is the
>>> patch that causes rt2500pci to be slow. If I revert it, it is fast again:
>>> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=d43c7b37ad787173d08683f05eadeea0398fefdf
>
>> That's odd. But that patch looks a bit fishy now that I look at it, care
>> to try below change (manually, this isn't a patch)?
>>
>> johannes
>>
>> bool use_protection = (erp_value & WLAN_ERP_USE_PROTECTION) != 0;
>> - bool use_short_preamble = (erp_value & WLAN_ERP_BARKER_PREAMBLE) == 0;
>> + bool use_short_preamble = (erp_value & WLAN_ERP_BARKER_PREAMBLE) != 0;
>> DECLARE_MAC_BUF(mac);
>
> No, wait, I'm confused, the original patch is correct. As far as I can
> tell, the code there is correct. The bug in that code was actually
> introduced by me based on the wrong thinking I just did again.
I figured as much from the original commit message. So rt2500pci works
properly when the use_short_preamble has the wrong value, and breaks
when it has the right one.
By the way, 2.6.25-rc8 was the first time that rt2500pci was ever fast
enough to be usable at all for me, so the bug you introduced seemed to
be the fix for my speed problems (which is odd). My guess is that
rt2500pci treats use_short_preamble wrong.