Send users mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
http://rt2x00.serialmonkey.com/mailman/listinfo/users_rt2x00.serialmonkey.com
or, via email, send a message with subject or body 'help' to
[email protected]
You can reach the person managing the list at
[email protected]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of users digest..."
Today's Topics:
1. Try to narrow down the problem with rt2800usb and rt3572
based USB WLAN devices (Andreas Hartmann)
2. [PATCH] rt2x00: Add USB device ID of Buffalo WLI-UC-GNHP.
(Gertjan van Wingerde)
3. [PATCH] rt2x00: Fix sleep-while-atomic bug in powersaving
code. (Gertjan van Wingerde)
----------------------------------------------------------------------
Message: 1
Date: Sat, 12 Nov 2011 18:00:06 +0100
From: Andreas Hartmann <[email protected]>
To: [email protected]
Cc: "[email protected]" <[email protected]>
Subject: [rt2x00-users] Try to narrow down the problem with rt2800usb
and rt3572 based USB WLAN devices
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-15
Hello,
as I already wrote some time ago, the rt2800usb module doesn't work very
well with WUSB600Nv2, e.g. (rt3572 chip). If it's on load, you get a lot
of warnings like these:
kernel: [357109.158376] phy0 ->rt2800usb_txdone_entry_check: Warning -
Data pending for entry 28 in queue 2
or:
kernel: [357109.158275] phy0 -> rt2800usb_txdone_entry_check: Warning -
TX status report missed for queue 2 entry 20
The throughput is very very bad (between 3 and 0 Mbits/s - 802.11n).
To get some more information about what's happening, I did an USB trace
and compared it with the rt3572sta driver from ralink.
First the outcome of the trace of the ralink driver (example - netperf
-t TCP_MAERTS -h server):
Packet- src->dst Data URB type URB ID
number
----------------------------------------------------------------------
7743 host -> 8.1 Request 24576 (0) Submit 41c0
7744 8.1 -> host 21840 bytes Complete 41c0 (response
to 7743)
7745 host -> 8.1 Request 24576 (0) Submit b140
7746 8.1 -> host 21840 bytes Complete b140 (response
to 7745)
7747 host -> 8.1 Request 24576 (0) Submit c5c0
7748 8.1 -> host 21840 bytes Complete c5c0 (response
to 7747)
7749 host -> 8.1 Request 24576 (0) Submit 92c0
7750 8.1 -> host 21840 bytes Complete 92c0 (response
to 7749)
7751 host -> 8.1 Request 24576 (0) Submit a440
7752 8.1 -> host 6240 bytes Complete a440 (response
to 7751)
7753 host -> 8.1 Request 24576 (0) Submit fe40
7754 8.1 -> host 21840 bytes Complete fe40 (response
zu 7753)
I could see a completely regular request/response behavior. Requested
are 24576 bytes, the response almost always is 21840 bytes. Throughput
is about 10 MBit/s.
The same trace with rt2800usb confuses me completely:
82998 host -> 8.1 Request 3860 (0) Submit 2cc0
...
83043 8.1 -> host 1560 bytes Complete 29c0
83044 host -> 8.1 Request 3860 (0) Submit 2bc0
83045 host -> 8.1 Request 3860 (0) Submit 2340
83046 host -> 8.1 Request 3860 (0) Submit 25c0
83047 8.1 -> host 1560 bytes Complete 2540
83048 host -> 8.1 Request 3860 (0) Submit 27c0
83049 host -> 8.1 Request 3860 (0) Submit 29c0
83050 host -> 8.1 Request 3860 (0) Submit 2540
....
83056 8.1 -> host 1560 bytes Complete 1e40 (response
to 83050)
83057 8.1 -> host 1560 bytes Complete c640 (response
to 83050)
83059 8.1 -> host 1560 bytes Complete f4c0 (response
to 83050)
83060 8.1 -> host 1560 bytes Complete 4940 (response
to 83050)
83061 8.1 -> host 1560 bytes Complete 3240 (response
to 83050)
83062 host -> 8.1 Request 3860 (0) Submit 1e40
83063 host -> 8.1 Request 3860 (0) Submit c640
83064 host -> 8.1 Request 3860 (0) Submit f4c0
83065 host -> 8.1 Request 3860 (0) Submit 4940
83066 host -> 8.1 Request 3860 (0) Submit 3240
83068 8.1 -> host 1560 bytes Complete 7440 (response
to 83066)
83070 host -> 8.1 Request 3860 (0) Submit 7440
83072 8.1 -> host 1560 bytes Complete 34c0 (response
to 83070)
83073 8.1 -> host 1560 bytes Complete 0840 (response
to 83070)
83074 host -> 8.1 Request 3860 (0) Submit 34c0
83075 host -> 8.1 Request 3860 (0) Submit 0840
83076 host -> 8.1 Request 3860 (0) Submit ddc0
83077 8.1 -> host 1560 bytes Complete c8c0 (response
to 83075)
83078 host -> 8.1 Request 3860 (0) Submit c8c0
83079 host -> 8.1 Request 3860 (0) Submit 4bc0
83111 8.1 -> host 1560 bytes Complete ca40 (response
to 83078)
83112 8.1 -> host 1560 bytes Complete c640 (response
to 83078)
83116 host -> 8.1 Request 3860 (0) Submit ca40
83116 host -> 8.1 Request 3860 (0) Submit c640
83122 8.1 -> host 1560 bytes Complete c9c0 (response
to 83117)
83123 host -> 8.1 Request 3860 (0) Submit c9c0
83125 8.1 -> host 1560 bytes Complete c5c0 (response
to 83123)
The device gets bombed with tons of small requests (3860 bytes instead
of 24576) and sometimes, there can be seen an answer (1560 bytes instead
of 21840). Most of the requests seem not to be answered at all.
Another comparison: using the ralink driver, I could count about 2365
packets / s. With the rt2800usb driver, I could see about 15187 packets / s.
Could anybody please try to explain this behavior, or even better, fix
it (it looks really broken to me)?
Thank you,
kind regards,
Andreas
------------------------------
Message: 2
Date: Sat, 12 Nov 2011 19:10:43 +0100
From: Gertjan van Wingerde <[email protected]>
To: <[email protected]>
Cc: [email protected], [email protected]
Subject: [rt2x00-users] [PATCH] rt2x00: Add USB device ID of Buffalo
WLI-UC-GNHP.
Message-ID: <[email protected]>
This is reported to be an RT3070 based device.
Reported-by: Teika Kazura <[email protected]>
Signed-off-by: Gertjan van Wingerde <[email protected]>
---
drivers/net/wireless/rt2x00/rt2800usb.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/net/wireless/rt2x00/rt2800usb.c
b/drivers/net/wireless/rt2x00/rt2800usb.c
index f156579..3778763 100644
--- a/drivers/net/wireless/rt2x00/rt2800usb.c
+++ b/drivers/net/wireless/rt2x00/rt2800usb.c
@@ -919,6 +919,7 @@ static struct usb_device_id rt2800usb_device_table[] = {
{ USB_DEVICE(0x050d, 0x935b) },
/* Buffalo */
{ USB_DEVICE(0x0411, 0x00e8) },
+ { USB_DEVICE(0x0411, 0x0158) },
{ USB_DEVICE(0x0411, 0x016f) },
{ USB_DEVICE(0x0411, 0x01a2) },
/* Corega */
--
1.7.7
------------------------------
Message: 3
Date: Sat, 12 Nov 2011 19:10:44 +0100
From: Gertjan van Wingerde <[email protected]>
To: <[email protected]>
Cc: [email protected], [email protected],
[email protected]
Subject: [rt2x00-users] [PATCH] rt2x00: Fix sleep-while-atomic bug in
powersaving code.
Message-ID: <[email protected]>
The generic powersaving code that determines after reception of a frame
whether the device should go back to sleep or whether is could stay
awake was calling rt2x00lib_config directly from RX tasklet context.
On a number of the devices this call can actually sleep, due to having
to confirm that the sleeping commands have been executed successfully.
Fix this by moving the call to rt2x00lib_config to a workqueue call.
This fixes bug https://bugzilla.redhat.com/show_bug.cgi?id=731672
Tested-by: Tomas Trnka <[email protected]>
Signed-off-by: Gertjan van Wingerde <[email protected]>
Cc: <[email protected]>
---
drivers/net/wireless/rt2x00/rt2x00.h | 1 +
drivers/net/wireless/rt2x00/rt2x00dev.c | 22 ++++++++++++++++++++--
2 files changed, 21 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/rt2x00/rt2x00.h
b/drivers/net/wireless/rt2x00/rt2x00.h
index 2ec5c00..99ff12d 100644
--- a/drivers/net/wireless/rt2x00/rt2x00.h
+++ b/drivers/net/wireless/rt2x00/rt2x00.h
@@ -943,6 +943,7 @@ struct rt2x00_dev {
* Powersaving work
*/
struct delayed_work autowakeup_work;
+ struct work_struct sleep_work;
/*
* Data queue arrays for RX, TX, Beacon and ATIM.
diff --git a/drivers/net/wireless/rt2x00/rt2x00dev.c
b/drivers/net/wireless/rt2x00/rt2x00dev.c
index e1fb2a8..edd317f 100644
--- a/drivers/net/wireless/rt2x00/rt2x00dev.c
+++ b/drivers/net/wireless/rt2x00/rt2x00dev.c
@@ -465,6 +465,23 @@ static u8 *rt2x00lib_find_ie(u8 *data, unsigned int len,
u8 ie)
return NULL;
}
+static void rt2x00lib_sleep(struct work_struct *work)
+{
+ struct rt2x00_dev *rt2x00dev =
+ container_of(work, struct rt2x00_dev, sleep_work);
+
+ if (!test_bit(DEVICE_STATE_PRESENT, &rt2x00dev->flags))
+ return;
+
+ /*
+ * Check again is powersaving is enabled, to prevent races from delayed
+ * work execution.
+ */
+ if (!test_bit(CONFIG_POWERSAVING, &rt2x00dev->flags))
+ rt2x00lib_config(rt2x00dev, &rt2x00dev->hw->conf,
+ IEEE80211_CONF_CHANGE_PS);
+}
+
static void rt2x00lib_rxdone_check_ps(struct rt2x00_dev *rt2x00dev,
struct sk_buff *skb,
struct rxdone_entry_desc *rxdesc)
@@ -512,8 +529,7 @@ static void rt2x00lib_rxdone_check_ps(struct rt2x00_dev
*rt2x00dev,
cam |= (tim_ie->bitmap_ctrl & 0x01);
if (!cam && !test_bit(CONFIG_POWERSAVING, &rt2x00dev->flags))
- rt2x00lib_config(rt2x00dev, &rt2x00dev->hw->conf,
- IEEE80211_CONF_CHANGE_PS);
+ queue_work(rt2x00dev->workqueue, &rt2x00dev->sleep_work);
}
static int rt2x00lib_rxdone_read_signal(struct rt2x00_dev *rt2x00dev,
@@ -1141,6 +1157,7 @@ int rt2x00lib_probe_dev(struct rt2x00_dev *rt2x00dev)
INIT_WORK(&rt2x00dev->intf_work, rt2x00lib_intf_scheduled);
INIT_DELAYED_WORK(&rt2x00dev->autowakeup_work, rt2x00lib_autowakeup);
+ INIT_WORK(&rt2x00dev->sleep_work, rt2x00lib_sleep);
/*
* Let the driver probe the device to detect the capabilities.
@@ -1197,6 +1214,7 @@ void rt2x00lib_remove_dev(struct rt2x00_dev *rt2x00dev)
*/
cancel_work_sync(&rt2x00dev->intf_work);
cancel_delayed_work_sync(&rt2x00dev->autowakeup_work);
+ cancel_work_sync(&rt2x00dev->sleep_work);
if (rt2x00_is_usb(rt2x00dev)) {
del_timer_sync(&rt2x00dev->txstatus_timer);
cancel_work_sync(&rt2x00dev->rxdone_work);
--
1.7.7
------------------------------
_______________________________________________
users mailing list
[email protected]
http://rt2x00.serialmonkey.com/mailman/listinfo/users_rt2x00.serialmonkey.com
End of users Digest, Vol 33, Issue 11
*************************************
