linux-kernel - Re: [rt2x00-users] Poor performance and lockup with rt2800usb and Asus USB-N13 adapter

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 30 Nov 2011 20:21:49 -0600
From:	Robert Hancock <hancockrwd@...il.com>
To:	Stanislaw Gruszka <sgruszka@...hat.com>
Cc:	linux-kernel <linux-kernel@...r.kernel.org>,
	linux-wireless <linux-wireless@...r.kernel.org>,
	users@...x00.serialmonkey.com
Subject: Re: [rt2x00-users] Poor performance and lockup with rt2800usb and
 Asus USB-N13 adapter

On Tue, Nov 29, 2011 at 5:46 AM, Stanislaw Gruszka <sgruszka@...hat.com> wrote:
> On Mon, Nov 28, 2011 at 07:50:20PM -0600, Robert Hancock wrote:
>> I recently got an Asus USB-N13 USB Wireless-N adapter which
>> apparently uses a Ralink RT3072 chip. I'm using it with an Asus
>> RT-N16 access point running TomatoUSB. When running Windows the
>> performance is reasonable (about 80 Mbps in both directions).
>> However under Fedora 16 (currently kernel 3.1.2) the performance is
>> abysmal (10 Mbps or less with lots of packet loss). I'll post some
>> debug information below.
> rt2800usb needs fixing. I'm able to reproduce these performance
> problems locally. They are quite hard to debug, and need some
> experiments. But I hope I will provide patches soon or leter.

Do you have any leads on what is going wrong? I'm not sure if the
issue is with the higher MCS rates not working as well as they should,
or with the rate control trying to use them even though they're not
working well.

>
>> While debugging this I also noticed that doing an rmmod on rt2800usb
>> with the adapter plugged in locks up the machine and then spews out
>> soft lockup stack traces on the console. I was only able to capture
>> it off the screen with a camera, but it basically is:
>>
>> rt2x00usb_work_rxdone
>> process_one_work
>> worker_thread
>> kthread
>> kernel_thread_helper
> Another thing to investigate. Can yo try to reproduce that with
> CONFIG_DEBUG_OBJECTS=y
> CONFIG_DEBUG_OBJECTS_FREE=y
> CONFIG_DEBUG_OBJECTS_TIMERS=y
> CONFIG_DEBUG_OBJECTS_WORK=y
> CONFIG_DEBUG_OBJECTS_RCU_HEAD=y
> CONFIG_DEBUG_SPINLOCK=y
> CONFIG_DEBUG_MUTEXES=y
> CONFIG_DEBUG_LOCK_ALLOC=y
> CONFIG_PROVE_LOCKING=y
> CONFIG_LOCKDEP=y
> and see if these options print some aditional message when rmmod.

I tried with the Fedora kernel-debug kernel and didn't see much
additional output. The stack trace might have a bit more detail:

rt2x00queue_index_inc
rt2x00lib_dmadone
rt2x00usb_kick_rx_entry
rt2x00usb_clear_entry
rt2x00lib_rxdone
rt2x00usb_work_rxdone
process_one_work
worker_thread
kthread
kernel_thread_helper

Seems like something that happens on rmmod with the device connected
causes these rxdone/txdone functions to go into a tight loop somehow.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/