Bug 51171
| Summary: | RTL8192CU drops IRQ at "ifconfig up" time in 3.7-rc7 | ||
|---|---|---|---|
| Product: | Networking | Reporter: | Dima Kogan (dima) |
| Component: | Wireless | Assignee: | networking_wireless (networking_wireless) |
| Status: | NEW --- | ||
| Severity: | normal | CC: | alan, Larry.Finger, linville, szg00000 |
| Priority: | P1 | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Kernel Version: | 3.7-rc7 | Subsystem: | |
| Regression: | No | Bisected commit-id: | |
|
Description
Dima Kogan
2012-12-01 08:42:12 UTC
I'm not sure about firmware loading causing this problem, unless there is something really wrong with the ARM port of udev. I have certainly not seen this kind of problem on x86_64 architecture. The dmesg output of my system related to rtl8192cu is as follows: [289303.196159] usb 1-1: new high-speed USB device number 4 using ehci_hcd [289304.368659] rtl8192cu: Chip version 0x10 [289304.696894] rtl8192cu: MAC address: 00:1f:1f:c8:8e:cb [289304.696916] rtl8192cu: Board Type 0 [289304.697480] rtlwifi: rx_max_size 15360, rx_urb_num 8, in_ep 1 [289304.697892] rtl8192cu: Loading firmware rtlwifi/rtl8192cufw.bin [289304.701662] usbcore: registered new interface driver rtl8192cu [289304.743930] ieee80211 phy1: Selected rate control algorithm 'rtl_rc' [289304.757358] rtlwifi: wireless switch is on [289306.048574] rtl8192cu: MAC auto ON okay! [289306.224557] rtl8192cu: Tx queue select: 0x05 [289306.759429] IPv6: ADDRCONF(NETDEV_UP): wlan1: link is not ready [289342.548093] wlan1: authenticate with c0:3f:0e:be:2b:44 [289342.567183] wlan1: send auth to c0:3f:0e:be:2b:44 (try 1/3) [289342.570136] wlan1: authenticated [289342.572940] wlan1: associate with c0:3f:0e:be:2b:44 (try 1/3) [289342.580777] wlan1: RX AssocResp from c0:3f:0e:be:2b:44 (capab=0x411 status=0 aid=4) [289342.582094] wlan1: associated [289342.584168] IPv6: ADDRCONF(NETDEV_CHANGE): wlan1: link becomes ready [289342.592160] wlan1: dropped frame to c0:3f:0e:be:2b:44 (unauthorized port) My system brings the interface up using NetworkManager, but that should not make any difference. I am running 3.7-rc7, but I never saw a DMA-mapping kernel bug from _usb_writeN_sync. In the current version, that routine has been removed. I am quite certain that the firmware loading is correct in the current version; however, any the usage of the older kernels with synchronous firmware loading will fail if used with a recent version of udev. If you want to run with an older kernel, I would recommend that you use a recent version of compat-wireless or compat-drivers in conjunction with that kernel. Hi Larry. Thanks for replying. The only reason I was suspecting the firmware being the culprit is that things stop working between 3.2 and 3.4, which is when the firmware changes occurred. It could certainly be something else. Furthermore, I don't think I was fully clear in the original report. I'm observing: | 3.2 | Everything works | | 3.4 | Oops described above | | 3.7 | Dropped IRQ | My goal is to get this running under 3.7, so the oops probably isn't that interesting. As I said, the network seems to work in 3.7 despite that message. However, I haven't tested it very thoroughly, so I can imagine that it could cause issues later. Does this dropped-IRQ message seem benign to you? What tests would be helpful to isolate the source of the issue? I can easily reproduce this problem, so I'm happy to run whatever experiments you think would be helpful. Thanks What device corresponds to IRQ #26? Is that shown in /proc/interrupts on ARM architecture? Is there a power problem on your USB system that shows up when the RTL8192CU is activated? Does the same problem occur when the wireless stick is plugged into a powered hub? Hi Larry. I looked a bit deeper, and there may be something wrong on the ARM side of things. IRQ 26 is the L3 interconnect application interrupt, handled in omap3_l3_app_irq() in omap_l3_smx.c. The ISR tries to determine which error has occurred, but the error code is "reserved", so the ISR doesn't handle the interrupt. Hence the problem. I'll ask on the ARM kernel mailing list about it. I still don't quite understand the firmware side of things, though. At driver-load time the kernel says rtl8192cu: Loading firmware rtlwifi/rtl8192cufw.bin Then at "ifconfig up" time I get the dropped IRQ, then the kernel says rtl8192c_common:_rtl92c_fw_free_to_go():<0-0> Polling FW ready fail!! REG_MCUFWDL:0x00030006 rtl8192c_common:rtl92c_download_fw():<0-0> Firmware is not ready to run! However, I can still connect to a wireless access point, and use the network. Why is this? Is the firmware actually being loaded despite those messages, or is the firmware not completely necessary? Thanks The firmware is needed, and it was loaded. I think the interrupt problem is making the driver falsely think that the firmware is not ready. Obviously, data is still being transmitted through the USB system as shown by the fact that you can communicate. I do not know anything about ARM, but I am willing to help if I can. This thread appears to be abandoned. Could someone with privilege please close it? Please try to reproduce this bug with latest kernel image. bugzilla-daemon@bugzilla.kernel.org writes: > Please try to reproduce this bug with latest kernel image. Hi. I don't have this hardware anymore, so I can't reproduce this in any reasonable timeframe. Hopefully somebody else can do this. Thanks |