Hello,
This patch will synchronize the transmission routines of rt2x00lib to avoid
processing interferences in systems with multiple execution threads.
Has been tested on an AMD 64 X2 6000 running Debian unstable
and a custom x86_64 kernel at version 2.6.37
The Wireless adapter is a D-Link USB,
ID 07d1:3c03 D-Link System AirPlus G DWL-G122 Wireless Adapter(rev.C1)
[Ralink RT73]
Now It works a lot better.
*** BEGIN PATCH
rt2x00: synchonize transmission_done routines
Signed-off-by: Jordi Pujol <jordipujolp AT gmail DOT com>
--- linux-2.6.37-old/drivers/net/wireless/rt2x00/rt2x00dev.c 2011-01-05
01:50:19.000000000 +0100
+++ linux-2.6.37/drivers/net/wireless/rt2x00/rt2x00dev.c 2011-02-12
14:59:58.043409531 +0100
@@ -258,6 +258,11 @@ void rt2x00lib_dmadone(struct queue_entr
}
EXPORT_SYMBOL_GPL(rt2x00lib_dmadone);
+/*
+ * rt2x00lib_txdone_mutex: synchonize rt2x00lib_txdone
+ */
+static DEFINE_MUTEX(rt2x00lib_txdone_mutex);
+
void rt2x00lib_txdone(struct queue_entry *entry,
struct txdone_entry_desc *txdesc)
{
@@ -271,6 +276,8 @@ void rt2x00lib_txdone(struct queue_entry
unsigned int i;
bool success;
+ mutex_lock(&rt2x00lib_txdone_mutex);
+
/*
* Unmap the skb.
*/
@@ -415,6 +422,8 @@ void rt2x00lib_txdone(struct queue_entry
*/
if (!rt2x00queue_threshold(entry->queue))
ieee80211_wake_queue(rt2x00dev->hw, qid);
+
+ mutex_unlock(&rt2x00lib_txdone_mutex);
}
EXPORT_SYMBOL_GPL(rt2x00lib_txdone);
@@ -486,6 +486,11 @@ static int rt2x00lib_rxdone_read_signal(
return 0;
}
+/*
+ * rt2x00lib_rxdone_mutex: synchonize rt2x00lib_rxdone
+ */
+static DEFINE_MUTEX(rt2x00lib_rxdone_mutex);
+
void rt2x00lib_rxdone(struct queue_entry *entry)
{
struct rt2x00_dev *rt2x00dev = entry->queue->rt2x00dev;
@@ -495,6 +500,8 @@ void rt2x00lib_rxdone(struct queue_entry
unsigned int header_length;
int rate_idx;
+ mutex_lock(&rt2x00lib_rxdone_mutex);
+
if (test_bit(ENTRY_DATA_IO_FAILED, &entry->flags))
goto submit_entry;
@@ -582,6 +589,8 @@ submit_entry:
rt2x00dev->ops->lib->clear_entry(entry);
rt2x00queue_index_inc(entry->queue, Q_INDEX);
rt2x00queue_index_inc(entry->queue, Q_INDEX_DONE);
+
+ mutex_unlock(&rt2x00lib_rxdone_mutex);
}
EXPORT_SYMBOL_GPL(rt2x00lib_rxdone);
*** END PATCH
Kind regards,
Jordi Pujol
Live never ending Tale
GNU/Linux Live forever!
http://livenet.selfip.com
Hi,
>> Both rxdone as txdone are for USB devices on a singlethreaded
>> workqueue. So it the work items will be scheduled only once...
>
> maybe that could depend on the scheduler type or anythig else,
> please look the attached kernel config.
> (excuse me, I'm not an expert)
>
> also the complete Debian kernel source is available in my website.
>
>> And I am not aware of any race conditions on the txdone/rxdone
>> paths (my testing environment is a dual-CPU system as well, so
>> I am always testing with SMP enabled...)
>>
>
> Maybe the kernel config or the adapter type impllies a different behaviour, I
> can say that without this patch the connections are slow and sometimes does
> not pass any bit, the adapter was continuosly retrying the transmission.
> This patch solves that; sure that is not the better solution, but works,
Could you try the compat-wireless package? There are a lot
of queue-related patches in there which were submitted after 2.6.37.
Ivo
A new version of this patch to synchronize transmission and receipt for each
device,
Jordi Pujol
Live never ending Tale
GNU/Linux Live forever!
http://livenet.selfip.com
> A new version of this patch to synchronize transmission and receipt for each
> device,
Well that address my first major objection against this patch.
But could you please explain what is working better with this patch?
Both rxdone as txdone are for USB devices on a singlethreaded
workqueue. So it the work items will be scheduled only once...
And I am not aware of any race conditions on the txdone/rxdone
paths (my testing environment is a dual-CPU system as well, so
I am always testing with SMP enabled...)
Ivo
A Dilluns 14 Febrer 2011 10:54:17, Ivo Van Doorn va escriure:
> >> Both rxdone as txdone are for USB devices on a singlethreaded
> >> workqueue. So it the work items will be scheduled only once...
guess (maybe) the problem is in the usb workqueues, I have found also an
erratic behaviour in the usb mouse.
> Could you try the compat-wireless package? There are a lot
> of queue-related patches in there which were submitted after 2.6.37.
this afternoon will try that,
Jordi Pujol
Live never ending Tale
GNU/Linux Live forever!
http://livenet.selfip.com
A Dilluns 14 Febrer 2011 11:57:51, Jordi Pujol va escriure:
> > Could you try the compat-wireless package? There are a lot
> > of queue-related patches in there which were submitted after 2.6.37.
>
> this afternoon will try that,
Yes, compat-wireless (yesterday version level) works well and has good
performance also,
Observing that there is a lot of new code about queue management,
Jordi Pujol
Live never ending Tale
GNU/Linux Live forever!
http://livenet.selfip.com
Hi,
>> >> Both rxdone as txdone are for USB devices on a singlethreaded
>> >> workqueue. So it the work items will be scheduled only once...
>
> guess (maybe) the problem is in the usb workqueues, I have found also an
> erratic behaviour in the usb mouse.
Even then, as soon as the USB fires the completion callback function,
rt2x00 will schedule the txdone and rxdone handlers to the mac80211
workqueue. So even when the USB layer has problems with the scheduling,
the txdone and rxdone paths are not affected.
>> Could you try the compat-wireless package? There are a lot
>> of queue-related patches in there which were submitted after 2.6.37.
>
> this afternoon will try that,
Ok
Ivo
A Dilluns 14 Febrer 2011 09:51:18, v?reu escriure:
> Well that address my first major objection against this patch.
> But could you please explain what is working better with this patch?
Hello Ivo,
In my personal experience using this adapter, that is already six or seven
years old, it has never worked fast; I have used standard Debian kernels, also
the sidux ones, and my own custom kernels.
There are some days, kernel 2.6.37 has crashed and dumped a message that I
have copied by hand, like this:
wq_worker_sleeping
schedule
? d_lookup
? call_rcu_sched
? release_task
? switch_task_namespaces
do_exit
? kmsg_dump
oops_end
no_context+0xf3/0x260
__bad_area_semaphore+0125/0x1e0
bad_area_semaphore+0xe/0x10
do_page_fault+0x291/0x400
? nf_contrack_free+0x54/0x60 [nf_contrack]
? kfree_skb+0x42/0xa0
? consume_skb+0x19/0x40
page_fault+0x25/0x30
? rt2x00lib_txdone [rt2x00lib]
rt2x00lib_txdone_noinfo [rt2x00lib]
rt2x00usb_work_txdone [rt2x00usb]
rt2x00usb_watchdog [rt2x00usb]
? wkq_func [aufs]
? rt2x00link_watchdog [rt2x00lib]
rt2x00link_watchdog [rt2x00lib]
process_one_work
worker_thread
? _wake_up_common
? worker_thread
kthread
That makes me deduct that it was a problem with the driver, what is already
suspected before,
> Both rxdone as txdone are for USB devices on a singlethreaded
> workqueue. So it the work items will be scheduled only once...
maybe that could depend on the scheduler type or anythig else,
please look the attached kernel config.
(excuse me, I'm not an expert)
also the complete Debian kernel source is available in my website.
> And I am not aware of any race conditions on the txdone/rxdone
> paths (my testing environment is a dual-CPU system as well, so
> I am always testing with SMP enabled...)
>
Maybe the kernel config or the adapter type impllies a different behaviour, I
can say that without this patch the connections are slow and sometimes does
not pass any bit, the adapter was continuosly retrying the transmission.
This patch solves that; sure that is not the better solution, but works,
Jordi Pujol
Live never ending Tale
GNU/Linux Live forever!
http://livenet.selfip.com