Hi. I have a suspicion the firmware-loading changes that happened around 3.3 are still not perfect. I'm using a Beagleboard-xM (ARM OMAP3 board). I'm running an almost-vanilla 3.7-rc7; the non-vanilla pieces touch some power regulators specific to this board and some unrelated drivers. I build rtl8192cu as a module. I boot and load the module, and see this: rtl8192cu 1-2.2:1.0: usb_probe_interface rtl8192cu 1-2.2:1.0: usb_probe_interface - got id rtl8192cu: Chip version 0x10 rtl8192cu: MAC address: 08:86:3b:a3:b4:49 rtl8192cu: Board Type 0 rtlwifi: rx_max_size 15360, rx_urb_num 8, in_ep 1 rtl8192cu: Loading firmware rtlwifi/rtl8192cufw.bin ieee80211 phy0: Selected rate control algorithm 'rtl_rc' rtlwifi: wireless switch is on This looks OK. Then I "ifconfig wlan0 up". I then see this: rtl8192cu: MAC auto ON okay! rtl8192cu: Tx queue select: 0x05 irq 26: nobody cared (try booting with the "irqpoll" option) [<c0012fac>] (unwind_backtrace+0x0/0xf0) from [<c009250c>] (__report_bad_irq+0x20/0xa4) [<c009250c>] (__report_bad_irq+0x20/0xa4) from [<c0092714>] (note_interrupt+0x184/0x22c) [<c0092714>] (note_interrupt+0x184/0x22c) from [<c0090cbc>] (handle_irq_event_percpu+0x1ec/0x220) [<c0090cbc>] (handle_irq_event_percpu+0x1ec/0x220) from [<c0090d18>] (handle_irq_event+0x28/0x38) [<c0090d18>] (handle_irq_event+0x28/0x38) from [<c0092ff8>] (handle_level_irq+0xc8/0xf8) [<c0092ff8>] (handle_level_irq+0xc8/0xf8) from [<c0090ac0>] (generic_handle_irq+0x28/0x30) [<c0090ac0>] (generic_handle_irq+0x28/0x30) from [<c000e12c>] (handle_IRQ+0x60/0x84) [<c000e12c>] (handle_IRQ+0x60/0x84) from [<c00086e8>] (omap3_intc_handle_irq+0x60/0x74) [<c00086e8>] (omap3_intc_handle_irq+0x60/0x74) from [<c0442e40>] (__irq_svc+0x40/0x50) Exception stack(0xc063de00 to 0xc063de48) de00: 00000000 00000000 00200000 0000000a c063c000 00000002 00000000 c06b0ec0 de20: 00000002 c0644b84 df39d900 c06639cc 00000003 c063de48 c0037d9c c0037ba0 de40: 20000113 ffffffff [<c0442e40>] (__irq_svc+0x40/0x50) from [<c0037ba0>] (__do_softirq+0x58/0x1d4) [<c0037ba0>] (__do_softirq+0x58/0x1d4) from [<c0037d9c>] (irq_exit+0x40/0x8c) [<c0037d9c>] (irq_exit+0x40/0x8c) from [<c000e130>] (handle_IRQ+0x64/0x84) [<c000e130>] (handle_IRQ+0x64/0x84) from [<c00086e8>] (omap3_intc_handle_irq+0x60/0x74) [<c00086e8>] (omap3_intc_handle_irq+0x60/0x74) from [<c0442e40>] (__irq_svc+0x40/0x50) Exception stack(0xc063deb8 to 0xc063df00) dea0: df553200 c0647890 dec0: c063df00 c063c000 df553200 00000000 df39d900 df553200 00000002 c0644b84 dee0: df39d900 c063df1c 00000000 c063df00 c044235c c005ab98 60000013 ffffffff [<c0442e40>] (__irq_svc+0x40/0x50) from [<c005ab98>] (T.1336+0x4c/0x114) [<c005ab98>] (T.1336+0x4c/0x114) from [<c044235c>] (__schedule+0x4fc/0x554) [<c044235c>] (__schedule+0x4fc/0x554) from [<c000e5fc>] (cpu_idle+0x98/0xa8) [<c000e5fc>] (cpu_idle+0x98/0xa8) from [<c060a680>] (start_kernel+0x290/0x2e0) handlers: [<c025abf8>] omap3_l3_app_irq Disabling IRQ #26 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! IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready This looks less OK. The network does work after this, so this is possibly benign, but it looks dangerous. I tried with an entirely vanilla 3.2 (prior to the firmware-loading changes) and things work without any issues. I then tried 3.4, and got a much nastier crash: root@beagle:~# ifconfig wlan0 up [ 89.395660] rtl8192cu: MAC auto ON okay! [ 89.490539] rtl8192cu: Tx queue select: 0x05 [ 89.497436] ------------[ cut here ]------------ [ 89.502319] kernel BUG at /home/dima/linux/arch/arm/include/asm/dma-mapping.h:321! [ 89.510253] Internal error: Oops - BUG: 0 [#1] ARM [ 89.515289] Modules linked in: arc4 rtl8192cu rtl8192c_common rtlwifi mac80211 cfg80211 [ 89.523742] CPU: 0 Tainted: G W (3.4.0 #15) [ 89.529418] PC is at usb_hcd_map_urb_for_dma+0x230/0x344 [ 89.535003] LR is at dma_cache_maint_page+0xf8/0x104 [ 89.540222] pc : [<c02ea8a0>] lr : [<c0014560>] psr: 20000013 [ 89.540222] sp : de4bfc50 ip : c0017ac0 fp : 00000000 [ 89.552276] r10: 0009e534 r9 : 00000010 r8 : c060d4f4 [ 89.557739] r7 : 00000000 r6 : 00000000 r5 : df5d2c00 r4 : df795780 [ 89.564605] r3 : 00000001 r2 : 000000ea r1 : e0000000 r0 : ffdfb000 [ 89.571441] Flags: nzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment user [ 89.578948] Control: 10c5387d Table: 9f744019 DAC: 00000015 [ 89.584960] Process ifconfig (pid: 852, stack limit = 0xde4be2f0) [ 89.591369] Stack: (0xde4bfc50 to 0xde4c0000) [ 89.595947] fc40: df5d2c00 df795780 df795780 df5d2c00 [ 89.604522] fc60: df795788 00000010 00000000 df62c400 00000040 c02eaf94 00000020 0000000c [ 89.613128] fc80: c060eddc c0b05d60 00000000 c0014c04 c00dbf98 df795e80 df795780 00000010 [ 89.621704] fca0: c0711c04 df795780 de4bfcd8 de4bfd14 00000032 00000000 df62c400 00000040 [ 89.630310] fcc0: 00000000 c02ec75c 00000000 c0014dcc 00000247 c00dbf98 00000000 de4bfcdc [ 89.638885] fce0: de4bfcdc 00000005 de534680 00000005 de534680 000000ea 00000000 00001000 [ 89.647460] fd00: 00000040 c02eca00 00000009 80000400 00000001 df6c8c00 80000480 000000ea [ 89.656066] fd20: df62c400 ffdfb000 e08f7020 00000004 00000011 00001000 00000009 bf0a97b4 [ 89.664642] fd40: 00001000 00000000 ffdfb000 000000ea 00000032 bf0a98b4 de438fe0 9f7e9000 [ 89.673248] fd60: e08f7020 de438fe0 e08f7020 e08f710a 000010ea 00000001 00000076 bf0bc8f0 [ 89.681823] fd80: 00000001 de438fe0 e08f7020 de438320 e08f8020 00000003 00000e6e bf0bcd30 [ 89.690429] fda0: de438fe0 de438320 de438fe0 00000002 1fff7fff 00000000 de438fe0 de438320 [ 89.699005] fdc0: de438fe0 00000002 de438fe0 00000010 de438fe0 bf0d427c 00000003 00000003 [ 89.707611] fde0: 00000003 c072d7a0 de4bfde8 00000000 000000e7 df709488 df709000 de438fe0 [ 89.716186] fe00: de438320 de438fec df709480 df71b00c 00000001 00000000 de4bfec8 bf0a8f0c [ 89.724761] fe20: de438fe0 de438320 de438fec df709480 df71b00c 00000001 00000000 bf0a4548 [ 89.733367] fe40: de438320 df709000 00001002 bf03e86c df709000 bf063c24 00001002 00000001 [ 89.741943] fe60: df71b00c 00008914 00000000 c036ce84 df709000 00001043 00001002 c036a7c8 [ 89.750549] fe80: df709000 00001002 df709000 df71b000 df71b00c c036cdb0 00000000 00000001 [ 89.759124] fea0: df709000 c03b3718 00000020 00000000 befa3564 befa395b 6e616c77 00000030 [ 89.767700] fec0: 00000000 00000000 b6f51043 befa395b 0000002c 0000006e b6f51043 befa395b [ 89.776306] fee0: 0000002c 0000006e b6f51002 00008914 befa3564 c0712bd8 00000004 00000000 [ 89.784881] ff00: de4be000 00000000 befa395b c0359cc0 befa3564 df6db0c0 00008914 00000004 [ 89.793487] ff20: 00000000 c00f3c20 00000000 00000000 df402200 df40c540 df70f000 000080d0 [ 89.802062] ff40: 00000018 df795e80 00000000 df795f80 df795e80 de534740 df795f80 c0202784 [ 89.810668] ff60: df795e80 00000004 df795f80 df6db0c0 befa3564 00008914 00000004 00000000 [ 89.819244] ff80: de4be000 c00f3cd4 00000004 00000000 0001f958 befa3648 0001f6d4 00000036 [ 89.827819] ffa0: c000d9c4 c000d840 0001f958 befa3648 00000004 00008914 befa3564 00001002 [ 89.836425] ffc0: 0001f958 befa3648 0001f6d4 00000036 0001f960 00000075 b6f68000 befa395b [ 89.845001] ffe0: 00001043 befa3558 0000b9b4 b6ebe3dc 60000010 00000004 9f8fe821 9f8fec21 [ 89.853607] [<c02ea8a0>] (usb_hcd_map_urb_for_dma+0x230/0x344) from [<c02eaf94>] (usb_hcd_submit_urb+0x5e0/0x700) [ 89.864379] [<c02eaf94>] (usb_hcd_submit_urb+0x5e0/0x700) from [<c02ec75c>] (usb_start_wait_urb+0x44/0x120) [ 89.874633] [<c02ec75c>] (usb_start_wait_urb+0x44/0x120) from [<c02eca00>] (usb_control_msg+0xcc/0xf0) [ 89.884460] [<c02eca00>] (usb_control_msg+0xcc/0xf0) from [<bf0a97b4>] (_usb_writeN_sync+0x80/0x9c [rtlwifi]) [ 89.894927] [<bf0a97b4>] (_usb_writeN_sync+0x80/0x9c [rtlwifi]) from [<bf0bc8f0>] (_rtl92c_fw_block_write+0x54/0x128 [rtl8192c_common]) [ 89.907745] [<bf0bc8f0>] (_rtl92c_fw_block_write+0x54/0x128 [rtl8192c_common]) from [<bf0bcd30>] (rtl92c_download_fw+0x200/0x544 [rtl8192c_common]) [ 89.921661] [<bf0bcd30>] (rtl92c_download_fw+0x200/0x544 [rtl8192c_common]) from [<bf0d427c>] (rtl92cu_hw_init+0xb40/0x1378 [rtl8192cu]) [ 89.934570] [<bf0d427c>] (rtl92cu_hw_init+0xb40/0x1378 [rtl8192cu]) from [<bf0a8f0c>] (rtl_usb_start+0x20/0x1a4 [rtlwifi]) [ 89.946228] [<bf0a8f0c>] (rtl_usb_start+0x20/0x1a4 [rtlwifi]) from [<bf0a4548>] (rtl_op_start+0x48/0x70 [rtlwifi]) [ 89.957305] [<bf0a4548>] (rtl_op_start+0x48/0x70 [rtlwifi]) from [<bf03e86c>] (ieee80211_do_open+0x148/0x9a4 [mac80211]) [ 89.968811] [<bf03e86c>] (ieee80211_do_open+0x148/0x9a4 [mac80211]) from [<c036ce84>] (__dev_open+0xa0/0xf0) [ 89.979156] [<c036ce84>] (__dev_open+0xa0/0xf0) from [<c036a7c8>] (__dev_change_flags+0xa4/0x130) [ 89.988464] [<c036a7c8>] (__dev_change_flags+0xa4/0x130) from [<c036cdb0>] (dev_change_flags+0x10/0x44) [ 89.998352] [<c036cdb0>] (dev_change_flags+0x10/0x44) from [<c03b3718>] (devinet_ioctl+0x2f4/0x6d8) [ 90.007873] [<c03b3718>] (devinet_ioctl+0x2f4/0x6d8) from [<c0359cc0>] (sock_ioctl+0x1f8/0x244) [ 90.016998] [<c0359cc0>] (sock_ioctl+0x1f8/0x244) from [<c00f3c20>] (do_vfs_ioctl+0x4d4/0x53c) [ 90.026062] [<c00f3c20>] (do_vfs_ioctl+0x4d4/0x53c) from [<c00f3cd4>] (sys_ioctl+0x4c/0x6c) [ 90.034851] [<c00f3cd4>] (sys_ioctl+0x4c/0x6c) from [<c000d840>] (ret_fast_syscall+0x0/0x30) [ 90.043701] Code: e59f1110 e5911000 e1500001 3a000001 (e7f001f2) [ 90.050323] ---[ end trace 1b75b31a2719ed1e ]--- This crash doesn't happen in 3.7-rc7, but it could be indicative that the firmware functionality is at fault. Thanks.
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