Larry Finger <larry.fin...@lwfinger.net> writes: > 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.
Larry, Just to be sure I got it right, you're saying the gain issue is not an issue with this version of the code after all? Is the 7811 a 1T1R or a 2T2R part? > 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. That one is interesting, I don't think I have seen this one ever, but I'll look out for it. It seems to happen during h2c command processing. I'll have a look. The uptime sounds pretty awesome, thanks again for testing! Jes -- 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
