I just tried the rt2500pci driver version 2.0.9 from the wireless-2.6 tree.
It does not work. There is no connection, and "iwlist scan" produces no
scan results.
I'm successfully using version 2.0.7 from wireless-dev (2.6.23-rc3 i386) on
this LG laptop.
Marcus
Ivo van Doorn wrote:
> Patch added below.
Kind-of works. I can connect but only at 1 Mb according to iwconfig.
>> printk(KERN_DEBUG "selected mode %d\n", local->oper_hw_mode->mode);
>> printk(KERN_DEBUG "select channel %d\n", local->oper_channel);
Oct 12 10:47:23 better kernel: selected mode 2
Oct 12 10:47:23 better kernel: select channel -539241232
Marcus
[CC list trimmed.]
Ivo van Doorn wrote:
> Could you enable debugfs and use attached debugfs script to create a dump
> of the rt2x00 registers. Preferably a dump of both the rt2x00 2.0.7 and
> 2.0.9 versions.
Here's a dump with 2.0.10 from current wireless-2.6 (kernel 2.6.23) to
start with. However I forgot to include your mode setting patch so it
doesn't associate. More to follow later.
Marcus
Johannes Berg wrote:
> On Mon, 2007-10-15 at 09:04 +0200, Marcus Better wrote:
>> The new patch doesn't seem to solve the problem either. I get the same
>> association failure as before.
Update: on my second recompile (after adding the printks) it started
working. I'm not sure why it failed the first time.
However there is a huge performance regression. "tptest" shows a TCP
throughput of under 300 kbit for the driver version 2.0.9 (current
wireless-2.6), compared to 7 Mbit for version 2.0.7 (with kernel
2.6.23-rc3). The UDP speed was also affected but not as much, down from
around 5-10 Mbit to 1 Mbit.
> Can you add back your printk patch and check what type 'channel' was and
> maybe print channel->channel?
With the printks below I get the following:
Oct 15 13:14:43 better kernel: selected mode 2
Oct 15 13:14:43 better kernel: selected channel 8
Thanks,
Marcus
--- a/net/mac80211/ieee80211_ioctl.c
+++ b/net/mac80211/ieee80211_ioctl.c
@@ -314,6 +314,8 @@ int ieee80211_set_channel(struct ieee80211_local
*local, int
}
if (set) {
+ printk(KERN_DEBUG "selected mode %d\n",
local->oper_hw_mode->mod
+ printk(KERN_DEBUG "selected channel %d\n",
local->oper_channel->
if (local->sta_scanning)
ret = 0;
else
Hi,
> Ivo van Doorn wrote:
> > Could you enable debugfs and use attached debugfs script to create a
> > dump of the rt2x00 registers.
>
> If you still need the debug dump for 2.0.7 (the latest working version),
> can you show me how to get hold of a source tree with that version? I have
> both the wireless-2.6 and rt2x00 git trees, but seem to have trouble
> locating the right revision, perhaps because the tree was rebased.
I'm afraid that is a bit of a problem, rt2x00 was merged into linus' tree as
a complete patch of version 2.0.8. This means the complete versioning of
2.0.7 has been lost.
The only possible way would be toying with cvs and copying the files
from there. But that is in no what a guarentee for success.
However I can recommend using 2.0.11 the following patches:
http://git.kernel.org/?p=linux/kernel/git/ivd/rt2x00.git;a=commit;h=8927e4ea2933f5f276a7bb505a6b240156a9238f
http://git.kernel.org/?p=linux/kernel/git/ivd/rt2x00.git;a=commit;h=32a8da711c3b03a88487dbe48e57c489b5a3031c
Both caused problems with packet throughput. So those might have
resolved the problem you reported.
Ivo
There's no reason to warn about an invalid AID field when the
association was denied.
Signed-off-by: Johannes Berg <[email protected]>
---
Odd messages in your log btw:
> Oct 10 10:26:27 better kernel: wlan0: associate with AP 00:14:6c:a7:60:10
> Oct 10 10:26:27 better kernel: wlan0: invalid aid value 0; bits 15:14 not set
> Oct 10 10:26:27 better kernel: wlan0: RX AssocResp from 00:14:6c:a7:60:10 (capab=0x431 status=19 aid=0)
> Oct 10 10:26:27 better kernel: wlan0: AP denied association (code=19)
> Oct 10 10:26:27 better kernel: wlan0: association with AP 00:14:6c:a7:60:10 timed out
We never use the AID value in this case...
net/mac80211/ieee80211_sta.c | 11 ++++++-----
1 file changed, 6 insertions(+), 5 deletions(-)
--- wireless-dev.orig/net/mac80211/ieee80211_sta.c 2007-10-10 11:57:36.290680979 +0200
+++ wireless-dev/net/mac80211/ieee80211_sta.c 2007-10-10 12:00:31.490680979 +0200
@@ -1195,15 +1195,11 @@ static void ieee80211_rx_mgmt_assoc_resp
capab_info = le16_to_cpu(mgmt->u.assoc_resp.capab_info);
status_code = le16_to_cpu(mgmt->u.assoc_resp.status_code);
aid = le16_to_cpu(mgmt->u.assoc_resp.aid);
- if ((aid & (BIT(15) | BIT(14))) != (BIT(15) | BIT(14)))
- printk(KERN_DEBUG "%s: invalid aid value %d; bits 15:14 not "
- "set\n", dev->name, aid);
- aid &= ~(BIT(15) | BIT(14));
printk(KERN_DEBUG "%s: RX %sssocResp from " MAC_FMT " (capab=0x%x "
"status=%d aid=%d)\n",
dev->name, reassoc ? "Rea" : "A", MAC_ARG(mgmt->sa),
- capab_info, status_code, aid);
+ capab_info, status_code, aid & ~(BIT(15) | BIT(14)));
if (status_code != WLAN_STATUS_SUCCESS) {
printk(KERN_DEBUG "%s: AP denied association (code=%d)\n",
@@ -1215,6 +1211,11 @@ static void ieee80211_rx_mgmt_assoc_resp
return;
}
+ if ((aid & (BIT(15) | BIT(14))) != (BIT(15) | BIT(14)))
+ printk(KERN_DEBUG "%s: invalid aid value %d; bits 15:14 not "
+ "set\n", dev->name, aid);
+ aid &= ~(BIT(15) | BIT(14));
+
pos = mgmt->u.assoc_resp.variable;
if (ieee802_11_parse_elems(pos, len - (pos - (u8 *) mgmt), &elems)
== ParseFailed) {
Adam Baker reported that the prism2 ioctl removal changed behaviour
in that now the selection order was the other way around as before.
New API is planned but not done yet, so for now just use the first
matching channel in any mode as was previous behaviour with an unset
next_mode.
Signed-off-by: Johannes Berg <[email protected]>
---
Michael Wu just pointed out the error in my previous patch. I missed the
outer loop, we need to break from it as well.
net/mac80211/ieee80211_ioctl.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
--- wireless-dev.orig/net/mac80211/ieee80211_ioctl.c 2007-10-10 12:29:49.330680979 +0200
+++ wireless-dev/net/mac80211/ieee80211_ioctl.c 2007-10-12 21:22:20.838530346 +0200
@@ -305,9 +305,12 @@ int ieee80211_set_channel(struct ieee802
((chan->chan == channel) || (chan->freq == freq))) {
local->oper_channel = chan;
local->oper_hw_mode = mode;
- set++;
+ set = 1;
+ break;
}
}
+ if (set)
+ break;
}
if (set) {
Johannes Berg wrote:
> Michael Wu just pointed out the error in my previous patch. I missed the
> outer loop, we need to break from it as well.
The new patch doesn't seem to solve the problem either. I get the same
association failure as before.
Marcus
On Friday 12 October 2007 15:24, Johannes Berg wrote:
> Adam Baker reported that the prism2 ioctl removal changed behaviour
> in that now the selection order was the other way around as before.
> New API is planned but not done yet, so for now just use the first
> matching channel in any mode as was previous behaviour with an unset
> next_mode.
>
> Signed-off-by: Johannes Berg <[email protected]>
Acked-by: Michael Wu <[email protected]>
Tested and working here.
Thanks,
-Michael Wu
Ivo van Doorn wrote:
> However I can recommend using 2.0.11 the following patches:
I tried the full 2.0.11. It still has throughput problems. TCP throughput is
300 kbit/s (tptest and HTTP download). However UDP throughput is 10 Mbit/s
according to tptest (and that may be limited by the bandwidth to the test
server).
Attaching the debugfs dump.
Marcus
On Wednesday 10 October 2007 06:03, Johannes Berg wrote:
> There's no reason to warn about an invalid AID field when the
> association was denied.
>
> Signed-off-by: Johannes Berg <[email protected]>
>
Acked-by: Michael Wu <[email protected]>
Thanks,
-Michael Wu
> > However there is a huge performance regression. "tptest" shows a TCP
> > throughput of under 300 kbit for the driver version 2.0.9 (current
> > wireless-2.6), compared to 7 Mbit for version 2.0.7 (with kernel
> > 2.6.23-rc3). The UDP speed was also affected but not as much, down from
> > around 5-10 Mbit to 1 Mbit.
>
> I don't think this would be related to mac80211, I'll let Ivo handle the
> rest of this.
Could you enable debugfs and use attached debugfs script to create a dump
of the rt2x00 registers. Preferably a dump of both the rt2x00 2.0.7 and 2.0.9 versions.
Ivo
Hi,
Ivo van Doorn wrote:
> Could you enable debugfs and use attached debugfs script to create a
> dump of the rt2x00 registers.
If you still need the debug dump for 2.0.7 (the latest working version),
can you show me how to get hold of a source tree with that version? I have
both the wireless-2.6 and rt2x00 git trees, but seem to have trouble
locating the right revision, perhaps because the tree was rebased.
Thanks,
Marcus
On Wed, 2007-10-10 at 12:56 +0200, Marcus Better wrote:
> Johannes Berg wrote:
> > Looking at the code... Ahh, I see. You've selected the B mode instead of
> > G and the AP requires G. I think my "[PATCH] mac80211: fix set_channel
> > regression" will fix this for you.
>
> No, I still get the same result.
The same error 19? That's weird because if you select a G mode we do
advertise short slot/short preamble.
johannes
On Wed, 2007-10-10 at 11:06 +0200, Marcus Better wrote:
> Neither does 2.0.10 from the current wireless-2.6 "everything" branch.
> I see scan results now but cannot associate with the access point
> using WEP.
Can you try that patch from Matthias Nissler ("[PATCH] mac80211: Defer
setting of RX_FLAG_DECRYPTED.")?
johannes
On Mon, 2007-10-15 at 13:37 +0200, Marcus Better wrote:
> Johannes Berg wrote:
> > On Mon, 2007-10-15 at 09:04 +0200, Marcus Better wrote:
> >> The new patch doesn't seem to solve the problem either. I get the same
> >> association failure as before.
>
> Update: on my second recompile (after adding the printks) it started
> working. I'm not sure why it failed the first time.
Buggy recompile? No idea really.
> However there is a huge performance regression. "tptest" shows a TCP
> throughput of under 300 kbit for the driver version 2.0.9 (current
> wireless-2.6), compared to 7 Mbit for version 2.0.7 (with kernel
> 2.6.23-rc3). The UDP speed was also affected but not as much, down from
> around 5-10 Mbit to 1 Mbit.
I don't think this would be related to mac80211, I'll let Ivo handle the
rest of this.
> > Can you add back your printk patch and check what type 'channel' was and
> > maybe print channel->channel?
>
> With the printks below I get the following:
>
> Oct 15 13:14:43 better kernel: selected mode 2
> Oct 15 13:14:43 better kernel: selected channel 8
Looks good, 2 is G mode.
johannes
On Mon, 2007-10-15 at 09:04 +0200, Marcus Better wrote:
> Johannes Berg wrote:
> > Michael Wu just pointed out the error in my previous patch. I missed the
> > outer loop, we need to break from it as well.
>
> The new patch doesn't seem to solve the problem either. I get the same
> association failure as before.
Can you add back your printk patch and check what type 'channel' was and
maybe print channel->channel?
johannes
Marcus Better wrote:
> I just tried the rt2500pci driver version 2.0.9 from the wireless-2.6
> tree. It does not work.
Neither does 2.0.10 from the current wireless-2.6 "everything" branch. I see scan results now but cannot associate with the access point using WEP.
Here are some logs:
Oct 10 10:26:27 better kernel: phy0 -> rt2500pci_init_bbp: Debug - Start initialization from EEPROM...
Oct 10 10:26:27 better kernel: phy0 -> rt2500pci_init_bbp: Debug - BBP: 0x0f, value: 0x30.
Oct 10 10:26:27 better kernel: phy0 -> rt2500pci_init_bbp: Debug - BBP: 0x11, value: 0x26.
Oct 10 10:26:27 better kernel: phy0 -> rt2500pci_init_bbp: Debug - BBP: 0x15, value: 0x18.
Oct 10 10:26:27 better kernel: phy0 -> rt2500pci_init_bbp: Debug - BBP: 0x16, value: 0x18.
Oct 10 10:26:27 better kernel: phy0 -> rt2500pci_init_bbp: Debug - BBP: 0x35, value: 0x10.
Oct 10 10:26:27 better kernel: phy0 -> rt2500pci_init_bbp: Debug - BBP: 0x36, value: 0x10.
Oct 10 10:26:27 better kernel: phy0 -> rt2500pci_init_bbp: Debug - BBP: 0x3d, value: 0x6a.
Oct 10 10:26:27 better kernel: phy0 -> rt2500pci_init_bbp: Debug - BBP: 0x3e, value: 0x10.
Oct 10 10:26:27 better kernel: phy0 -> rt2500pci_init_bbp: Debug - BBP: 0x23, value: 0x50.
Oct 10 10:26:27 better kernel: phy0 -> rt2500pci_init_bbp: Debug - BBP: 0x29, value: 0x60.
Oct 10 10:26:27 better kernel: phy0 -> rt2500pci_init_bbp: Debug - BBP: 0x36, value: 0x18.
Oct 10 10:26:27 better kernel: phy0 -> rt2500pci_init_bbp: Debug - BBP: 0x3e, value: 0x00.
Oct 10 10:26:27 better kernel: phy0 -> rt2500pci_init_bbp: Debug - ...End initialization from EEPROM.
Oct 10 10:26:27 better kernel: phy0 -> rt2x00mac_conf_tx: Info - Configured TX ring 0 - CWmin: 5, CWmax: 10, Aifs: 2.
Oct 10 10:26:27 better kernel: phy0 -> rt2x00mac_conf_tx: Info - Configured TX ring 1 - CWmin: 5, CWmax: 10, Aifs: 2.
Oct 10 10:26:27 better kernel: phy0 -> rt2x00mac_conf_tx: Info - Configured TX ring 7 - CWmin: 6, CWmax: 10, Aifs: 2.
Oct 10 10:26:27 better kernel: wlan0: Initial auth_alg=0
Oct 10 10:26:27 better kernel: wlan0: authenticate with AP 00:14:6c:a7:60:10
Oct 10 10:26:27 better kernel: wlan0: RX authentication from 00:14:6c:a7:60:10 (alg=0 transaction=2 status=0)
Oct 10 10:26:27 better kernel: wlan0: authenticated
Oct 10 10:26:27 better kernel: wlan0: associate with AP 00:14:6c:a7:60:10
Oct 10 10:26:27 better kernel: wlan0: invalid aid value 0; bits 15:14 not set
Oct 10 10:26:27 better kernel: wlan0: RX AssocResp from 00:14:6c:a7:60:10 (capab=0x431 status=19 aid=0)
Oct 10 10:26:27 better kernel: wlan0: AP denied association (code=19)
Oct 10 10:26:27 better kernel: wlan0: associate with AP 00:14:6c:a7:60:10
Oct 10 10:26:27 better kernel: wlan0: invalid aid value 0; bits 15:14 not set
Oct 10 10:26:27 better kernel: wlan0: RX AssocResp from 00:14:6c:a7:60:10 (capab=0x431 status=19 aid=0)
Oct 10 10:26:27 better kernel: wlan0: AP denied association (code=19)
Oct 10 10:26:27 better kernel: wlan0: associate with AP 00:14:6c:a7:60:10
Oct 10 10:26:27 better kernel: wlan0: invalid aid value 0; bits 15:14 not set
Oct 10 10:26:27 better kernel: wlan0: RX AssocResp from 00:14:6c:a7:60:10 (capab=0x431 status=19 aid=0)
Oct 10 10:26:27 better kernel: wlan0: AP denied association (code=19)
Oct 10 10:26:27 better kernel: wlan0: association with AP 00:14:6c:a7:60:10 timed out
Thanks,
Marcus
On Thursday 11 October 2007, Johannes Berg wrote:
> On Thu, 2007-10-11 at 11:05 +0200, Marcus Better wrote:
>
> > > No, but you can comment out the B mode registration in rt2500pci and see
> > > if that helps.
> >
> > I have very limited time to find out how to do that, but will gladly try a
> > patch...
>
> Me neither. It seems to be in rt2x00dev.c, Ivo can you help maybe? Just
> for debugging. I'd have thought that adding the 'break' statement would
> fix it.
Patch added below.
> Alternatively, could you print out the selected mode in
> ieee80211_ioctl.c:ieee80211_set_channel?
>
> something like
> printk(KERN_DEBUG "selected mode %d\n", local->oper_hw_mode->mode);
> printk(KERN_DEBUG "select channel %d\n", local->oper_channel);
---
diff --git a/drivers/net/wireless/rt2x00/rt2x00dev.c b/drivers/net/wireless/rt2x00/rt2x00dev.c
index 360f03a..89470c0 100644
--- a/drivers/net/wireless/rt2x00/rt2x00dev.c
+++ b/drivers/net/wireless/rt2x00/rt2x00dev.c
@@ -866,9 +866,9 @@ static int rt2x00lib_probe_hw_modes(struct rt2x00_dev *rt2x00dev,
ieee80211_register_hwmode(hw, &hwmodes[HWMODE_G]))
goto exit_free_rates;
- if (spec->num_modes > HWMODE_B &&
+ /*if (spec->num_modes > HWMODE_B &&
ieee80211_register_hwmode(hw, &hwmodes[HWMODE_B]))
- goto exit_free_rates;
+ goto exit_free_rates;*/
if (spec->num_modes > HWMODE_A &&
ieee80211_register_hwmode(hw, &hwmodes[HWMODE_A]))
Johannes Berg wrote:
> Looking at the code... Ahh, I see. You've selected the B mode instead of
> G and the AP requires G. I think my "[PATCH] mac80211: fix set_channel
> regression" will fix this for you.
No, I still get the same result.
Marcus
On Fri, 2007-10-12 at 11:04 +0200, Marcus Better wrote:
> Oct 12 10:47:23 better kernel: selected mode 2
That's G. What do you get without this patch but with my 'break' patch?
> Oct 12 10:47:23 better kernel: select channel -539241232
That's weird. Humm. What exactly are you printing there and is it really
a pointer 0xdfdbd4f0?
johannes