Hi All,
I first reported this in Fedora bugzilla, as I'm using Fedora with a Fedora
kernel (which includes recent linux-wireless git snapshots), see here for the
Fedora bugreport:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=249823
Updating from the Fedora 7 test kernel to the final results in very poor
performance, and going to even newer versions of the Fedora kernel totally
breaks connectivity. Linville thought it would be best to further discuss this
here, so here I am.
I've looked at recent git commits to the prism54 / p54pci driver and have been
trying it revision by revision, eventually I've managed to pin the cause down
to 2 patches, below is a verbatim cut and paste from the bugzilla entry,
containing my analysis:
---
I've been busy researching this and I have come to the
following conclusions.
1) with the 2.6.20-2something F7-test kernel everything works fine build date
3 march, I can give you the exact revision if you want.
2) with the fc release kerkel (3194) things work, but the connection is often lost.
3) with the 2.6.23-0.49.rc1.git3.fc8, the card asociates and thats it.
Using wireless git and out of tree driver building I've found that the following
2 patches are the culprits:
Patch causing loose off connection within seconds when fully loading the link
with a local file transfer:
http://bu3sch.de/gitweb?p=wireless-dev.git;a=commitdiff;h=62ee473d67b7ae353d210b186abaadc37a642237
Only associating and nothing else:
http://bu3sch.de/gitweb?p=wireless-dev.git;a=commitdiff;h=7d59453a9dbe50dc9bab846c410e39f8d5b10c83
And then specifically the changes to prism54common.c
This is with an isl3886 cardbus card, using the p54pci driver.
----
I would be more then happy to test any changes.
Thanks & Regards,
Hans
p.s.
Please keep my CC-ed I'm not on the list.
On Thursday, 23. August 2007, Hans de Goede wrote:
>
> Okay, I've given this a test together with your remvoe QOS and other advanced
> features patch and it seems to work well (as good as the versiono of the driver
> I'm currently using).
>
> I've tried using all other firmwares from here:
> http://jbnote.free.fr/prism54usb/data/firmwares/
>
> But none of them work, except for the (identical) 2.4.12.0 one. the others
> either don't boot or can't read the eeprom.
>
Thanks for testing! Let's see if I can write something over the weekend.
Since you have said in your previous post that your Sitecom adapter is cheap
and common ... can you please tell me which one is it?
Regards,
Chr.
On Tuesday, 14. August 2007, Hans de Goede wrote:
Hans,
Any updates? Or are you on holiday?
I've prepared a patch, which should theoretically lower the excessive retry count.
however I don't think it will magically solve anything...
OT: Michael/anyone else:
1. Do you know why the rate algorithm (rc80211_simple) starts with the lowest speed?
or is this really only a p54 bug?
2. Is there any way to get a station aid (in ap mode) and dtim period
without lots of castings or "new variables" in struct ieee80211_tx_control?
I really need them for AP mode (yes, I have a "proof of concept" for it,
the hardest thing was to compile hostapd ;-) ).
Thanks,
Chr.
On Sunday 12 August 2007 22:50, Hans de Goede wrote:
> Patch causing loose off connection within seconds when fully loading the
> link with a local file transfer:
> http://bu3sch.de/gitweb?p=wireless-dev.git;a=commitdiff;h=62ee473d67b7ae353
>d210b186abaadc37a642237
>
> Only associating and nothing else:
> http://bu3sch.de/gitweb?p=wireless-dev.git;a=commitdiff;h=7d59453a9dbe50dc9
>bab846c410e39f8d5b10c83 And then specifically the changes to prism54common.c
>
Links not working.
-Michael Wu
Somebody in the thread at some point said:
> On Monday 13 August 2007 00:49, Hans de Goede wrote:
>> I already found that one, but there is no drivers/net/wireless/mac80211 dir
>> there. What am I missing?
>>
> John Linville recently collapsed that directory into driver/net/wireless.
Looking through that gitweb HEAD, the mac80211 stuff appears to be just
plain absent at the moment as Hans says:
http://git.kernel.org/?p=linux/kernel/git/linville/wireless-dev.git;a=blob;f=drivers/net/wireless/Kconfig;h=ae27af0141c02ee5b6100aa7f512dfdd77c4e703;hb=HEAD
-Andy
From: Christian Lamparter <[email protected]>
This patch should finally fix the mysterious "stuck at 1 mbps" and numerous of
"lost" ACKs (very important for the not yet released p54 AP addon).
The patch also includes a bunch of useful one liners that did not make it in the tree yet.
Signed-off-by: Christian Lamparter <[email protected]>
---
From: Christian Lamparter <[email protected]>
This patch fixes a regression with older (pre 2.5.2.0) firmwares, that don't
support the QoS queues yet...
Thanks to Hans de Goede <[email protected]> for reporting and debugging it.
Signed-off-by: Christian Lamparter <[email protected]>
---
On Monday, 13. August 2007, Michael Wu wrote:
> On Monday 13 August 2007 04:58, Hans de Goede wrote:
> > Okay, I still had copies of various git revisions of prism54common.c and .h
> > (aka the culprits) on my laptop. I've run some tests again to make sure I
> > had the right revisions in mind for the breakage (which I had). I've
> > attached 2 patches:
> > diff: with this reversed my speed increases 10x and more importantly when
> > fully loading the link (using scp from a local non wireless ethernet
> > machine) it no longer looses the connection in a couple of seconds
> >
> Hm, I guess either these changes were wrong or exposed some bugs. Can you
> check what sort of tx rates are being reported in iwconfig before and after
> that change?
>
> > diff2, when I do not reverse this one, it still associates, but it no
> > longer receives / or transmits packages. (no dhcp, no ping when manually
> > assigning IP's, etc).
> >
> Not sure.. this patch generally helped things on my hardware. Christian
> Lamparter might have an idea.
>
Well not really, It is "fast" as usual here:
scp user@p54pci-pc:/usr/src/dummyzero ./
dummyzero 100% 236MB 1.8MB/s 02:09
iperf:
[ 5] local 192.168.1.247 port 5001 connected with 192.168.1.1 port 56253
[ 5] 0.0-240.7 sec 597 MBytes 20.8 Mbits/sec
=> need more data...
1. Which p54 firmware do you use? (It "must" be 2.7.0.0 for pci/cardbus)
2. What's your "average" txrate and Link Signal Level / Link Quality with and without the patches.
(see iwconfig)
3. what brand/type of AP do you have?
-> what does the beacon frame look like? (or: if you don't have a
wlan sniffer / monitor, just run: iwlist wlanX scan )
4. Can you recompile the mac80211 layer with debug options and look for
something like ethX: STA XX:YY:ZZ:AA:BB:CC Average rate: VVV ... in your syslogs?
5. are they any suspicious dmesg outputs when the "network" stops/dies?
Thanks,
Chr.
Chr wrote:
> On Monday, 20. August 2007, Hans de Goede wrote:
>> Chr wrote:
>>> On Tuesday, 14. August 2007, Hans de Goede wrote:
>>>
>>> Hans,
>>>
>>> Any updates?
>> Erm, did you not receive my long mail with all kinda logs attached in logs.tar.gz?
>>
> yes I got the logs... but maybe you haven't seen my reply:
> http://www.spinics.net/lists/linux-wireless/msg04658.html
>
I indeed didn't see that, probably because I'm not on the list. Here are some
answers to your questions:
> > > 1. Which p54 firmware do you use? (It "must" be 2.7.0.0 for pci/cardbus)
> > 2.4.12.0, extracted from the window driver for my card, any later version
> > will cause the driver to fail to load with: "Error cannot read eeprom!"
> uhh, that's a pity... Well, I'm thinking about to get the FW then. The
> problem is that I don't have the necessary equipment "here" for debugging (I
> am abroad with my old laptop and a minipci prism54 card...)
>
> Anyway, could you please verify that the firmware at
> http://daemonizer.de/prism54/prism54-fw/fw-softmac/2.4.12.0.arm is the same
> one you have? Or does it "differ"?
I'm at work atm, but I did verify that my 2.4.12.0 matched 2.4.12.0 available
from the firmware site linked to from the prism54 wiki.
I can verify that your link matches too if you want, but it porbably will.
>
> > 2. What's your "average" txrate and Link Signal Level / Link Quality with
and without the patches.
> > (see iwconfig)
> See attached logs
>
Your average speed is in the very low MBit/s and your normal Link Signal Level
is only about
40/100 (~ -80 dbm! ) ?! (The equation is roughly (rssi / 2) - 100 = dbm)
Something is fishy: take a look at the "not working" scan-13-6. Signal level
is about 62/100
(~ -69 dbm! => much better! Did you move the laptop, or is this high value
really reproducible?)
I'm afraid that my reception quality varies wildly. I don't know why, I'll try
to configure a different channel on the AP the next time I do some testing.
> > 3. what brand/type of AP do you have?
> A davolink DV-201AMR its an embedded Linux device using the BCM6348 chipset,
hmm, a embedded linux? do you have a ssh/telnet access to the router? Maybe the
syslogs / dmesg gives us a "hint" why it won't connect.
I'm afraid its provisioned by my ISP , and I only have access to some crippled
web interface, I really need to kick the ISP and ask them to give me the source
and stuff, as they are oblidged under the GPL.
(BTW: does your router really only support the weak WEP encryptions?)
No it also supports 128 bit, but when first settings things up I had trouble
getting that working. This has been working reasonably for me, so I didn't
change it. The firmware can also do wpa, but the webinterface I'm stuck behind
doesn't allow this (GRRRR).
> k. Do you have another wifi card that can perform wifi sniffs? (just as an
> option)
I can get my hands on a full mac prism pci card, but I'll first try your patches.
----
Replying to other mail in one go:
Chr wrote:
> I made two patches:
>
> the p54-pull-padding.diff should finally fix the rate algorithm for
"everyone" and as
> a bonus for developers: it adds a printk for the firmware revision p54 is using.
>
Cool I'll give this a try tonight, I really wanted to try it sooner, but ...
> p54-remove-qos.diff (must be applied on top of p54-pull-padding.diff) is
_only_ for
> Hans... It removes/reverts QoS/WME/WMM/IEEE802.11e features.
>
Hmm, could this be made conditionally on the firmware revision perhaps? I don't
like having to patch my kernel every update, and more importantly, my card is a
pretty popular el cheapo sitecom, which are stacked by the dozen by every
computershop in town, so it would be nice if this worked out of the box.
I'll try to see if 2.5.2.0 will work with my card, I think I've tried before
but you never know, will 2.5.2.0 be good enough for the QoS/WME/WMM/IEEE802.11e
features?
Maybe it would be an idea to dump the eeprom from the driver with the 2.4.12.0
firmware, and then fake the eeprom in the driver using newer firmware to see if
the eeprom reading is the only problem with newer firmware and my card ?
Thanks & Regards,
Hans
On Friday, 24. August 2007, Hans de Goede wrote:
> Chr wrote:
>
> Its a Sitecom WL-140 V2 (small letters at the bottom right of the front of the
> box) aka the Sitecom Nitro XM 140G+
>
> Note I think that the V2 is important to get the same one as mine, otherwise
> you probably get an older fullmac version (if they still sell that anyware).
>
Here we are:
series:
p54-pull-padding2.diff
p54-support-older-firmwares.diff
Signed-off will follow on friday/saturday... Michael, any complains?
Regards,
Chr.
Chr wrote:
> On Thursday, 23. August 2007, Hans de Goede wrote:
>> I'm afraid that my reception quality varies wildly. I don't know why, I'll try
>> to configure a different channel on the AP the next time I do some testing.
>>
> Ok, maybe someone has cooked a meal in a microwave oven, or
> something like that...
>
>> Replying to other mail in one go:
>>
>> Chr wrote:
>> > I made two patches:
>> >
>> > the p54-pull-padding.diff should finally fix the rate algorithm for
>> "everyone" and as
>> > a bonus for developers: it adds a printk for the firmware revision p54 is using.
>> >
>>
>> Cool I'll give this a try tonight, I really wanted to try it sooner, but ...
>>
> k, I'll wait ;-)
>
> BTW: There's already a newer version of it... see attachment.
>
Okay, I've given this a test together with your remvoe QOS and other advanced
features patch and it seems to work well (as good as the versiono of the driver
I'm currently using).
I've tried using all other firmwares from here:
http://jbnote.free.fr/prism54usb/data/firmwares/
But none of them work, except for the (identical) 2.4.12.0 one. the others
either don't boot or can't read the eeprom.
Regards,
Hans
Michael Wu wrote:
> On Sunday 12 August 2007 22:50, Hans de Goede wrote:
>> Patch causing loose off connection within seconds when fully loading the
>> link with a local file transfer:
>> http://bu3sch.de/gitweb?p=wireless-dev.git;a=commitdiff;h=62ee473d67b7ae353
>> d210b186abaadc37a642237
>>
>> Only associating and nothing else:
>> http://bu3sch.de/gitweb?p=wireless-dev.git;a=commitdiff;h=7d59453a9dbe50dc9
>> bab846c410e39f8d5b10c83 And then specifically the changes to prism54common.c
>>
> Links not working.
>
Darn, is there a gitweb of the wireless-dev git anywhere else, I'm pretty sure
I can find those patches pretty quick again.
Regards,
Hans
Andy Green wrote:
> Somebody in the thread at some point said:
>
>> Darn, is there a gitweb of the wireless-dev git anywhere else, I'm
>> pretty sure I can find those patches pretty quick again.
>
> http://git.kernel.org/?p=linux/kernel/git/linville/wireless-dev.git;a=summary
>
Erm,
I already found that one, but there is no drivers/net/wireless/mac80211 dir
there. What am I missing?
Regards,
Hans
On Thursday, 30. August 2007, Michael Wu wrote:
> On Tuesday 28 August 2007 15:32, Chr wrote:
> > Here we are:
> >
> > series:
> > p54-pull-padding2.diff
> Looks okay, but it seems to do more than just account for padding. I'm okay
> with those changes too.
>
Ok!
> > p54-support-older-firmwares.diff
> The new information pulled from parsing the firmware isn't used anywhere but
> in this function.. no need to keep that information in the private structure.
>
Yes, the firmware version string could be freed right after the printk...
but I would like to keep the fw_variant for "further" patches, since the
softmac protocol has changed a bit throughout 2.4 - 2.13.1 firmwares.
> Thanks,
> -Michael Wu
Thanks,
Chr.
Chr wrote:
> On Thursday, 23. August 2007, Hans de Goede wrote:
>> Okay, I've given this a test together with your remvoe QOS and other advanced
>> features patch and it seems to work well (as good as the versiono of the driver
>> I'm currently using).
>>
>> I've tried using all other firmwares from here:
>> http://jbnote.free.fr/prism54usb/data/firmwares/
>>
>> But none of them work, except for the (identical) 2.4.12.0 one. the others
>> either don't boot or can't read the eeprom.
>>
>
> Thanks for testing! Let's see if I can write something over the weekend.
> Since you have said in your previous post that your Sitecom adapter is cheap
> and common ... can you please tell me which one is it?
>
Its a Sitecom WL-140 V2 (small letters at the bottom right of the front of the
box) aka the Sitecom Nitro XM 140G+
Note I think that the V2 is important to get the same one as mine, otherwise
you probably get an older fullmac version (if they still sell that anyware).
Regards,
Hans
On Monday 13 August 2007 04:58, Hans de Goede wrote:
> Okay, I still had copies of various git revisions of prism54common.c and .h
> (aka the culprits) on my laptop. I've run some tests again to make sure I
> had the right revisions in mind for the breakage (which I had). I've
> attached 2 patches:
> diff: with this reversed my speed increases 10x and more importantly when
> fully loading the link (using scp from a local non wireless ethernet
> machine) it no longer looses the connection in a couple of seconds
>
Hm, I guess either these changes were wrong or exposed some bugs. Can you
check what sort of tx rates are being reported in iwconfig before and after
that change?
> diff2, when I do not reverse this one, it still associates, but it no
> longer receives / or transmits packages. (no dhcp, no ping when manually
> assigning IP's, etc).
>
Not sure.. this patch generally helped things on my hardware. Christian
Lamparter might have an idea.
Thanks,
-Michael Wu
On Tuesday, 14. August 2007, Hans de Goede wrote:
> >
> > 1. Which p54 firmware do you use? (It "must" be 2.7.0.0 for pci/cardbus)
> 2.4.12.0, extracted from the window driver for my card, any later version will
> cause the driver to fail to load with: "Error cannot read eeprom!"
uhh, that's a pity... Well, I'm thinking about to get the FW then. The problem is that I don't have the
necessary equipment "here" for debugging (I am abroad with my old laptop and a minipci prism54 card...)
Anyway, could you please verify that the firmware at
http://daemonizer.de/prism54/prism54-fw/fw-softmac/2.4.12.0.arm is the same one you have?
Or does it "differ"?
>
> > 2. What's your "average" txrate and Link Signal Level / Link Quality with and without the patches.
> > (see iwconfig)
> See attached logs
>
Your average speed is in the very low MBit/s and your normal Link Signal Level is only about
40/100 (~ -80 dbm! ) ?! (The equation is roughly (rssi / 2) - 100 = dbm)
Something is fishy: take a look at the "not working" scan-13-6. Signal level is about 62/100
(~ -69 dbm! => much better! Did you move the laptop, or is this high value really reproducible?)
> > 3. what brand/type of AP do you have?
> A davolink DV-201AMR its an embedded Linux device using the BCM6348 chipset,
hmm, a embedded linux? do you have a ssh/telnet access to the router? Maybe the
syslogs / dmesg gives us a "hint" why it won't connect.
(BTW: does your router really only support the weak WEP encryptions?)
>
> > -> what does the beacon frame look like? (or: if you don't have a
> > wlan sniffer / monitor, just run: iwlist wlanX scan )
> See logs
>
> > 4. Can you recompile the mac80211 layer with debug options and look for
> > something like ethX: STA XX:YY:ZZ:AA:BB:CC Average rate: VVV ... in your syslogs?
>
> See logs
phy4: not handling 0x02 type control frame.
=> It's a bit strange that you got one, it's probably because of the 2.4.12.0 Firmware.
wlan0: switched to short barker preamble.
Well, that's probably the reason why your connection always "dropped".
could you please replace all "IEEE80211_RATE_CCK_2" in p54common.h
with "IEEE80211_RATE_CCK" and report back?
>
> > 5. are they any suspicious dmesg outputs when the "network" stops/dies?
> >
>
> Nope.
Yep, none!
I'll see if I can post you a "debug" driver, when I'm back at home. I'm afraid it's not
possible right now...
>
> I've attached a tarbal with logs the FC7test logs are the logs from the Fedora
> 7 test kernel which I normally use, as that works well.
>
> The rest is based on a F-8 test kernel which contains a wireless-dev snapshot
> from 26 jul 2007. The dates are dates of git checkouts from prism54common.{c,h}
> the -common one has the speed changes to prism54common.h reversed, because
> otherwise connectivity is lost as explained.
>
k. Do you have another wifi card that can perform wifi sniffs? (just as an option)
> I hope this helps.
>
> Regards,
>
> Hans
>
Thanks,
Chr
On Monday, 20. August 2007, Hans de Goede wrote:
> Chr wrote:
> > On Tuesday, 14. August 2007, Hans de Goede wrote:
> >
> > Hans,
> >
> > Any updates?
>
> Erm, did you not receive my long mail with all kinda logs attached in logs.tar.gz?
>
yes I got the logs... but maybe you haven't seen my reply:
http://www.spinics.net/lists/linux-wireless/msg04658.html
> > Or are you on holiday?
>
> Nope
>
> >
> > I've prepared a patch, which should theoretically lower the excessive retry count.
> >
> > however I don't think it will magically solve anything...
> >
>
> Erm, I'm awfully busy, still I want to get this resolved! So I'll make time to
> test things as necessary, but could you first look at the logs I send and then
> confirm (or deny) that this pathc might help.
>
me too... but the logs don't carry much useful information inside:
"pyh2: not handling 0x02 type control frame" (could be the FW)
"wlan0: duplicate address detected!" (never seen this before... IPv6?)
"wlan0: switched to short barker preamble" (nothing to be scared.)
and of course: the low signal with any driver, except 13-6...
Thanks,
Chr.
Chr wrote:
> On Tuesday, 14. August 2007, Hans de Goede wrote:
>
> Hans,
>
> Any updates?
Erm, did you not receive my long mail with all kinda logs attached in logs.tar.gz?
> Or are you on holiday?
Nope
>
> I've prepared a patch, which should theoretically lower the excessive retry count.
>
> however I don't think it will magically solve anything...
>
Erm, I'm awfully busy, still I want to get this resolved! So I'll make time to
test things as necessary, but could you first look at the logs I send and then
confirm (or deny) that this pathc might help.
Regards,
Hans
Somebody in the thread at some point said:
> Darn, is there a gitweb of the wireless-dev git anywhere else, I'm
> pretty sure I can find those patches pretty quick again.
http://git.kernel.org/?p=linux/kernel/git/linville/wireless-dev.git;a=summary
-Andy
On Mon, 2007-08-20 at 13:51 +0200, Chr wrote:
> "pyh2: not handling 0x02 type control frame" (could be the FW)
The driver, I assume.
> "wlan0: duplicate address detected!" (never seen this before... IPv6?)
Yes, IPv6, caused by the multicast bug.
> "wlan0: switched to short barker preamble" (nothing to be scared.)
Fairly new, but yeah, nothing to worry.
johannes
Chr wrote:
> On Monday, 13. August 2007, Michael Wu wrote:
>> On Monday 13 August 2007 04:58, Hans de Goede wrote:
>>> Okay, I still had copies of various git revisions of prism54common.c and .h
>>> (aka the culprits) on my laptop. I've run some tests again to make sure I
>>> had the right revisions in mind for the breakage (which I had). I've
>>> attached 2 patches:
>>> diff: with this reversed my speed increases 10x and more importantly when
>>> fully loading the link (using scp from a local non wireless ethernet
>>> machine) it no longer looses the connection in a couple of seconds
>>>
>> Hm, I guess either these changes were wrong or exposed some bugs. Can you
>> check what sort of tx rates are being reported in iwconfig before and after
>> that change?
>>
>>> diff2, when I do not reverse this one, it still associates, but it no
>>> longer receives / or transmits packages. (no dhcp, no ping when manually
>>> assigning IP's, etc).
>>>
>> Not sure.. this patch generally helped things on my hardware. Christian
>> Lamparter might have an idea.
>>
>
> Well not really, It is "fast" as usual here:
>
> scp user@p54pci-pc:/usr/src/dummyzero ./
> dummyzero 100% 236MB 1.8MB/s 02:09
>
> iperf:
> [ 5] local 192.168.1.247 port 5001 connected with 192.168.1.1 port 56253
> [ 5] 0.0-240.7 sec 597 MBytes 20.8 Mbits/sec
>
>
> => need more data...
>
> 1. Which p54 firmware do you use? (It "must" be 2.7.0.0 for pci/cardbus)
2.4.12.0, extracted from the window driver for my card, any later version will
cause the driver to fail to load with: "Error cannot read eeprom!"
> 2. What's your "average" txrate and Link Signal Level / Link Quality with and without the patches.
> (see iwconfig)
See attached logs
> 3. what brand/type of AP do you have?
A davolink DV-201AMR its an embedded Linux device using the BCM6348 chipset,
> -> what does the beacon frame look like? (or: if you don't have a
> wlan sniffer / monitor, just run: iwlist wlanX scan )
See logs
> 4. Can you recompile the mac80211 layer with debug options and look for
> something like ethX: STA XX:YY:ZZ:AA:BB:CC Average rate: VVV ... in your syslogs?
See logs
> 5. are they any suspicious dmesg outputs when the "network" stops/dies?
>
Nope.
I've attached a tarbal with logs the FC7test logs are the logs from the Fedora
7 test kernel which I normally use, as that works well.
The rest is based on a F-8 test kernel which contains a wireless-dev snapshot
from 26 jul 2007. The dates are dates of git checkouts from prism54common.{c,h}
the -common one has the speed changes to prism54common.h reversed, because
otherwise connectivity is lost as explained.
I hope this helps.
Regards,
Hans
On Mon, 2007-08-13 at 07:46 +0100, Andy Green wrote:
> Somebody in the thread at some point said:
>
> > Darn, is there a gitweb of the wireless-dev git anywhere else, I'm
> > pretty sure I can find those patches pretty quick again.
>
> http://git.kernel.org/?p=linux/kernel/git/linville/wireless-dev.git;a=summary
Actually, you want to look at
http://git.kernel.org/?p=linux/kernel/git/linville/wireless-dev.git;a=shortlog;h=everything or one of the other branches.
johannes
On Monday 13 August 2007 00:49, Hans de Goede wrote:
> I already found that one, but there is no drivers/net/wireless/mac80211 dir
> there. What am I missing?
>
John Linville recently collapsed that directory into driver/net/wireless.
If you can just find the title of the patches/commits or describe them, that's
probably enough for me to find them.
-Michael Wu
On Tuesday 28 August 2007 15:32, Chr wrote:
> Here we are:
>
> series:
> p54-pull-padding2.diff
Looks okay, but it seems to do more than just account for padding. I'm okay
with those changes too.
> p54-support-older-firmwares.diff
The new information pulled from parsing the firmware isn't used anywhere but
in this function.. no need to keep that information in the private structure.
Thanks,
-Michael Wu
On Monday, 20. August 2007, Johannes Berg wrote:
> On Mon, 2007-08-20 at 13:51 +0200, Chr wrote:
>
> > "pyh2: not handling 0x02 type control frame" (could be the FW)
>
> The driver, I assume.
No, it's really the firmware. I've "finally" tried the 2.4.12.0 and got the same messages...
But, I didn't get them with 2.7.0.0 or 2.5.2.0.
Moreover, because of some "unknown reason" 2.4.12.0 does not work very well with
my isl3880 chip, I cannot tx/rx any QoS data frame... And probably, it's because the
feature is not supported by the firmware...
I made two patches:
the p54-pull-padding.diff should finally fix the rate algorithm for "everyone" and as
a bonus for developers: it adds a printk for the firmware revision p54 is using.
(If noone complains within a week, I'll write a official patch post for it...)
p54-remove-qos.diff (must be applied on top of p54-pull-padding.diff) is _only_ for
Hans... It removes/reverts QoS/WME/WMM/IEEE802.11e features.
Thanks,
Chr
Chr wrote:
> On Tuesday, 14. August 2007, Hans de Goede wrote:
>
> Hans,
>
> Any updates? Or are you on holiday?
>
> I've prepared a patch, which should theoretically lower the excessive retry count.
>
> however I don't think it will magically solve anything...
>
>
> OT: Michael/anyone else:
>
> 1. Do you know why the rate algorithm (rc80211_simple) starts with the lowest speed?
> or is this really only a p54 bug?
I cannot answer any other of your questions, but rc80211_simple starting at 1 Mbs is not a bug, it
is a feature. The reason is that particular speed offers the greatest chance of authenticating and
associating. It used to start at the highest rate and many systems would give up trying to connect
before the rate was dropped to a point at which they could communicate. If the connection is really
capable of higher speeds, it gets there very quickly.
Larry
--- prism54common-11-4.c 2007-07-27 20:47:47.000000000 +0200
+++ prism54common-13-6.c 2007-07-27 20:47:47.000000000 +0200
@@ -3,6 +3,7 @@
* Common code for mac80211 Prism54 drivers
*
* Copyright (c) 2006, Michael Wu <[email protected]>
+ * Copyright (c) 2007, Christian Lamparter <[email protected]>
*
* Based on the islsm (softmac prism54) driver, which is:
* Copyright 2004-2006 Jean-Baptiste Note <[email protected]>, et al.
@@ -283,10 +284,11 @@
u16 freq = le16_to_cpu(hdr->freq);
rx_status.ssi = hdr->rssi; /* TODO: check this */
- rx_status.rate = hdr->rate & 0x0f;
+ rx_status.rate = hdr->rate & 0x1f; /* report short preambles & CCK too */
rx_status.channel = freq == 2484 ? 14 : (freq - 2407)/5;
rx_status.freq = freq;
rx_status.phymode = MODE_IEEE80211G;
+ rx_status.antenna = hdr->antenna;
skb_pull(skb, sizeof(*hdr));
skb_trim(skb, le16_to_cpu(hdr->len));
@@ -294,6 +296,19 @@
ieee80211_rx_irqsafe(dev, skb, &rx_status);
}
+static void inline p54_wake_free_queues(struct ieee80211_hw *dev)
+{
+ struct p54_common *priv = dev->priv;
+ int i;
+
+ /* ieee80211_start_queues is great if all queues are really empty.
+ * But, what if some are full? */
+
+ for (i = 0; i < dev->queues; i++)
+ if (priv->tx_stats.data[i].len < priv->tx_stats.data[i].limit)
+ ieee80211_wake_queue(dev, i);
+}
+
static void p54_rx_frame_sent(struct ieee80211_hw *dev, struct sk_buff *skb)
{
struct p54_common *priv = dev->priv;
@@ -331,6 +346,7 @@
status.retry_count = payload->retries - 1;
status.ack_signal = le16_to_cpu(payload->ack_rssi);
skb_pull(entry, sizeof(*hdr) + sizeof(struct p54_tx_control_allocdata));
+ priv->tx_stats.data[status.control.queue].len--;
ieee80211_tx_status_irqsafe(dev, entry, &status);
break;
} else
@@ -340,7 +356,7 @@
if (freed >= IEEE80211_MAX_RTS_THRESHOLD + 0x170 +
sizeof(struct p54_control_hdr))
- ieee80211_wake_queue(dev, 0);
+ p54_wake_free_queues(dev);
}
static void p54_rx_control(struct ieee80211_hw *dev, struct sk_buff *skb)
@@ -443,7 +459,7 @@
__skb_queue_after(&priv->tx_queue, target_skb, skb);
if (largest_hole < IEEE80211_MAX_RTS_THRESHOLD + 0x170 +
sizeof(struct p54_control_hdr))
- ieee80211_stop_queue(dev, 0);
+ ieee80211_stop_queues(dev);
}
spin_unlock_irqrestore(&priv->tx_queue.lock, flags);
@@ -453,6 +469,7 @@
static int p54_tx(struct ieee80211_hw *dev, struct sk_buff *skb,
struct ieee80211_tx_control *control)
{
+ struct ieee80211_tx_queue_stats_data *current_queue;
struct p54_common *priv = dev->priv;
struct p54_control_hdr *hdr;
struct p54_tx_control_allocdata *txhdr;
@@ -460,6 +477,14 @@
size_t padding, len;
u8 rate;
+ current_queue = &priv->tx_stats.data[control->queue];
+ if (unlikely(current_queue->len > current_queue->limit))
+ return NETDEV_TX_BUSY;
+ current_queue->len++;
+ current_queue->count++;
+ if (current_queue->len == current_queue->limit)
+ ieee80211_stop_queue(dev, control->queue);
+
padding = (unsigned long)(skb->data - (sizeof(*hdr) + sizeof(*txhdr))) & 3;
len = skb->len;
@@ -493,12 +518,13 @@
memset(txhdr->rateset, rate, 8);
txhdr->wep_key_present = 0;
txhdr->wep_key_len = 0;
- txhdr->frame_type = cpu_to_le32(0x4);
+ txhdr->frame_type = cpu_to_le32(control->queue + 4);
txhdr->magic4 = 0;
- txhdr->antenna = control->antenna_sel_tx;
+ txhdr->antenna = (control->antenna_sel_tx == 0) ?
+ 2 : control->antenna_sel_tx - 1;
txhdr->output_power = 0x7f; // HW Maximum
txhdr->magic5 = (control->flags & IEEE80211_TXCTL_NO_ACK) ?
- 0 : cpu_to_le32(0x23);
+ 0 : ((rate > 0x3) ? cpu_to_le32(0x33) : cpu_to_le32(0x23));
if (padding)
txhdr->align[0] = padding;
@@ -654,6 +680,64 @@
return 0;
}
+#define P54_SET_QUEUE(queue, ai_fs, cw_min, cw_max, burst) \
+do { \
+ queue.aifs = cpu_to_le16(ai_fs); \
+ queue.cwmin = cpu_to_le16(cw_min); \
+ queue.cwmax = cpu_to_le16(cw_max); \
+ queue.txop = (burst == 0) ? \
+ 0 : cpu_to_le16((burst * 100) / 32 + 1); \
+} while(0)
+
+static void p54_init_vdcf(struct ieee80211_hw *dev)
+{
+ struct p54_common *priv = dev->priv;
+ struct p54_control_hdr *hdr;
+ struct p54_tx_control_vdcf *vdcf;
+
+ /* all USB V1 adapters need a extra headroom */
+ hdr = (void *)priv->cached_vdcf + priv->tx_hdr_len;
+ hdr->magic1 = cpu_to_le16(0x8001);
+ hdr->len = cpu_to_le16(sizeof(*vdcf));
+ hdr->type = cpu_to_le16(P54_CONTROL_TYPE_DCFINIT);
+ hdr->req_id = cpu_to_le32(priv->rx_start);
+
+ vdcf = (struct p54_tx_control_vdcf *) hdr->data;
+
+ P54_SET_QUEUE(vdcf->queue[0], 0x0002, 0x0003, 0x0007, 0x000f);
+ P54_SET_QUEUE(vdcf->queue[1], 0x0002, 0x0007, 0x000f, 0x001e);
+ P54_SET_QUEUE(vdcf->queue[2], 0x0002, 0x000f, 0x03ff, 0x0014);
+ P54_SET_QUEUE(vdcf->queue[3], 0x0007, 0x000f, 0x03ff, 0x0000);
+}
+
+static void p54_set_vdcf(struct ieee80211_hw *dev)
+{
+ struct p54_common *priv = dev->priv;
+ struct p54_control_hdr *hdr;
+ struct p54_tx_control_vdcf *vdcf;
+
+ hdr = (void *)priv->cached_vdcf + priv->tx_hdr_len;
+
+ p54_assign_address(dev, NULL, hdr, sizeof(*hdr) + sizeof(*vdcf), NULL);
+
+ vdcf = (struct p54_tx_control_vdcf *) hdr->data;
+
+ if (dev->conf.flags & IEEE80211_CONF_SHORT_SLOT_TIME) {
+ vdcf->slottime = 9;
+ vdcf->magic1 = 0x00;
+ vdcf->magic2 = 0x10;
+ } else {
+ vdcf->slottime = 20;
+ vdcf->magic1 = 0x0a;
+ vdcf->magic2 = 0x06;
+ }
+
+ /* (see prism54/isl_oid.h for further details) */
+ vdcf->frameburst = cpu_to_le16(0);
+
+ priv->tx(dev, hdr, sizeof(*hdr) + sizeof(*vdcf), 0);
+}
+
static int p54_add_interface(struct ieee80211_hw *dev,
struct ieee80211_if_init_conf *conf)
{
@@ -683,6 +767,7 @@
p54_set_filter(dev, 0, priv->mac_addr, NULL, 0, 1, 0, 0xF642);
p54_set_filter(dev, 0, priv->mac_addr, NULL, 1, 0, 0, 0xF642);
+ p54_set_vdcf(dev);
switch (conf->type) {
case IEEE80211_IF_TYPE_STA:
@@ -712,8 +797,11 @@
static int p54_config(struct ieee80211_hw *dev, struct ieee80211_conf *conf)
{
- p54_set_freq(dev, cpu_to_le16(conf->freq));
- return 0;
+ int ret;
+
+ ret = p54_set_freq(dev, cpu_to_le16(conf->freq));
+ p54_set_vdcf(dev);
+ return ret;
}
static int p54_config_interface(struct ieee80211_hw *dev, int if_id,
@@ -727,6 +815,26 @@
return 0;
}
+static int p54_conf_tx(struct ieee80211_hw *dev, int queue,
+ const struct ieee80211_tx_queue_params *params)
+{
+ struct p54_common *priv = dev->priv;
+ struct p54_tx_control_vdcf *vdcf;
+
+ vdcf = (struct p54_tx_control_vdcf *)(((struct p54_control_hdr *)
+ ((void *)priv->cached_vdcf + priv->tx_hdr_len))->data);
+
+ if ((params) && !((queue < 0) || (queue > 4))) {
+ P54_SET_QUEUE(vdcf->queue[queue], params->aifs,
+ params->cw_min, params->cw_max, params->burst_time);
+ } else
+ return -EINVAL;
+
+ p54_set_vdcf(dev);
+
+ return 0;
+}
+
static int p54_get_stats(struct ieee80211_hw *dev,
struct ieee80211_low_level_stats *stats)
{
@@ -737,7 +845,13 @@
static int p54_get_tx_stats(struct ieee80211_hw *dev,
struct ieee80211_tx_queue_stats *stats)
{
- /* TODO.. probably should let lower level deal with this */
+ struct p54_common *priv = dev->priv;
+ unsigned int i;
+
+ for (i = 0; i < dev->queues; i++)
+ memcpy(&stats->data[i], &priv->tx_stats.data[i],
+ sizeof(stats->data[i]));
+
return 0;
}
@@ -747,6 +861,7 @@
.remove_interface = p54_remove_interface,
.config = p54_config,
.config_interface = p54_config_interface,
+ .conf_tx = p54_conf_tx,
.get_stats = p54_get_stats,
.get_tx_stats = p54_get_tx_stats
};
@@ -784,12 +899,29 @@
dev->channel_change_time = 1000; /* TODO: find actual value */
dev->max_rssi = 100;
- dev->queues = 1;
+ /* (hard) queue limits */
+ priv->tx_stats.data[0].limit = 3;
+ priv->tx_stats.data[1].limit = 4;
+ priv->tx_stats.data[2].limit = 3;
+ priv->tx_stats.data[3].limit = 1;
+
+ dev->queues = 4;
dev->extra_tx_headroom = sizeof(struct p54_control_hdr) + 4 +
sizeof(struct p54_tx_control_allocdata);
+ priv->cached_vdcf = kzalloc(sizeof(struct p54_tx_control_vdcf) +
+ priv->tx_hdr_len + sizeof(struct p54_control_hdr), GFP_KERNEL);
+
+ if (!priv->cached_vdcf) {
+ ieee80211_free_hw(dev);
+ return NULL;
+ }
+
+ p54_init_vdcf(dev);
+
for (i = 0; i < 2; i++) {
if (ieee80211_register_hwmode(dev, &priv->modes[i])) {
+ kfree(priv->cached_vdcf);
ieee80211_free_hw(dev);
return NULL;
}
@@ -805,6 +937,7 @@
kfree(priv->iq_autocal);
kfree(priv->output_limit);
kfree(priv->curve_data);
+ kfree(priv->cached_vdcf);
}
EXPORT_SYMBOL_GPL(p54_free_common);
Chr wrote:
> On Thursday, 23. August 2007, Hans de Goede wrote:
>> Maybe it would be an idea to dump the eeprom from the driver with the 2.4.12.0
>> firmware, and then fake the eeprom in the driver using newer firmware to see if
>> the eeprom reading is the only problem with newer firmware and my card ?
>
> Hmm, I don't think that the firmware somehow changes the eeprom.
>
I think you misunderstood me. The driver fails to load when using newer
firmware with a "can not read eeprom" error. So I have the idea to add a couple
of printk's printing all the important bits from the eeprom using the 2.4.12.0
firmware, then modify the driver to hardcode these bits from the eeprom in to
the driver and then try newer firmware with the driver with the hardcoded bits
in. This way I want to see if the reading of the eeprom is the only problem, or
if there are other problems too when using newer firmware. Does this sound like
a plan or is it a waste of time?
Regards,
Hans
On Thursday, 23. August 2007, Hans de Goede wrote:
>
> I'm afraid that my reception quality varies wildly. I don't know why, I'll try
> to configure a different channel on the AP the next time I do some testing.
>
Ok, maybe someone has cooked a meal in a microwave oven, or
something like that...
>
> Replying to other mail in one go:
>
> Chr wrote:
> > I made two patches:
> >
> > the p54-pull-padding.diff should finally fix the rate algorithm for
> "everyone" and as
> > a bonus for developers: it adds a printk for the firmware revision p54 is using.
> >
>
> Cool I'll give this a try tonight, I really wanted to try it sooner, but ...
>
k, I'll wait ;-)
BTW: There's already a newer version of it... see attachment.
>
> Hmm, could this be made conditionally on the firmware revision perhaps? I don't
> like having to patch my kernel every update, and more importantly, my card is a
> pretty popular el cheapo sitecom, which are stacked by the dozen by every
> computershop in town, so it would be nice if this worked out of the box.
>
Of course! This patch is just a "test" patch, because you never know if it's "this" or "that"...
Probably, it's only necessary to hardcode "txhdr->frame_type = 4;" in p54_tx again.
> I'll try to see if 2.5.2.0 will work with my card, I think I've tried before
> but you never know, will 2.5.2.0 be good enough for the QoS/WME/WMM/IEEE802.11e
> features?
AFAIK Michael uses this revision too and he would not have merged the QoS patch, if it
was completly unusable or faulty... So I think 2.5.2 will be fine, if it works with your card.
(However, 2.7.0.0 is recommend, because it's one of the few FWs for which we have
additional debugging and testing facilities...)
> Maybe it would be an idea to dump the eeprom from the driver with the 2.4.12.0
> firmware, and then fake the eeprom in the driver using newer firmware to see if
> the eeprom reading is the only problem with newer firmware and my card ?
Hmm, I don't think that the firmware somehow changes the eeprom.
Thanks,
Chr.
From: Christian Lamparter <[email protected]>
This patch fixes a regression with older (pre 2.5.2.0) firmwares, that don't
support the QoS queues yet...
Thanks to Hans de Goede <[email protected]> for reporting and debugging it.
Signed-off-by: Christian Lamparter <[email protected]>
---
>Why bother allocating a temporary buffer for firmware version string? Just
>keep a pointer to where it's located. (unless it's not null terminated..)
Ok
On Friday 31 August 2007 17:27, Chr wrote:
> This patch fixes a regression with older (pre 2.5.2.0) firmwares, that
> don't support the QoS queues yet...
>
Why bother allocating a temporary buffer for firmware version string? Just
keep a pointer to where it's located. (unless it's not null terminated..)
There's two extra unnecessary lines added to the end of p54_parse_firmware.
Thanks,
-Michael Wu