Unable to disable USB host

[levi]

I've just started using a USB wifi gizmo (one supplied by ED) for my wifi networking, as it produced much higher throughput and doesn't drop out on this router whenever you least expect it, so it's very handy for c4a games for example.


However, it uses a lot more power than the internal wifi, so I use the USB host control as a wifi control when I'm not using the network. It would appear that if I turn it on and off a few times over a few hourse, after a few switches it stops responding to being turned off - it does disable the wifi stick, but the menu continues to say 'disable usb host' and I'm unable to turn it on again.


Running op_usbhost.sh says 'ERROR: Removing 'echi_hcd': Device or resource busy' on STDERR. Power usage still seems high indicating it hasn't been able to disable the USB host port completely, though it would still seem the USB stick is no longer connected (I've unplugged it now, so I can't lsusb it, but it wasn't providing a network service).


Is there anything worth doing before doing a reboot now? This is the second time I've experienced this by the way, and a reboot fixed it last time.

 

[notaz]

You should check dmesg output and maybe post it here.

 

[levi]

Okay, dmesg took a bit of figuring out as it doesn't seem to be writing anything new to it any more when I 'rmmod ehci_hcd', but going through it I can find a bunch of 'bad dma' messages which come as part of disabling usb host. On the first two instances I can find this doesn't seem to be much of a problem though, as it goes and reconnects next time I try to fine.


However, the last bunch of ecmi_hcd messages contain a crash. After the bad dma warnings there's a bit of other stuff ending 'ehci-omap ehci-omap.0: USB bus 2 deregistered' in all cases, but in the last case it's followed by a crash:

Spoiler

[12555.703094] Unhandled fault: external abort on non-linefetch (0x1028) at 0xfa062014


[12555.703155] Internal error: : 1028 [#1]


[12555.703308] Modules linked in: ehci_hcd(-) aufs squashfs xz_dec 8192cu(O) bluetooth g_cdc bufferclass_ti(O) omaplfb(O) pvrsrvkm(O) zram© snd_seq snd_seq_device snd_pcm_oss snd_mixer_oss ipv6 fuse ads7846 [last unloaded: ehci_hcd]


[12555.704864] CPU: 0 Tainted: G C O (3.2.63 #1041)


[12555.704956] PC is at omap_usbhs_disable+0xe8/0x1d0


[12555.705078] LR is at omap_usbhs_disable+0x5c/0x1d0


[12555.705169] pc : [] lr : [] psr: 20000193


[12555.705169] sp : cf189ee0 ip : 00000007 fp : bede0734


[12555.705383] r10: 00000000 r9 : cf188000 r8 : c0013f04


[12555.705444] r7 : 00000013 r6 : db925c08 r5 : a0000113 r4 : db927a80


[12555.705596] r3 : c058a1f8 r2 : fa062000 r1 : 00000002 r0 : fa062000


[12555.705718] Flags: nzCv IRQs off FIQs on Mode SVC_32 ISA ARM Segment user


[12555.705810] Control: 10c5387d Table: 8f1f0019 DAC: 55555555


[12555.705932] Process rmmod (pid: 4278, stack limit = 0xcf188238)


[12555.706024] Stack: (0xcf189ee0 to 0xcf18a000)


[12555.706176] 9ee0: c0b0b400 db925c00 db925c08 bf20e274 db925c08 bf217064 bf217064 c027e3f4


[12555.706237] 9f00: c027e3dc c027cc34 db925c08 db925c3c bf217064 c027d260 00000000 bf217064


[12555.706390] 9f20: c05a12e8 c027caf0 00000000 bf2170a0 cf188000 bf216708 bf2166fc c006e22c


[12555.706542] 9f40: c0aa85d8 69636865 6463685f 401fe000 c3a588c0 c00b32f8 401ff000 00000000


[12555.706665] 9f60: 00001000 60000013 d8f27900 c3a588f8 00000000 401fe000 c3a588c0 00013f04


[12555.706756] 9f80: bf2170a0 00000880 cf189f8c 00000000 fbad2408 bede09bc bede0700 00000880


[12555.706909] 9fa0: 00000081 c0013d80 bede09bc bede0700 bede0700 00000880 beddfe80 00000001


[12555.707031] 9fc0: bede09bc bede0700 00000880 00000081 00000000 00000000 00000000 bede0734


[12555.707183] 9fe0: 17dbc0e0 bede06f8 00009124 4016b0ac 60000010 bede0700 c0000000 00000000


[12555.707275] [] (omap_usbhs_disable+0xe8/0x1d0) from [] (ehci_hcd_omap_remove+0x24/0x44 [ehci_hcd])


[12555.707458] [] (ehci_hcd_omap_remove+0x24/0x44 [ehci_hcd]) from [] (platform_drv_remove+0x18/0x1c)


[12555.707611] [] (platform_drv_remove+0x18/0x1c) from [] (__device_release_driver+0x70/0xc0)


[12555.707763] [] (__device_release_driver+0x70/0xc0) from [] (driver_detach+0x9c/0xa0)


[12555.707885] [] (driver_detach+0x9c/0xa0) from [] (bus_remove_driver+0x7c/0xc0)


[12555.708038] [] (bus_remove_driver+0x7c/0xc0) from [] (ehci_hcd_cleanup+0xc/0x34 [ehci_hcd])


[12555.708221] [] (ehci_hcd_cleanup+0xc/0x34 [ehci_hcd]) from [] (sys_delete_module+0x1ec/0x25c)


[12555.708312] [] (sys_delete_module+0x1ec/0x25c) from [] (ret_fast_syscall+0x0/0x30)


[12555.708465] Code: e594203c e3a01002 e5821010 e594003c (e590e014)

Hope that's of more use to you than it is to me!

 

[notaz]

This is on CC/rebirth I guess?

 

[levi]

No, 1GHz unit. What makes you think otherwise?

 

[notaz]

They've changed the interconnects for 3630/3730, so these kind of crashes are less likely to happen.

I'm not able to reproduce this though. In general it's SoC sending abort signal to the CPU, basically meaning "you're programming my registers incorrectly, for that you must now die!". So it's not an usual NULL pointer style programmer's bug, but "make the hardware happy" issue, a bit hard to fix without having a reproducer.

 

[levi]

Okay, thanks for trying. I'm assuming this is an issue simply with loading/unloading the kernel object enough times to trigger it, as I've used usb host before, but generally only once per few days, yet when using it for wifi, I can use it anything up to half a dozen times during a day. But could it be something to do with the USB hardware itself - it's an unbranded 802.11n stick which lsusb identifies as an Realtech part, and dmesg seems to identify it as an RTL8188C 8192C ?


I'll see if I can find a simpler way to reproduce this on my system from a fresh boot.