On 08/29/2015 04:18 PM, jes.soren...@redhat.com wrote:
From: Jes Sorensen <jes.soren...@redhat.com>
Hi,
I finally found some time to work on rtl8xxxu again. Since the
previously version posted some months ago, I fixed up a number of
bugs. I also added support for a range of other Realtek based USB
devices. The driver now supports rtl8723au, rtl8188cu, rtl8188ru, and
rtl8192cu. It should work on rtl8191cu devices as well.
Per default only devices I have actually tested will be enabled. If
you are interested in trying it out with other 8188cu/8188ru/819[12]cu
dongles, you need to enable CONFIG_RTL8XXXU_UNTESTED. Please report
test results back to me.
Note if you enable this driver, it may clash with CONFIG_RTL8192U,
CONFIG_R8723AU, and CONFIG_RTL8192CU (rtlwifi). Please pay attention
to which module you load and/or use modprobe blacklists.
This driver is still work in progress. I have used it as my primary
driver for the last six months, and I find it to be very stable. It
seems suitable for mainline inclusion at this point.
Jes,
The Edimax 7811 works on the new driver. The performance is a lot better than I
said in my previous post. Measuring with netperf for 3 second intervals, I get a
maximum RX rate of 33.0 Mbps and a long-term average (750 samples) of 20.8 Mbps.
For TX, the max is 34.5 Mbps and the average is 27.4.
I am still getting one "scheduling while atomic" BUG splat as follows:
BUG: sleeping function called from invalid context at kernel/locking/mutex.c:616
in_atomic(): 0, irqs_disabled(): 0, pid: 19961, name: kworker/u16:0
INFO: lockdep is turned off.
CPU: 0 PID: 19961 Comm: kworker/u16:0 Tainted: G W O 4.2.0-rc7-wl+
#39
Hardware name: TOSHIBA TECRA A50-A/TECRA A50-A, BIOS Version 4.20 04/17/2014
Workqueue: phy9 ieee80211_iface_work [mac80211]
ffffffff81a3d470 ffff880102227508 ffffffff8174b6e1 0000000000000000
ffff880224e54b00 ffff880102227538 ffffffff81090117 ffff880102227578
ffffffff81a3d470 0000000000000268 0000000000000000 ffff880102227568
Call Trace:
[<ffffffff8174b6e1>] dump_stack+0x4c/0x6e
[<ffffffff81090117>] ___might_sleep+0x147/0x1f0
[<ffffffff8109020d>] __might_sleep+0x4d/0x90
[<ffffffff81750d88>] mutex_lock_nested+0x38/0x3c0
[<ffffffff814d9a56>] ? __dev_printk+0x46/0x90
[<ffffffffa07a553f>] rtl8723a_h2c_cmd+0x4f/0x180 [rtl8xxxu]
[<ffffffffa07aa977>] rtl8xxxu_bss_info_changed+0x367/0x6b1 [rtl8xxxu]
[<ffffffffa07aa89f>] ? rtl8xxxu_bss_info_changed+0x28f/0x6b1 [rtl8xxxu]
[<ffffffffa055fd84>] ieee80211_bss_info_change_notify+0x104/0x4e0 [mac80211]
[<ffffffffa05f5626>] ieee80211_assoc_success+0x90c/0xa98 [mac80211]
[<ffffffff8116b8ad>] ? irq_work_queue+0x7d/0xa0
[<ffffffff810d26d9>] ? wake_up_klogd+0x39/0x50
[<ffffffff810d28d7>] ? console_unlock+0x1e7/0x510
[<ffffffff810d2def>] ? vprintk_emit+0x1ef/0x540
[<ffffffff810d3299>] ? vprintk_default+0x29/0x40
[<ffffffffa05d311b>] ieee80211_rx_mgmt_assoc_resp+0x15b/0x310 [mac80211]
[<ffffffffa05d48da>] ieee80211_sta_rx_queued_mgmt+0x19a/0x6d0 [mac80211]
[<ffffffff810b8915>] ? cpuacct_charge+0x5/0x1a0
[<ffffffff815e8a91>] ? skb_dequeue+0x21/0x70
[<ffffffff810bca4d>] ? trace_hardirqs_on+0xd/0x10
[<ffffffffa05803b9>] ieee80211_iface_work+0x2d9/0x3e0 [mac80211]
[<ffffffff81082e7e>] ? process_one_work+0x14e/0x7d0
[<ffffffff81082f0f>] process_one_work+0x1df/0x7d0
[<ffffffff81082e7e>] ? process_one_work+0x14e/0x7d0
[<ffffffff8108361a>] worker_thread+0x11a/0x460
[<ffffffff817546bb>] ? _raw_spin_unlock_irqrestore+0x4b/0x60
[<ffffffff81083500>] ? process_one_work+0x7d0/0x7d0
[<ffffffff81089e9f>] kthread+0xef/0x110
[<ffffffff81089db0>] ? kthread_create_on_node+0x220/0x220
[<ffffffff8175530f>] ret_from_fork+0x3f/0x70
[<ffffffff81089db0>] ? kthread_create_on_node+0x220/0x220
wlp0s20u6: associated
This splat happened during the authentication/association phase. At present, the
connection has been up for almost 12 hours without a single drop.
Larry
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
