[rt2x00-users] [PATCH 0/3] rt2800usb: TX_STA_FIFO read timer

Ivo Van Doorn ivdoorn at gmail.com
Wed Jan 19 04:30:36 EST 2011


Hi,

> On Tue, Jan 18, 2011 at 04:45:06PM +0100, Johannes Stezenbach wrote:
>> On Mon, Jan 17, 2011 at 09:15:47PM +0100, Ivo Van Doorn wrote:
>> >
>> > > I guess I can get the wpa_supplicant from code.ros.org svn.
>> > > Can you point me to the script so I can try to
>> > > reproduce the issue?
>> >
>> > 1)
>> > You have to check the install instructions here (for Ubuntu):
>> > http://www.ros.org/wiki/cturtle/Installation/Ubuntu
>> [snip]
>>
>> My main testing platform is an embedded device.  On my development
>> machine I'm using Debian unstable so I guess I could try to
>> install the Ubuntu packages, but it'll take a bit of time to do that.
>>
>> Regarding the other mail I just wrt power save: Did you have
>> power save enabled in your tests?  If yes, min to try without?
>>
>> And if you had time to look at the patches, do you have any comments,
>> especially the "rt2x00: fix queue timeout checks" patch?
>
> FWIW, when I do a simple "wpa_cli -i wlan0 reassociate" in
> my environment I get:
>
> [14105.985394] phy0 -> rt2x00usb_watchdog_tx_status: Warning - TX queue 0 status timed out, invoke forced tx handler
> [14106.985076] phy0 -> rt2x00usb_watchdog_tx_status: Warning - TX queue 0 status timed out, invoke forced tx handler
> [14107.416490] phy0 -> rt2x00queue_flush_queue: Warning - Queue 0 failed to flush
> [14108.985317] phy0 -> rt2x00usb_watchdog_tx_status: Warning - TX queue 0 status timed out, invoke forced tx handler
> [14109.985939] phy0 -> rt2x00usb_watchdog_tx_status: Warning - TX queue 0 status timed out, invoke forced tx handler
> [14110.176761] phy0 -> rt2x00queue_flush_queue: Warning - Queue 0 failed to flush
> [14111.986146] phy0 -> rt2x00usb_watchdog_tx_status: Warning - TX queue 0 status timed out, invoke forced tx handler
> [14112.937112] phy0 -> rt2x00queue_flush_queue: Warning - Queue 0 failed to flush
> [14112.985798] phy0 -> rt2x00usb_watchdog_tx_status: Warning - TX queue 0 status timed out, invoke forced tx handler
> [14113.518188] phy0 -> rt2x00mac_conf_tx: Info - Configured TX queue 0 - CWmin: 2, CWmax: 3, Aifs: 2, TXop: 47.
> [14113.533086] phy0 -> rt2x00mac_conf_tx: Info - Configured TX queue 1 - CWmin: 3, CWmax: 4, Aifs: 2, TXop: 94.
> [14113.547322] phy0 -> rt2x00mac_conf_tx: Info - Configured TX queue 2 - CWmin: 4, CWmax: 10, Aifs: 3, TXop: 0.
> [14113.562326] phy0 -> rt2x00mac_conf_tx: Info - Configured TX queue 3 - CWmin: 4, CWmax: 10, Aifs: 7, TXop: 0.
> [14113.636714] wlan0: deauthenticating from 00:23:cd:18:fa:60 by local choice (reason=2)
> [14113.659783] cfg80211: Calling CRDA to update world regulatory domain
> [14113.694765] wlan0: authenticate with 00:23:cd:18:fa:60 (try 1)
> [14113.712633] wlan0: authenticated
> [14113.744397] wlan0: associate with 00:23:cd:18:fa:60 (try 1)
> [14113.762096] wlan0: RX ReassocResp from 00:23:cd:18:fa:60 (capab=0x411 status=0 aid=1)
> [14113.770126] wlan0: associated
> [14113.773816] phy0 -> rt2x00mac_conf_tx: Info - Configured TX queue 2 - CWmin: 4, CWmax: 10, Aifs: 3, TXop: 0.
> [14113.788992] phy0 -> rt2x00mac_conf_tx: Info - Configured TX queue 3 - CWmin: 4, CWmax: 10, Aifs: 7, TXop: 0.
> [14113.803034] phy0 -> rt2x00mac_conf_tx: Info - Configured TX queue 1 - CWmin: 3, CWmax: 4, Aifs: 2, TXop: 94.
> [14113.817234] phy0 -> rt2x00mac_conf_tx: Info - Configured TX queue 0 - CWmin: 2, CWmax: 3, Aifs: 2, TXop: 47.
>
> I debugged this a bit because it looked like my patches did not work because
> of the status timeouts, but it looks like the workqueue is simply blocked
> by rt2x00queue_flush_queue().

Yeah I know, that was the rt2x00mac_flush() problem I mentioned before.
Because rt2x00mac_flush() & Watchdog have a problem with dependencies
(it depends on the RX/TX work
structures to run freely), the workqueue on which those structures are
placed must be in such
a way that they don't collide with eachother. This causes long delays,
and long times
before the client is associated.

When I comment out the flush() callbacks the association times are
reduced to normal,
but I haven't done a stresstest with that function disabled yet.

> If I comment out the sleep in rt2x00queue_flush_queue() the reassociate
> works much faster.  Maybe this is the root cause of your issue?
> BTW, the "failed to flush" warning happens _always_ on reassociate.

Ivo



More information about the users mailing list