* Re: [PATCH] wireless: orphan ipw2x00 drivers
From: maximilian attems @ 2010-06-23 16:39 UTC (permalink / raw)
To: reinette chatre
Cc: Zhu, Yi, linville@tuxdriver.com, linux-wireless@vger.kernel.org
In-Reply-To: <1277311325.25793.2299.camel@rchatre-DESK>
On Wed, Jun 23, 2010 at 09:42:05AM -0700, reinette chatre wrote:
> On Wed, 2010-06-23 at 09:33 -0700, maximilian attems wrote:
> > On Thu, 10 Jun 2010, reinette chatre wrote:
> >
> > > On Wed, 2010-06-09 at 18:44 -0700, Zhu Yi wrote:
> > > > Signed-off-by: Zhu Yi <yi.zhu@intel.com>
> > >
> > > Not sure if it is needed but the sourceforge pages will still have the
> > > firmware available for download. We are in process of cleaning those
> > > pages up.
> >
> > while you are at it:
> > it be cool to have the firmware license also "cleaned up" to allow
> > at least distribution.
>
> Please see http://ipw2100.sourceforge.net/firmware_faq.php
I know that strange page and we (Debian) adhere to it.
still sad that you don't care to change it now that you don't care
anymore about the driver.
^ permalink raw reply
* Re: [RFC/RFT] minstrel_ht: new rate control module for 802.11n
From: Felix Fietkau @ 2010-06-23 17:07 UTC (permalink / raw)
To: Björn Smedman
Cc: linux-wireless, Derek Smithies, Benoit PAPILLAULT,
Luis R. Rodriguez, Christian Lamparter, Johannes Berg,
ath9k-devel
In-Reply-To: <AANLkTilWfp6LzCYhxFweqAP_GceRz5PQBIBl5AksLKUf@mail.gmail.com>
On 2010-06-23 6:36 PM, Björn Smedman wrote:
> 2010/3/2 Felix Fietkau <nbd@openwrt.org>:
>> On 2010-03-02 4:47 PM, Björn Smedman wrote:
>>> 2010/3/2 Felix Fietkau <nbd@openwrt.org>:
> [snip]
>>> You mean the hardware interprets the block-ack and keeps retrying the
>>> un-acked frames? I thought it stopped as soon as it got a block-ack to
>>> let software sort out the acked and un-acked frames and handle the
>>> "partial" A-MPDU retry.
>> Not sure, actually. I just looked at the ath9k tx path again, and it
>> seems that you're right. However it looks like it's not sending rate
>> control updates until it's done with the software retry, so that's
>> probably the reason why I wasn't able to make it more precise yet.
>
> I had another look at the code now and if I read it correctly this
> delay in the rate control feedback is really scary. In the extreme
> case where all the rates in the MRR stop working you have to make 10
> (ATH_MAX_SW_RETRIES) aggregate software retries (of about 20 frames
> each) with approx 10 hardware retries each before you give the rate
> control algorithm any feedback whatsoever. That is a worst case of
> several thousand (pointless) subframe retransmissions before the rate
> control algorithm has a chance to adjust...
Yes, the extreme case is currently not handled properly. However the
extreme case is also extremely unlikely to trigger. With minstrel_ht,
the max_prob_rate is always in the MRR series. If the conditions jump
from all rates working down to even max_prob_rate failing, then
something must be so wrong with the radio, that there's probably no
possibility of a graceful fallback at all. I do agree that this should
be fixed, though.
> If I'm not wrong above then the rate control feedback must also be
> incorrect: a disaster of that magnitude simply cannot be conveyed to
> the rate control algorithm through the thin tx status interface. As
> far as I can tell, whenever the first subframe of an aggregate fails
> and is software retried, the rate control feedback for that aggregate
> is lost (ath_tx_rc_status() is never called with update_rc = true in
> xmit.c).
I think you misread that part. The loop iterates over all subframes in
the aggregate, and the first successful or swretry-expired frame will
trigger an AMPDU status report, which will update the RC. The first
subframe of the A-MPDU is not getting any special treatment here.
> Any ideas on how to fix this? To me the aggregation and rate control
> code seems to need a major overhaul, something which would require
> changes to the interface between mac80211 and drivers, e.g. ath9k.
> That's out of my league unfortunately...
I've already made a lot of progress rewriting the entire aggregation
logic (it'll be in mac80211 instead of ath9k).
As soon as I'm done fixing the current batch of bugs that I'm debugging
at the moment, I will post my changes as RFC on the linux-wireless list.
- Felix
^ permalink raw reply
* Re: 2.6.34 kernel + compat-wireless + Bluez-4.66 --- no Bluetooth devices
From: Andrei Moraru @ 2010-06-23 17:19 UTC (permalink / raw)
To: Luis R. Rodriguez; +Cc: linux-wireless
In-Reply-To: <AANLkTimcw-AVVFGbSJioJIcVw75tzUYCKt4plNMtQJr1@mail.gmail.com>
On Wed, Jun 23, 2010 at 7:30 PM, Luis R. Rodriguez <mcgrof@gmail.com> wrote:
> On Wed, Jun 23, 2010 at 2:04 AM, Andrei Moraru
> <andrei.moraru.n@gmail.com> wrote:
>> Hello,
>>
>> I have a machine with Centos 5.4, kernel version 2.6.34, Bluez-4.66,
>> compat-wireless for 2.6.34 kernel version.
>>
>> The system knows about USB Bluetooth adapters
>>
>> [root@voip ~]# lsusb
>> Bus 002 Device 004: ID 1131:1001 Integrated System Solution Corp.
>> KY-BT100 Bluetooth Adapter
>> Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
>> Bus 002 Device 002: ID 0a12:0001 Cambridge Silicon Radio, Ltd
>> Bluetooth Dongle (HCI mode)
>> Bus 002 Device 003: ID 0a12:0001 Cambridge Silicon Radio, Ltd
>> Bluetooth Dongle (HCI mode)
>> Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
>>
>> However, hciconfig shows no devices:
>>
>> [root@voip ~]# hciconfig -a
>> [root@voip ~]#
>>
>>
>> Also, hcitool dev
>>
>> [root@voip ~]# hcitool dev
>> Devices:
>>
>> the dmesg output about bluetooth shows
>>
>> Bluetooth: Core ver 2.15
>> NET: Registered protocol family 31
>> Bluetooth: HCI device and connection manager initialized
>> Bluetooth: HCI socket layer initialized
>> Bluetooth: L2CAP ver 2.14
>> Bluetooth: L2CAP socket layer initialized
>> Bluetooth: SCO (Voice Link) ver 0.6
>> Bluetooth: SCO socket layer initialized
>> Bluetooth: HIDP (Human Interface Emulation) ver 1.2
>> Bluetooth: RFCOMM TTY layer initialized
>> Bluetooth: RFCOMM socket layer initialized
>> Bluetooth: RFCOMM ver 1.11
>> Bluetooth: BNEP (Ethernet Emulation) ver 1.3
>> Bluetooth: BNEP filters: protocol multicast
>>
>>
>> Please suggest your opinions.
>
> dmesg looks good, repost to linux-bluetooth and show also the version
> of compat-wireless you used.
>
> Luis
>
Thanks Luis.
I solved the issue with no BT devices on hciconfig -a
The problem was that 2.6.34 kernel was built without HCI USB support.
So, I have rebuilt it, rebooted, then the hciconfig -a shows me BT
dongles.
The sugestion was made to me on #bluez-users on freenode
Ok, after detection of BT devices, i rebuilt the compat-wireless with
new kernel sources. When make btload was issued, then the dmesg output
was many lines similar to:
Jun 23 17:13:31 voip kernel: l2cap: Unknown symbol bt_sock_wait_state
Jun 23 17:13:31 voip kernel: l2cap: disagrees about version of symbol
bt_sock_register
The steps to get rid of that errors were:
1) be sure no bluetooth related file is in use:
the command:
lsof | grep blue*
should return nothing
2) remove all Bluez-4.66 files (hciconfig, libbluetooth.so, etc)
3) rebuilt the Bluez-4.66
4) start the compat-wireless stack
make btload
Now, the dmesg shows me clear output,
Bluetooth: Core ver 2.15
NET: Registered protocol family 31
Bluetooth: HCI device and connection manager initialized
Bluetooth: HCI socket layer initialized
Bluetooth: Generic Bluetooth USB driver ver 0.6
usbcore: registered new interface driver btusb
Bluetooth: L2CAP ver 2.14
Bluetooth: L2CAP socket layer initialized
Bluetooth: SCO (Voice Link) ver 0.6
Bluetooth: SCO socket layer initialized
Bluetooth: HIDP (Human Interface Emulation) ver 1.2
Bluetooth: RFCOMM TTY layer initialized
Bluetooth: RFCOMM socket layer initialized
Bluetooth: RFCOMM ver 1.11
Bluetooth: BNEP (Ethernet Emulation) ver 1.3
Bluetooth: BNEP filters: protocol multicast
Thats all.
Andrei Moraru.
^ permalink raw reply
* Re: [PATCH] ath9k: Fix the LED behaviour in idle unassociated state.
From: Pavel Roskin @ 2010-06-23 17:55 UTC (permalink / raw)
To: Vivek Natarajan; +Cc: linville, linux-wireless
In-Reply-To: <1277275109-4662-1-git-send-email-vnatarajan@atheros.com>
On Wed, 2010-06-23 at 12:08 +0530, Vivek Natarajan wrote:
> LED should be ON when the radio is put into FULL SLEEP mode during the idle
> unassociated state.
Why? Is there any written policy for the LED behavior? I think we want
to conserve power if sleeping, which means turning LEDs off.
Or is it a workaround for some quirk in Atheros hardware?
In any case, I don't like the new comment. The comment says "Keep the
LED on...", but the code is still turning the LED off.
--
Regards,
Pavel Roskin
^ permalink raw reply
* [PATCH] ath9k: declare MODULE_FIRMWARE for ath9k_htc
From: John W. Linville @ 2010-06-23 18:23 UTC (permalink / raw)
To: linux-wireless; +Cc: ath9k-devel, John W. Linville
Signed-off-by: John W. Linville <linville@tuxdriver.com>
---
drivers/net/wireless/ath/ath9k/hif_usb.c | 5 +++++
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/hif_usb.c b/drivers/net/wireless/ath/ath9k/hif_usb.c
index 74bc80f..4949f83 100644
--- a/drivers/net/wireless/ath/ath9k/hif_usb.c
+++ b/drivers/net/wireless/ath/ath9k/hif_usb.c
@@ -16,6 +16,11 @@
#include "htc.h"
+/* identify firmware images */
+MODULE_FIRMWARE("ar7010.fw");
+MODULE_FIRMWARE("ar7010_1_1.fw");
+MODULE_FIRMWARE("ar9271.fw");
+
static struct usb_device_id ath9k_hif_usb_ids[] = {
{ USB_DEVICE(0x0cf3, 0x9271) }, /* Atheros */
{ USB_DEVICE(0x0cf3, 0x1006) }, /* Atheros */
--
1.7.0.1
^ permalink raw reply related
* Re: [RFC/RFT] minstrel_ht: new rate control module for 802.11n
From: Björn Smedman @ 2010-06-23 18:47 UTC (permalink / raw)
To: Felix Fietkau
Cc: linux-wireless, Derek Smithies, Benoit PAPILLAULT,
Luis R. Rodriguez, Christian Lamparter, Johannes Berg,
ath9k-devel
In-Reply-To: <4C223F58.3060509@openwrt.org>
2010/6/23 Felix Fietkau <nbd@openwrt.org>:
> On 2010-06-23 6:36 PM, Björn Smedman wrote:
[snip]
>> If I'm not wrong above then the rate control feedback must also be
>> incorrect: a disaster of that magnitude simply cannot be conveyed to
>> the rate control algorithm through the thin tx status interface. As
>> far as I can tell, whenever the first subframe of an aggregate fails
>> and is software retried, the rate control feedback for that aggregate
>> is lost (ath_tx_rc_status() is never called with update_rc = true in
>> xmit.c).
> I think you misread that part. The loop iterates over all subframes in
> the aggregate, and the first successful or swretry-expired frame will
> trigger an AMPDU status report, which will update the RC. The first
> subframe of the A-MPDU is not getting any special treatment here.
You're right, I missed that part. And I guess that's also why the
worst case is so rare.
But on the other hand doesn't that also mean that MRR rates and counts
in the tx status will be incorrect? I.e. one set of rates/counts used
to transmit the aggregate (first subframe) and (possibly) another set
reported back in tx status (first acked/expired subframe)?
Also, bf->bf_retries is used in ath_tx_rc_status() but the logic makes
no sense if bf_retries holds the number of software retries...
>> Any ideas on how to fix this? To me the aggregation and rate control
>> code seems to need a major overhaul, something which would require
>> changes to the interface between mac80211 and drivers, e.g. ath9k.
>> That's out of my league unfortunately...
> I've already made a lot of progress rewriting the entire aggregation
> logic (it'll be in mac80211 instead of ath9k).
> As soon as I'm done fixing the current batch of bugs that I'm debugging
> at the moment, I will post my changes as RFC on the linux-wireless list.
Very nice to hear a rewrite is in progress. :) Looking forward to those patches.
> - Felix
>
/Björn
^ permalink raw reply
* [PATCH v2] ath9k: declare MODULE_FIRMWARE for ath9k_htc
From: John W. Linville @ 2010-06-23 18:50 UTC (permalink / raw)
To: linux-wireless; +Cc: ath9k-devel, John W. Linville
In-Reply-To: <1277317393-20245-1-git-send-email-linville@tuxdriver.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
---
v2 -> avoid duplicate strings for firmware names and simultaneously
attract attention to MODULE_FIRMWARE section in the even of
any updates
drivers/net/wireless/ath/ath9k/hif_usb.c | 15 ++++++++++++---
1 files changed, 12 insertions(+), 3 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/hif_usb.c b/drivers/net/wireless/ath/ath9k/hif_usb.c
index 74bc80f..ad9134b 100644
--- a/drivers/net/wireless/ath/ath9k/hif_usb.c
+++ b/drivers/net/wireless/ath/ath9k/hif_usb.c
@@ -16,6 +16,15 @@
#include "htc.h"
+/* identify firmware images */
+#define FIRMWARE_AR7010 "ar7010.fw"
+#define FIRMWARE_AR7010_1_1 "ar7010_1_1.fw"
+#define FIRMWARE_AR9271 "ar9271.fw"
+
+MODULE_FIRMWARE(FIRMWARE_AR7010);
+MODULE_FIRMWARE(FIRMWARE_AR7010_1_1);
+MODULE_FIRMWARE(FIRMWARE_AR9271);
+
static struct usb_device_id ath9k_hif_usb_ids[] = {
{ USB_DEVICE(0x0cf3, 0x9271) }, /* Atheros */
{ USB_DEVICE(0x0cf3, 0x1006) }, /* Atheros */
@@ -890,12 +899,12 @@ static int ath9k_hif_usb_probe(struct usb_interface *interface,
case 0x7010:
case 0x9018:
if (le16_to_cpu(udev->descriptor.bcdDevice) == 0x0202)
- hif_dev->fw_name = "ar7010_1_1.fw";
+ hif_dev->fw_name = FIRMWARE_AR7010_1_1;
else
- hif_dev->fw_name = "ar7010.fw";
+ hif_dev->fw_name = FIRMWARE_AR7010;
break;
default:
- hif_dev->fw_name = "ar9271.fw";
+ hif_dev->fw_name = FIRMWARE_AR9271;
break;
}
--
1.7.0.1
^ permalink raw reply related
* Compat-wireless release for 2010-06-23 is baked
From: Compat-wireless cronjob account @ 2010-06-23 19:03 UTC (permalink / raw)
To: linux-wireless, linux-bluetooth
>From git://git.kernel.org/pub/scm/linux/kernel/git/mcgrof/compat-wireless-2.6
7df472d..87dca92 master -> origin/master
8e2a8ea..dac1811 wl -> origin/wl
>From git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next
41d99c6..951149c history -> origin/history
+ d82e647...fca5ab0 master -> origin/master (forced update)
* [new tag] next-20100623 -> next-20100623
compat-wireless code metrics
498619 - Total upstream lines of code being pulled
1410 - backport code changes
1177 - backport code additions
233 - backport code deletions
5748 - backport from compat module
7158 - total backport code
1.4356 - % of code consists of backport work
1218 - Crap changes not yet posted
1179 - Crap additions not yet posted
39 - Crap deletions not yet posted
0.2443 - % of crap code
Base tree: linux-next.git
Base tree version: next-20100623
compat-wireless release: compat-wireless-2010-06-17-4-g87dca92
^ permalink raw reply
* Re: [ath5k-devel] [PATCH v2] ath5k: disable ASPM
From: Johannes Stezenbach @ 2010-06-23 19:07 UTC (permalink / raw)
To: Luis R. Rodriguez
Cc: Matthew Garrett, Jussi Kivilinna, Maxim Levitsky, David Quan,
Bob Copeland, Luis R. Rodriguez, ath5k-devel, linux-wireless,
linux-kernel, Jonathan May, Tim Gardner
In-Reply-To: <AANLkTilyQB-q8Xf9Mu3F5SnKbRqbBuLjbdx8EcyCt_0v@mail.gmail.com>
On Wed, Jun 23, 2010 at 09:28:57AM -0700, Luis R. Rodriguez wrote:
> On Wed, Jun 23, 2010 at 7:39 AM, Johannes Stezenbach <js@sig21.net> wrote:
> >
> > If enabling ASPM comes with a performance penalty (which is not unexpected,
> > there is usually a tradeoff between performance and power consumption),
> > do you think a boot time option (pcie_aspm=) or compile time option
> > (CONFIG_PCIEASPM) is the right user interface?
> >
> >
> > But meanwhile I found that CONFIG_PCIEASPM has a runtime
> > interface, /sys/module/pcie_aspm/parameters/policy.
> > http://lwn.net/Articles/266585/
>
> Same thing, its to be used by developers not users, damn it we should
> just remove this crap.
Hopefully I got at least the message across that there is
a good reason to have an interface where the user can
select the ASPM policy?
If your answer is "reboot and change the BIOS setting" then
you didn't get what I was talking about _at all_.
Also, having now briefly looked at pcie/aspm.c, I do not share your
opinion that it is crap, except maybe for the force enable.
If I read it correctly it will by default keep the BIOS settings,
but offers a per-device sysfs attribute to change the ASPM link
state, and it seems to do sanity checking, and takes care that
both ends of the link agree.
(disclaimer: I haven't tested any of it, only briefly looked at the code)
Johannes
^ permalink raw reply
* Re: [ath5k-devel] [PATCH v2] ath5k: disable ASPM
From: Johannes Stezenbach @ 2010-06-23 19:23 UTC (permalink / raw)
To: Luis R. Rodriguez
Cc: Matthew Garrett, Jussi Kivilinna, Maxim Levitsky, David Quan,
Bob Copeland, Luis R. Rodriguez, ath5k-devel, linux-wireless,
linux-kernel, Jonathan May, Tim Gardner
In-Reply-To: <AANLkTin1fAAgYTYegqaadkYIYP2NXRNRzCR48e-uIgYV@mail.gmail.com>
On Tue, Jun 22, 2010 at 12:37:01PM -0700, Luis R. Rodriguez wrote:
> On Tue, Jun 22, 2010 at 12:31 PM, Johannes Stezenbach <js@sig21.net> wrote:
> > I have a Samsung N130 netbook which has a BIOS setting
> > called "CPU Power Saving Mode". When enabled it activates
> > ASPM L1 and L0s for the ethernet chip (Realtek RTL8102e, 100Mbit)
> > and the PCIE bridge (with the BIOS setting off it's just L1).
> > The result is that the ethernet througput is reduced to 25Mbit/s.
> > (The BIOS setting does not activa L0s for the Atheros AR9285 WLAN.)
>
> L0s is not going to buy you much gains, getting at least L1 will
> however. L0s is just a further enhancement. I recommend you test by
> enabling L1 and L0s, check how longer your battery lasts and then test
> again with just L1. Then test without both L1 and L0s.
What I did was to dump lspci output to a file, for both settings
of the BIOS option, and then diff.
00:1c.2 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express Port 3 (rev 02) (prog-if 00 [Normal decode])
...
LnkCap: Port #3, Speed 2.5GT/s, Width x1, ASPM L0s L1, Latency L0 <256ns, L1 <4us
ClockPM- Surprise- LLActRep+ BwNot-
- LnkCtl: ASPM L1 Enabled; RCB 64 bytes Disabled- Retrain- CommClk+
+ LnkCtl: ASPM L0s L1 Enabled; RCB 64 bytes Disabled- Retrain- CommClk+
ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
LnkSta: Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+ DLActive+ BWMgmt- ABWMgmt-
03:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8101E/RTL8102E PCI Express Fast Ethernet controller (rev 02)
...
LnkCap: Port #0, Speed 2.5GT/s, Width x1, ASPM L0s L1, Latency L0 <512ns, L1 <64us
ClockPM+ Surprise- LLActRep- BwNot-
- LnkCtl: ASPM L1 Enabled; RCB 64 bytes Disabled- Retrain- CommClk+
+ LnkCtl: ASPM L0s L1 Enabled; RCB 64 bytes Disabled- Retrain- CommClk+
ExtSynch- ClockPM+ AutWidDis- BWInt- AutBWInt-
LnkSta: Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt-
I suspect the performance penalty is because L0s is entered very often
even during ethernet bulk transfer, whereas L1 is only entered
when the link is idle for longer time.
The difference in battery run time due to the BIOS option is
significant (IIRC, it's been a while back), but I don't know
what else the BIOS option changes.
Johannes
^ permalink raw reply
* Re: [RFC/RFT] minstrel_ht: new rate control module for 802.11n
From: Felix Fietkau @ 2010-06-23 19:27 UTC (permalink / raw)
To: Björn Smedman
Cc: linux-wireless, Derek Smithies, Benoit PAPILLAULT,
Luis R. Rodriguez, Christian Lamparter, Johannes Berg,
ath9k-devel
In-Reply-To: <AANLkTilDTZRUk_3iI5NPX0JhqG7N8LtKcE3VSSnqFGk9@mail.gmail.com>
On 2010-06-23 8:47 PM, Björn Smedman wrote:
> 2010/6/23 Felix Fietkau <nbd@openwrt.org>:
>> On 2010-06-23 6:36 PM, Björn Smedman wrote:
> [snip]
>>> If I'm not wrong above then the rate control feedback must also be
>>> incorrect: a disaster of that magnitude simply cannot be conveyed to
>>> the rate control algorithm through the thin tx status interface. As
>>> far as I can tell, whenever the first subframe of an aggregate fails
>>> and is software retried, the rate control feedback for that aggregate
>>> is lost (ath_tx_rc_status() is never called with update_rc = true in
>>> xmit.c).
>> I think you misread that part. The loop iterates over all subframes in
>> the aggregate, and the first successful or swretry-expired frame will
>> trigger an AMPDU status report, which will update the RC. The first
>> subframe of the A-MPDU is not getting any special treatment here.
>
> You're right, I missed that part. And I guess that's also why the
> worst case is so rare.
>
> But on the other hand doesn't that also mean that MRR rates and counts
> in the tx status will be incorrect? I.e. one set of rates/counts used
> to transmit the aggregate (first subframe) and (possibly) another set
> reported back in tx status (first acked/expired subframe)?
No, MRR info is just fine. The retry stats are reported for the whole
A-MPDU, not for indvididual subframes. It's always present in the last
descriptor of the whole batch. Also, since my code cleanup a while ago,
the converted rx/tx status info is not longer part of the allocated
descriptor space, but instead kept on stack in the function that
processes the tx status. This on stack tx status is then passed to the
rc update function, which sends the data to mac80211 along with the
AMPDU tx status report.
> Also, bf->bf_retries is used in ath_tx_rc_status() but the logic makes
> no sense if bf_retries holds the number of software retries...
Hmm, that part might indeed be buggy. I'll review it in detail when I'm
at home again.
- Felix
^ permalink raw reply
* wireless-next-2.6 rebase 2010-06-23
From: John W. Linville @ 2010-06-23 19:42 UTC (permalink / raw)
To: linux-wireless
FYI...in order to avoid merging a patch series with build breakage, I'm
rebasing wireless-next-2.6. The master-2010-06-21 tag is still valid,
but the master-2010-06-22 tag is no longer an ancestor of master.
If you have no idea what I mean, then feel free to ignore this
message. :-) Most people should be using wireless-testing anyway.
Thanks,
John
--
John W. Linville Someday the world will need a hero, and you
linville@tuxdriver.com might be all we have. Be ready.
^ permalink raw reply
* Re: Recent results with BCM4312 on Netbook
From: Larry Finger @ 2010-06-23 20:49 UTC (permalink / raw)
To: Michael Büsch; +Cc: Gábor Stefanik, wireless, b43-dev
In-Reply-To: <4C22014A.3000102@bu3sch.de>
On 06/23/2010 07:42 AM, Michael Büsch wrote:
> Please note that there were some rewrites recently in the kernel
> DMA subsystem. b43 does now use the generic DMA interface, which
> should work on all busses. I would not rule out an error in
> that area, though it's unlikely.
I don't think that is a problem. None of my other 3 systems developed an
error with that change. In addition, the Netbook started working as
mysteriously as it had failed earlier. I just love intermittent cases. ;-)
Larry
^ permalink raw reply
* Re: [PATCH 1/3] libertas: fix build error due to undefined symbol
From: Dan Williams @ 2010-06-23 23:24 UTC (permalink / raw)
To: John W. Linville; +Cc: linux-wireless, dkiran, Johannes Berg
In-Reply-To: <1277303846-17257-1-git-send-email-linville@tuxdriver.com>
On Wed, 2010-06-23 at 10:37 -0400, John W. Linville wrote:
> ERROR: "mesh_handler_def" [drivers/net/wireless/libertas/libertas.ko] undefined!
>
> Caused by a hunk missed by "Libertas: cfg80211 support" when building
> with CONFIG_WIRELESS_EXT enabled.
>
> Signed-off-by: John W. Linville <linville@tuxdriver.com>
Acked-by: Dan Williams <dcbw@redhat.com>
> ---
> drivers/net/wireless/libertas/mesh.c | 3 ---
> drivers/net/wireless/libertas/mesh.h | 5 -----
> 2 files changed, 0 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/net/wireless/libertas/mesh.c b/drivers/net/wireless/libertas/mesh.c
> index 00b36b0..bc5bc13 100644
> --- a/drivers/net/wireless/libertas/mesh.c
> +++ b/drivers/net/wireless/libertas/mesh.c
> @@ -370,9 +370,6 @@ int lbs_add_mesh(struct lbs_private *priv)
>
> SET_NETDEV_DEV(priv->mesh_dev, priv->dev->dev.parent);
>
> -#ifdef WIRELESS_EXT
> - mesh_dev->wireless_handlers = &mesh_handler_def;
> -#endif
> mesh_dev->flags |= IFF_BROADCAST | IFF_MULTICAST;
> /* Register virtual mesh interface */
> ret = register_netdev(mesh_dev);
> diff --git a/drivers/net/wireless/libertas/mesh.h b/drivers/net/wireless/libertas/mesh.h
> index e257330..84ea248 100644
> --- a/drivers/net/wireless/libertas/mesh.h
> +++ b/drivers/net/wireless/libertas/mesh.h
> @@ -70,11 +70,6 @@ void lbs_persist_config_init(struct net_device *net);
> void lbs_persist_config_remove(struct net_device *net);
>
>
> -/* WEXT handler */
> -
> -extern struct iw_handler_def mesh_handler_def;
> -
> -
> /* Ethtool statistics */
>
> struct ethtool_stats;
^ permalink raw reply
* Re: [PATCH 2/3] libertas: unmangle capability value
From: Dan Williams @ 2010-06-23 23:24 UTC (permalink / raw)
To: John W. Linville; +Cc: linux-wireless, dkiran, Johannes Berg
In-Reply-To: <1277303846-17257-2-git-send-email-linville@tuxdriver.com>
On Wed, 2010-06-23 at 10:37 -0400, John W. Linville wrote:
> Address fall-out from patch converting libertas to use cfg80211...
>
> +drivers/net/wireless/libertas/cfg.c:1844:13: warning: incorrect type in assignment (different base types)
> +drivers/net/wireless/libertas/cfg.c:1844:13: expected unsigned short [unsigned] [usertype] capability
> +drivers/net/wireless/libertas/cfg.c:1844:13: got restricted __le16 [usertype] <noident>
>
> Signed-off-by: John W. Linville <linville@tuxdriver.com>
Acked-by: Dan Williams <dcbw@redhat.com>
> ---
> drivers/net/wireless/libertas/cfg.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/net/wireless/libertas/cfg.c b/drivers/net/wireless/libertas/cfg.c
> index 23c1dc6..f36cc97 100644
> --- a/drivers/net/wireless/libertas/cfg.c
> +++ b/drivers/net/wireless/libertas/cfg.c
> @@ -1841,7 +1841,7 @@ static int lbs_ibss_start_new(struct lbs_private *priv,
> if (MRVL_FW_MAJOR_REV(priv->fwrelease) <= 8)
> cmd.probedelay = cpu_to_le16(CMD_SCAN_PROBE_DELAY_TIME);
> /* TODO: mix in WLAN_CAPABILITY_PRIVACY */
> - capability = cpu_to_le16(WLAN_CAPABILITY_IBSS);
> + capability = WLAN_CAPABILITY_IBSS;
> cmd.capability = cpu_to_le16(capability);
> lbs_add_rates(cmd.rates);
>
^ permalink raw reply
* Re: [PATCH 3/3] libertas: mark lbs_ret_802_11d_domain_info static
From: Dan Williams @ 2010-06-23 23:24 UTC (permalink / raw)
To: John W. Linville; +Cc: linux-wireless, dkiran, Johannes Berg
In-Reply-To: <1277303846-17257-3-git-send-email-linville@tuxdriver.com>
On Wed, 2010-06-23 at 10:37 -0400, John W. Linville wrote:
> Probably little risk of namespace polution, but good practice... :-)
>
> Signed-off-by: John W. Linville <linville@tuxdriver.com>
Acked-by: Dan Williams <dcbw@redhat.com>
> ---
> drivers/net/wireless/libertas/cmdresp.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/net/wireless/libertas/cmdresp.c b/drivers/net/wireless/libertas/cmdresp.c
> index b4bc103..a0d9482 100644
> --- a/drivers/net/wireless/libertas/cmdresp.c
> +++ b/drivers/net/wireless/libertas/cmdresp.c
> @@ -103,7 +103,7 @@ static int lbs_ret_reg_access(struct lbs_private *priv,
> * @param resp pointer to command response buffer
> * @return 0; -1
> */
> -int lbs_ret_802_11d_domain_info(struct cmd_ds_command *resp)
> +static int lbs_ret_802_11d_domain_info(struct cmd_ds_command *resp)
> {
> struct cmd_ds_802_11d_domain_info *domaininfo =
> &resp->params.domaininforesp;
^ permalink raw reply
* PCI error for some CM9 chipsets when using ath5k
From: Peizhao Hu @ 2010-06-23 23:36 UTC (permalink / raw)
To: linux-wireless
Hi
I have a number of CM9 cards that crash every time I reload ath5k (compat-wireless-2010-05-24) with the following error message. The strange thing is that it only happen to my newer CM9 cards (AR5213A-001 chipset), older version cards (AR5213A-00 chipset) work fine. The same card works fine if I use madwifi as the driver. When I replace the CM9 card with a EMP-8602 PLUS-S card, the ath5k seems working ok as well.
Anyone know why and how to fix it?
dmesg output when I reload the driver
========================
ath_rate_minstrel: unloaded
wlan: mac acl policy unregistered
wlan: driver unloaded
ath_pci: driver unloaded
ath_hal: driver unloaded
ath9k: Driver unloaded
cfg80211: Calling CRDA to update world regulatory domain
cfg80211: Calling CRDA for country: AU
ath5k 0000:00:14.0: registered as 'phy0'
ath: EEPROM regdomain: 0x0
ath: EEPROM indicates default country code should be used
ath: doing EEPROM country->regdmn map search
ath: country maps to regdmn code: 0x3a
ath: Country alpha2 being used: US
ath: Regpair used: 0x3a
phy0: Selected rate control algorithm 'minstrel'
ath5k phy0: Atheros AR5213A chip found (MAC: 0x59, PHY: 0x43)
ath5k phy0: RF5112B multiband radio found (0x36)
cfg80211: Calling CRDA for country: US
cfg80211: Current regulatory domain intersected:
(start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp)
(2402000 KHz - 2472000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
(2457000 KHz - 2472000 KHz @ 15000 KHz), (300 mBi, 2000 mBm)
(5170000 KHz - 5250000 KHz @ 40000 KHz), (300 mBi, 1700 mBm)
(5735000 KHz - 5835000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
error message right after the reload
====================
root@OpenWrt:/# PCI error 1 at PCI addr 0x10008020
Data bus error, epc == 87c468e0, ra == 87c468d8
Oops[#1]:
Cpu 0
$ 0 : 00000000 806b0000 deadc0de b0000000
$ 4 : 00000002 b0008034 b0000000 00000000
$ 8 : 0000000a 00000000 00000001 0000004d
$12 : 00000050 87defb98 ca62c1d6 87defc40
$16 : 87e24000 00008024 00008020 00000001
$20 : 00001f30 00001ef0 000003e8 018003e8
$24 : 00000000 8f1bbcdc
$28 : 87dee000 87defce0 00000064 87c468d8
Hi : 00000000
Lo : 00000000
epc : 87c468e0 ath5k_hw_reset_tsf+0x44/0x90 [ath5k]
Tainted: P
ra : 87c468d8 ath5k_hw_reset_tsf+0x3c/0x90 [ath5k]
Status: 1800f403 KERNEL EXL IE
Cause : 1080001c
PrId : 00019374 (MIPS 24Kc)
Modules linked in: ath9k ath9k_common ath9k_hw ath5k ath mac80211 cfg80211 ohci_hcd nf_nat_tftp nf_conntrack_tftp nf_nat_irc nf_conntrack_irc nf_nat_ftp nf_c
onntrack_ftp ipt_MASQUERADE iptable_nat nf_nat xt_NOTRACK iptable_raw xt_state nf_conntrack_ipv4 nf_defrag_ipv4 nf_conntrack ehci_hcd pppoe pppox ipt_REJECT
xt_TCPMSS ipt_LOG xt_comment xt_multiport xt_mac xt_limit iptable_mangle iptable_filter ip_tables xt_tcpudp x_tables nfs ppp_async ppp_generic slhc lockd sun
rpc usbcore nls_base crc_ccitt compat_firmware_class compat arc4 aes_generic deflate ecb cbc leds_gpio button_hotplug gpio_buttons input_polldev input_core [
last unloaded: cfg80211]
Process phy0 (pid: 729, threadinfo=87dee000, task=87884488, tls=00000000)
Stack : 802d0000 806c0c99 806c0c5c 00000000 000003e8 00008030 00008034 87e24000
00000001 87c46ae8 00000002 87defdd0 00000064 87c4e6c8 00000000 87defdd0
00000003 8772e2c0 8772e2c0 87e78200 8772e564 00000002 87defdd0 87e87710
87defdd0 8018d8f0 8755e4e0 00009920 87e787e4 87e8d8d4 00000001 5077ec03
87defdd0 87e78200 8772e2c0 00000000 fffffffe 8772e564 00000000 00000000
...
Call Trace:
[<87c468e0>] ath5k_hw_reset_tsf+0x44/0x90 [ath5k]
[<87c46ae8>] ath5k_hw_init_beacon+0x1bc/0x254 [ath5k]
[<87e87710>] __ieee80211_sta_join_ibss+0x6c/0x43c [mac80211]
[<87e8884c>] ieee80211_ibss_work+0x55c/0x6f8 [mac80211]
[<8008e47c>] worker_thread+0x134/0x1d8
[<80091e60>] kthread+0x7c/0x88
[<8006cbac>] kernel_thread_helper+0x10/0x18
Code: 00642021 8e0400ac 8e060098 <3c030100> 02202821 00439825 0244280b 00c52821 0c05fe7e
--
Regard;
Peizhao Hu
^ permalink raw reply
* Re: [RFC/RFT] minstrel_ht: new rate control module for 802.11n
From: Björn Smedman @ 2010-06-23 23:56 UTC (permalink / raw)
To: Felix Fietkau
Cc: linux-wireless, Derek Smithies, Benoit PAPILLAULT,
Luis R. Rodriguez, Christian Lamparter, Johannes Berg,
ath9k-devel
In-Reply-To: <4C22601E.5050101@openwrt.org>
2010/6/23 Felix Fietkau <nbd@openwrt.org>:
> On 2010-06-23 8:47 PM, Björn Smedman wrote:
[snip]
>> But on the other hand doesn't that also mean that MRR rates and counts
>> in the tx status will be incorrect? I.e. one set of rates/counts used
>> to transmit the aggregate (first subframe) and (possibly) another set
>> reported back in tx status (first acked/expired subframe)?
> No, MRR info is just fine. The retry stats are reported for the whole
> A-MPDU, not for indvididual subframes. It's always present in the last
> descriptor of the whole batch. Also, since my code cleanup a while ago,
> the converted rx/tx status info is not longer part of the allocated
> descriptor space, but instead kept on stack in the function that
> processes the tx status. This on stack tx status is then passed to the
> rc update function, which sends the data to mac80211 along with the
> AMPDU tx status report.
That part looks reasonable to me. The part I don't understand is how
ath_tx_rc_update() builds the 'status' field of the
'ieee80211_tx_info' struct. The way I read the code we rely on the
compiler laying out the 'status' field on top of the 'control' field
(both members of an anonymous union) so that rates and counts align.
Since the 'control' field was (presumably) used to set up the tx we
already have a 'status' field that is almost correct. We only have to
remove the retries that where not actually needed from the counts. But
the presumption seems incorrect in the aggregation case. We may be
adjusting an MRR series that has never been used to control tx, right?
> - Felix
>
/Björn
^ permalink raw reply
* Re: [PATCH] ath9k: Fix the LED behaviour in idle unassociated state.
From: Vasanthakumar Thiagarajan @ 2010-06-24 4:56 UTC (permalink / raw)
To: Pavel Roskin
Cc: Vivek Natarajan, linville@tuxdriver.com,
linux-wireless@vger.kernel.org
In-Reply-To: <1277315740.3562.6.camel@mj>
On Wed, Jun 23, 2010 at 11:25:40PM +0530, Pavel Roskin wrote:
> On Wed, 2010-06-23 at 12:08 +0530, Vivek Natarajan wrote:
> > LED should be ON when the radio is put into FULL SLEEP mode during the idle
> > unassociated state.
>
> Why? Is there any written policy for the LED behavior? I think we want
> to conserve power if sleeping, which means turning LEDs off.
There is no written policy for this behaviour, may be the comment
needs to be changed. It makes sense to turn off the LED to save
power but turning off the LED while wireless interface is still up
is kind of misleading, also this one we got as a requirement
internally and did not want to maintain any private patch.
>
> Or is it a workaround for some quirk in Atheros hardware?
nope.
>
> In any case, I don't like the new comment. The comment says "Keep the
> LED on...", but the code is still turning the LED off.
yeah, this comment seems to be implicit. thanks for the review.
Vasanth
^ permalink raw reply
* RE: [PATCH 1/3] Libertas: cfg80211 support
From: Kiran Divekar @ 2010-06-24 5:38 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless@vger.kernel.org
In-Reply-To: <1277281556.3642.6.camel@jlt3.sipsolutions.net>
> On Mon, 2010-06-14 at 22:01 +0530, Kiran Divekar wrote:
> > Holger Schurig's patch (https://patchwork.kernel.org/patch/64286/)
> > is rebased to latest wireless-testing tree.
Hi Johannes, John,
>
>
> +drivers/net/wireless/libertas/cfg.c:1844:13: warning: incorrect type in
> assignment (different base types)
> +drivers/net/wireless/libertas/cfg.c:1844:13: expected unsigned short
> [unsigned] [usertype] capability
> +drivers/net/wireless/libertas/cfg.c:1844:13: got restricted __le16
> [usertype] <noident>
> +drivers/net/wireless/libertas/cmdresp.c:106:5: warning: symbol
> 'lbs_ret_802_11d_domain_info' was not declared. Should it be static?
>
These errors did not show up during my compilation. I will now make sure to check with various kernel configs. Any other things should I test?
> I'm guessing this patchset is at fault.
>
> Johannes
- Kiran
^ permalink raw reply
* RE: [PATCH 1/3] Libertas: cfg80211 support
From: Johannes Berg @ 2010-06-24 6:03 UTC (permalink / raw)
To: Kiran Divekar; +Cc: linux-wireless@vger.kernel.org
In-Reply-To: <25B60CDC2F704E4E9D88FFD52780CB4C04D64A250E@SC-VEXCH1.marvell.com>
On Wed, 2010-06-23 at 22:38 -0700, Kiran Divekar wrote:
> > +drivers/net/wireless/libertas/cfg.c:1844:13: warning: incorrect type in
> > assignment (different base types)
> > +drivers/net/wireless/libertas/cfg.c:1844:13: expected unsigned short
> > [unsigned] [usertype] capability
> > +drivers/net/wireless/libertas/cfg.c:1844:13: got restricted __le16
> > [usertype] <noident>
> > +drivers/net/wireless/libertas/cmdresp.c:106:5: warning: symbol
> > 'lbs_ret_802_11d_domain_info' was not declared. Should it be static?
> >
>
> These errors did not show up during my compilation. I will now make
> sure to check with various kernel configs. Any other things should I
> test?
These are sparse errors, you need to
make C=2 CF=-D__CHECK_ENDIAN__ drivers/net/wireless/libertas/
johannes
^ permalink raw reply
* Re: [PATCH] rt2500usb: fallback to SW encryption for TKIP+AES
From: Gertjan van Wingerde @ 2010-06-24 6:15 UTC (permalink / raw)
To: Ondrej Zary; +Cc: Ivo Van Doorn, rt2x00 Users List, linux-wireless
In-Reply-To: <201006231257.17684.linux@rainbow-software.org>
On 06/23/10 12:57, Ondrej Zary wrote:
> On Tuesday 22 June 2010, Ondrej Zary wrote:
>> On Tuesday 22 June 2010 21:35:18 Gertjan van Wingerde wrote:
>>> On 06/22/10 12:38, Ondrej Zary wrote:
>>>> Hello,
>>>> I'm (again) trying to solve (debug) a weird problem with Asus WL-167G:
>>>> 0b05:1706 ASUSTek Computer, Inc. WL-167G v1 802.11g Adapter [Ralink
>>>> RT2500USB]
>>>>
>>>> The problem only appears when HW encryption is enabled and connecting
>>>> to an AP configured as WPA2 TKIP+AES.
>>>>
>>>> HW encryption works when the AP is configured as TKIP-only or AES-only.
>>>> It also works when AP is configured as TKIP+AES but wpa_supplicant is
>>>> forced to use TKIP as pairwise cipher (pairwise=TKIP)
>>>>
>>>> SW encryption works always.
>>>>
>>>> The problem is that no packets are transmitted. I can't see DHCP
>>>> broadcasts on other machine using tcpdump. But when I run tcpdump on
>>>> the rt2500usb, I see broadcasts from the other machine, so receive
>>>> seems to work fine.
>>>>
>>>> Added some printk()s to the driver, 6 packets from unsuccessful DHCP:
>>>> [ 371.760073] rt2500usb_write_tx_desc: key_idx=0
>>>> [ 371.852062] rt2500usb_write_tx_desc: key_idx=0
>>>> [ 371.944054] rt2500usb_write_tx_desc: key_idx=0
>>>> [ 372.036068] rt2500usb_write_tx_desc: key_idx=0
>>>> [ 372.128056] rt2500usb_write_tx_desc: key_idx=0
>>>> [ 372.220053] rt2500usb_write_tx_desc: key_idx=0
>>>> [ 372.312053] rt2500usb_write_tx_desc: key_idx=0
>>>> [ 372.404055] rt2500usb_write_tx_desc: key_idx=0
>>>> [ 372.496101] rt2500usb_write_tx_desc: key_idx=0
>>>> [ 372.588077] rt2500usb_write_tx_desc: key_idx=0
>>>> [ 372.688073] rt2500usb_write_tx_desc: key_idx=0
>>>> [ 373.272513] wlan1: authenticate with 00:13:d4:0f:f3:19 (try 1)
>>>> [ 373.272552] rt2500usb_write_tx_desc: key_idx=0
>>>> [ 373.274533] wlan1: authenticated
>>>> [ 373.274564] wlan1: associate with 00:13:d4:0f:f3:19 (try 1)
>>>> [ 373.274581] rt2500usb_write_tx_desc: key_idx=0
>>>> [ 373.277696] wlan1: RX AssocResp from 00:13:d4:0f:f3:19 (capab=0x411
>>>> status=0 aid=1) [ 373.277704] wlan1: associated
>>>> [ 373.308247] rt2500usb_write_tx_desc: key_idx=0
>>>> [ 373.308392] rt2500usb_write_tx_desc: key_idx=0
>>>> [ 373.315999] rt2500usb_write_tx_desc: key_idx=0
>>>> [ 373.340306] rt2x00crypto_key_to_cipher: ALG_CCMP
>>>> [ 373.340318] rt2500usb_config_key key->hw_key_idx=0 SET_KEY
>>>> hw_key_idx = 0 OK [ 373.344521] rt2x00crypto_key_to_cipher: ALG_TKIP
>>>> [ 373.344527] rt2500usb_config_key key->hw_key_idx=0 SET_KEY
>>>> hw_key_idx = 1 OK [ 373.412083] rt2500usb_write_tx_desc: key_idx=0
>>>> [ 375.160233] rt2x00crypto_key_to_cipher: ALG_CCMP
>>>> [ 375.160246] rt2x00crypto_tx_overhead=8
>>>> [ 375.160254] rt2500usb_write_tx_desc: key_idx=0
>>>> [ 375.240078] rt2500usb_write_tx_desc: key_idx=0
>>>> [ 381.163494] rt2x00crypto_key_to_cipher: ALG_CCMP
>>>> [ 381.163507] rt2x00crypto_tx_overhead=8
>>>> [ 381.163515] rt2500usb_write_tx_desc: key_idx=0
>>>> [ 381.244066] rt2500usb_write_tx_desc: key_idx=0
>>>> [ 388.165180] rt2x00crypto_key_to_cipher: ALG_CCMP
>>>> [ 388.165194] rt2x00crypto_tx_overhead=8
>>>> [ 388.165201] rt2500usb_write_tx_desc: key_idx=0
>>>> [ 388.244069] rt2500usb_write_tx_desc: key_idx=0
>>>> [ 399.169468] rt2x00crypto_key_to_cipher: ALG_CCMP
>>>> [ 399.169481] rt2x00crypto_tx_overhead=8
>>>> [ 399.169489] rt2500usb_write_tx_desc: key_idx=0
>>>> [ 399.248067] rt2500usb_write_tx_desc: key_idx=0
>>>> [ 404.080428] rt2500usb_write_tx_desc: key_idx=0
>>>> [ 404.180066] rt2500usb_write_tx_desc: key_idx=0
>>>> [ 410.168836] rt2x00crypto_key_to_cipher: ALG_CCMP
>>>> [ 410.168850] rt2x00crypto_tx_overhead=8
>>>> [ 410.168858] rt2500usb_write_tx_desc: key_idx=0
>>>> [ 410.248068] rt2500usb_write_tx_desc: key_idx=0
>>>> [ 414.374545] rt2500usb_write_tx_desc: key_idx=0
>>>> [ 414.472061] rt2500usb_write_tx_desc: key_idx=0
>>>> [ 422.169686] rt2x00crypto_key_to_cipher: ALG_CCMP
>>>> [ 422.169699] rt2x00crypto_tx_overhead=8
>>>> [ 422.169706] rt2500usb_write_tx_desc: key_idx=0
>>>> [ 422.252069] rt2500usb_write_tx_desc: key_idx=0
>>>>
>>>> Seems that it's trying to use CCMP, which is good. I wonder if the keys
>>>> are properly handled in rt2500usb_config_key. They seem to be uploaded
>>>> to the HW correctly (one at index 0, one at 1) - but can't tell without
>>>> any HW docs.
>>>>
>>>> I did some framedumps before but don't know what to do with them (what
>>>> to look for):
>>>> http://www.rainbow-software.org/linux_files/rt2500usb/dump-wpa2-bad.txt
>>>> http://www.rainbow-software.org/linux_files/rt2500usb/dump-wpa2-good.tx
>>>> t
>>>>
>>>> Anything else I can try?
>>>
>>> Hi Ondrej,
>>>
>>> Did you also test what happens if you configure the AP to be TKIP+AES and
>>> force wpa-supplicant to use AES pairwise key?
>>> If my analysis below is correct then that may work as well.
>>
>> That does not work - it's probably the same case as default options (TKIP
>> group key + AES pairwise key).
>>
>>> If my reading of the rt2570 data sheet is correct, then the rt2570 will
>>> only support one encryption mechanism at the time. That means that it is
>>> not possible to upload 1 TKIP key and 1 AES key at the same time to the
>>> hardware. All the configured keys have to be of the same encryption
>>> algorithm.
>>> Presumably this is why the HW encryption engine fails, as the keys are
>>> set with mixed settings.
>>> Based on that, I don't think that rt2500usb can support this TKIP+AES
>>> setting on wpa-supplicant.
>>
>> If this is true, then the driver should fall back to SW encryption in this
>> case.
>
> HW crypto in rt2500usb does not seem to support keys with different ciphers,
> which breaks TKIP+AES mode. Fall back to software encryption to fix it.
>
> This should fix long-standing problems with rt2500usb and WPA, such as:
> http://rt2x00.serialmonkey.com/phpBB/viewtopic.php?f=4&t=4834
> https://bugzilla.redhat.com/show_bug.cgi?id=484888
>
> Also tested that it does not break WEP, TKIP-only and AES-only modes.
>
> Signed-off-by: Ondrej Zary <linux@rainbow-software.org>
Yes, this seems to be the right thing to do.
Acked-by: Gertjan van Wingerde <gwingerde@gmail.com>
>
> diff -urp linux-2.6.35-rc3-orig/drivers/net/wireless/rt2x00/rt2500usb.c linux-2.6.35-rc3/drivers/net/wireless/rt2x00/rt2500usb.c
> --- linux-2.6.35-rc3-orig/drivers/net/wireless/rt2x00/rt2500usb.c 2010-06-12 04:14:04.000000000 +0200
> +++ linux-2.6.35-rc3/drivers/net/wireless/rt2x00/rt2500usb.c 2010-06-23 12:18:43.000000000 +0200
> @@ -348,6 +348,7 @@ static int rt2500usb_config_key(struct r
> int timeout;
> u32 mask;
> u16 reg;
> + enum cipher curr_cipher;
>
> if (crypto->cmd == SET_KEY) {
> /*
> @@ -358,6 +359,7 @@ static int rt2500usb_config_key(struct r
> mask = TXRX_CSR0_KEY_ID.bit_mask;
>
> rt2500usb_register_read(rt2x00dev, TXRX_CSR0, ®);
> + curr_cipher = rt2x00_get_field16(reg, TXRX_CSR0_ALGORITHM);
> reg &= mask;
>
> if (reg && reg == mask)
> @@ -366,6 +368,14 @@ static int rt2500usb_config_key(struct r
> reg = rt2x00_get_field16(reg, TXRX_CSR0_KEY_ID);
>
> key->hw_key_idx += reg ? ffz(reg) : 0;
> + /*
> + * Hardware requires that all keys use the same cipher
> + * (e.g. TKIP-only, AES-only, but not TKIP+AES).
> + * If this is not the first key, compare the cipher with the
> + * first one and fall back to SW crypto if not the same.
> + */
> + if (key->hw_key_idx > 0 && crypto->cipher != curr_cipher)
> + return -EOPNOTSUPP;
>
> /*
> * The encryption key doesn't fit within the CSR cache,
>
>
^ permalink raw reply
* [PATCH 1/3] ath9k: Fix bug in paprd
From: Vasanthakumar Thiagarajan @ 2010-06-24 9:42 UTC (permalink / raw)
To: linville; +Cc: linux-wireless
It is possbile that the transmission of paprd test frame
might not get completed in 100ms if tx is stuck. Freeing
this skb upon timeout in ath_paprd_calibrate() will result
in accessing already freed memory when the associated pending
buffer is drained in txq. This patch fixes this issue.
Signed-off-by: Vasanthakumar Thiagarajan <vasanth@atheros.com>
---
drivers/net/wireless/ath/ath9k/ath9k.h | 3 +++
drivers/net/wireless/ath/ath9k/main.c | 5 +++--
drivers/net/wireless/ath/ath9k/xmit.c | 12 ++++++++++--
3 files changed, 16 insertions(+), 4 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/ath9k.h b/drivers/net/wireless/ath/ath9k/ath9k.h
index 6218890..6c561fa 100644
--- a/drivers/net/wireless/ath/ath9k/ath9k.h
+++ b/drivers/net/wireless/ath/ath9k/ath9k.h
@@ -226,6 +226,7 @@ struct ath_buf_state {
int bfs_retries;
u8 bf_type;
u8 bfs_paprd;
+ unsigned long bfs_paprd_timestamp;
u32 bfs_keyix;
enum ath9k_key_type bfs_keytype;
};
@@ -425,6 +426,8 @@ int ath_beaconq_config(struct ath_softc *sc);
#define ATH_LONG_CALINTERVAL 30000 /* 30 seconds */
#define ATH_RESTART_CALINTERVAL 1200000 /* 20 minutes */
+#define ATH_PAPRD_TIMEOUT 100 /* msecs */
+
void ath_paprd_calibrate(struct work_struct *work);
void ath_ani_calibrate(unsigned long data);
diff --git a/drivers/net/wireless/ath/ath9k/main.c b/drivers/net/wireless/ath/ath9k/main.c
index 41a317d..6d57877 100644
--- a/drivers/net/wireless/ath/ath9k/main.c
+++ b/drivers/net/wireless/ath/ath9k/main.c
@@ -310,13 +310,13 @@ void ath_paprd_calibrate(struct work_struct *work)
break;
time_left = wait_for_completion_timeout(&sc->paprd_complete,
- 100);
+ msecs_to_jiffies(ATH_PAPRD_TIMEOUT));
if (!time_left) {
ath_print(ath9k_hw_common(ah), ATH_DBG_CALIBRATE,
"Timeout waiting for paprd training on "
"TX chain %d\n",
chain);
- break;
+ goto fail_paprd;
}
if (!ar9003_paprd_is_done(ah))
@@ -334,6 +334,7 @@ void ath_paprd_calibrate(struct work_struct *work)
ath_paprd_activate(sc);
}
+fail_paprd:
ath9k_ps_restore(sc);
}
diff --git a/drivers/net/wireless/ath/ath9k/xmit.c b/drivers/net/wireless/ath/ath9k/xmit.c
index 20221b8..edbeffb 100644
--- a/drivers/net/wireless/ath/ath9k/xmit.c
+++ b/drivers/net/wireless/ath/ath9k/xmit.c
@@ -1644,6 +1644,8 @@ static int ath_tx_setup_buffer(struct ieee80211_hw *hw, struct ath_buf *bf,
}
bf->bf_state.bfs_paprd = txctl->paprd;
+ if (txctl->paprd)
+ bf->bf_state.bfs_paprd_timestamp = jiffies;
bf->bf_flags = setup_tx_flags(skb, use_ldpc);
bf->bf_keytype = get_hw_crypto_keytype(skb);
@@ -1944,8 +1946,14 @@ static void ath_tx_complete_buf(struct ath_softc *sc, struct ath_buf *bf,
dma_unmap_single(sc->dev, bf->bf_dmacontext, skb->len, DMA_TO_DEVICE);
if (bf->bf_state.bfs_paprd) {
- sc->paprd_txok = txok;
- complete(&sc->paprd_complete);
+ if (time_after(jiffies,
+ bf->bf_state.bfs_paprd_timestamp +
+ msecs_to_jiffies(ATH_PAPRD_TIMEOUT))) {
+ dev_kfree_skb_any(skb);
+ } else {
+ sc->paprd_txok = txok;
+ complete(&sc->paprd_complete);
+ }
} else {
ath_tx_complete(sc, skb, bf->aphy, tx_flags);
ath_debug_stat_tx(sc, txq, bf, ts);
--
1.7.0.4
^ permalink raw reply related
* [PATCH 2/3] ath9k: Restore ps state in ath_paprd_calibrate() upon failure to allocate skb
From: Vasanthakumar Thiagarajan @ 2010-06-24 9:42 UTC (permalink / raw)
To: linville; +Cc: linux-wireless
In-Reply-To: <1277372566-22883-1-git-send-email-vasanth@atheros.com>
Signed-off-by: Vasanthakumar Thiagarajan <vasanth@atheros.com>
---
drivers/net/wireless/ath/ath9k/main.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/main.c b/drivers/net/wireless/ath/ath9k/main.c
index 6d57877..484d113 100644
--- a/drivers/net/wireless/ath/ath9k/main.c
+++ b/drivers/net/wireless/ath/ath9k/main.c
@@ -271,7 +271,7 @@ void ath_paprd_calibrate(struct work_struct *work)
ath9k_ps_wakeup(sc);
skb = alloc_skb(len, GFP_KERNEL);
if (!skb)
- return;
+ goto fail_paprd;
tx_info = IEEE80211_SKB_CB(skb);
--
1.7.0.4
^ permalink raw reply related
* [PATCH 3/3] ath9k: Remove unused paprd_txok
From: Vasanthakumar Thiagarajan @ 2010-06-24 9:42 UTC (permalink / raw)
To: linville; +Cc: linux-wireless
In-Reply-To: <1277372566-22883-1-git-send-email-vasanth@atheros.com>
Signed-off-by: Vasanthakumar Thiagarajan <vasanth@atheros.com>
---
drivers/net/wireless/ath/ath9k/ath9k.h | 1 -
drivers/net/wireless/ath/ath9k/xmit.c | 6 ++----
2 files changed, 2 insertions(+), 5 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/ath9k.h b/drivers/net/wireless/ath/ath9k/ath9k.h
index 6c561fa..72d5e52 100644
--- a/drivers/net/wireless/ath/ath9k/ath9k.h
+++ b/drivers/net/wireless/ath/ath9k/ath9k.h
@@ -563,7 +563,6 @@ struct ath_softc {
struct mutex mutex;
struct work_struct paprd_work;
struct completion paprd_complete;
- int paprd_txok;
u32 intrstatus;
u32 sc_flags; /* SC_OP_* */
diff --git a/drivers/net/wireless/ath/ath9k/xmit.c b/drivers/net/wireless/ath/ath9k/xmit.c
index edbeffb..c41185b 100644
--- a/drivers/net/wireless/ath/ath9k/xmit.c
+++ b/drivers/net/wireless/ath/ath9k/xmit.c
@@ -1948,12 +1948,10 @@ static void ath_tx_complete_buf(struct ath_softc *sc, struct ath_buf *bf,
if (bf->bf_state.bfs_paprd) {
if (time_after(jiffies,
bf->bf_state.bfs_paprd_timestamp +
- msecs_to_jiffies(ATH_PAPRD_TIMEOUT))) {
+ msecs_to_jiffies(ATH_PAPRD_TIMEOUT)))
dev_kfree_skb_any(skb);
- } else {
- sc->paprd_txok = txok;
+ else
complete(&sc->paprd_complete);
- }
} else {
ath_tx_complete(sc, skb, bf->aphy, tx_flags);
ath_debug_stat_tx(sc, txq, bf, ts);
--
1.7.0.4
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox