On 01/29/2012 11:00 AM, Olivier Fabre wrote:
Hi Larry, A few Arch Linux users and I noticed that the r8712u driver didn't work anymore starting from kernel 3.2.1, while it worked in 3.0 and 3.1. Here is the Arch Linux bug report: https://bugs.archlinux.org/task/27996 I'll list whatever info I can think of about my own case below... lsusb: Bus 003 Device 003: ID 0bda:8172 Realtek Semiconductor Corp. RTL8191SU 802.11n WLAN Adapter Partial dmesg: [ 5.347026] r8712u: module is from the staging directory, the quality is unknown, you have been warned. [ 5.348082] r8712u: DriverVersion: v7_0.20100831 [ 5.348096] r8712u: register rtl8712_netdev_ops to netdev_ops [ 5.348098] r8712u: USB_SPEED_HIGH with 4 endpoints [ 5.348459] r8712u: Boot from EFUSE: Autoload OK [ 6.075474] r8712u: CustomerID = 0x0000 [ 6.075479] r8712u: MAC Address from efuse = 80:1f:02:0b:bb:11 [ 6.075770] usbcore: registered new interface driver r8712u [ 7.132386] r8712u: Loading firmware from "rtlwifi/rtl8712u.bin" [ 7.789082] r8712u: 1 RCR=0x153f00e [ 7.789829] r8712u: 2 RCR=0x553f00e [ 16.240983] r8712u: Loading firmware from "rtlwifi/rtl8712u.bin" [ 16.890571] r8712u: 1 RCR=0x153f00e [ 16.891427] r8712u: 2 RCR=0x553f00e [ 17.440436] r8712u: Loading firmware from "rtlwifi/rtl8712u.bin" [ 18.086805] r8712u: 1 RCR=0x153f00e [ 18.087554] r8712u: 2 RCR=0x553f00e [ 61.003359] r8712u: Loading firmware from "rtlwifi/rtl8712u.bin" In dmesg I see that network applications get stuck, including wpa_supplicant and xfce4-netload-plugin: [ 239.934619] INFO: task xfce4-netload-p:766 blocked for more than 120 seconds. [ 239.934623] "echo 0> /proc/sys/kernel/hung_task_timeout_secs" disables this message. [ 239.934627] xfce4-netload-p D 00000000fffee866 0 766 729 0x00000000 [ 239.934633] ffff88007fec7cd8 0000000000000086 ffffffff00000000 ffffea000437fd80 [ 239.934639] ffff8801081bf200 ffff88007fec7fd8 ffff88007fec7fd8 ffff88007fec7fd8 [ 239.934644] ffff880110ca4e60 ffff8801081bf200 ffff88007ff193b8 ffff880104cf4d00 [ 239.934649] Call Trace: [ 239.934660] [<ffffffff8110ec10>] ? __pagevec_free+0x60/0x100 [ 239.934667] [<ffffffff814258bf>] schedule+0x3f/0x60 [ 239.934671] [<ffffffff81426fa4>] __mutex_lock_slowpath+0x154/0x370 [ 239.934675] [<ffffffff814271d6>] mutex_lock+0x16/0x30 [ 239.934681] [<ffffffff81371d15>] rtnl_lock+0x15/0x20 [ 239.934685] [<ffffffff813c5db7>] devinet_ioctl+0xd7/0x730 [ 239.934689] [<ffffffff813c6f05>] inet_ioctl+0x75/0x90 [ 239.934694] [<ffffffff8134a260>] sock_do_ioctl+0x30/0x70 [ 239.934698] [<ffffffff8134a54d>] sock_ioctl+0x6d/0x2c0 [ 239.934706] [<ffffffff8116879b>] ? alloc_file+0x2b/0xd0 [ 239.934711] [<ffffffff811793af>] do_vfs_ioctl+0x8f/0x500 [ 239.934715] [<ffffffff8134bf64>] ? sock_alloc_file+0xa4/0x120 [ 239.934719] [<ffffffff811655b2>] ? fd_install+0x62/0x80 [ 239.934724] [<ffffffff811798b1>] sys_ioctl+0x91/0xa0 [ 239.934727] [<ffffffff8134d460>] ? sys_socket+0x40/0x70 [ 239.934733] [<ffffffff814290c2>] system_call_fastpath+0x16/0x1b I'm currently running kernel 3.0.17 (LTS) and the driver works, but if I boot under 3.2.2 it doesn't (all other software being equal.) I'm guessing bisecting might help find the source of the problem, but I've never done that. But I could try.
When contacting a maintainer about a problem, always Cc the appropriate mailing list, and keep that ML in any replies.
I think the problem is that Arch Linux has switched to a new version of udev, which is causing all sorts of problems for drivers that use synchronous loading of firmware. Several drivers, including r8712u, need to be converted to an asynchronous load mechanism. Until that happens, you should be able to work around it by using a "modprobe -r/modprobe" sequence. Once the user-space code is fully up and running, the synchronous loading will be OK.
Larry -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
