Hello.
Jon Povey wrote:
In the process of looking into problems with MUSB OTG behaviour here, I tried a rebase to the current master, which has broken module unload of musb_hdrc - it now OOPSes while trying to rmmod (OOPS pasted below).
Saw that, though it was really a WARNING in my case.
I reverted two commits in /musb, after reverting the second I could unload musb_hdrc without crash:
#1 34e2beb2c883e0ea1b6135ad6f7713f7574a01aa
#2 461972d8a4c94bc44f11a13046041c78a7cf18dd
Yeah, the second one seems to be a culprit. I haven't tested it in OTG mode.
[...]
The OOPS:
Unable to handle kernel NULL pointer dereference at virtual address 0000002c
pgd = c7df0000
Strange, I got a WARNING there...
[0000002c] *pgd=87e1b031, *pte=00000000, *ppte=00000000
Internal error: Oops: 17 [#1] PREEMPT
last sysfs file: /sys/devices/platform/musb_hdrc/usb1/product
Modules linked in: musb_hdrc(-) [last unloaded: g_serial]
CPU: 0 Not tainted (2.6.34-07363-g879b87a #78)
PC is at kobject_put+0x18/0x60
LR is at put_device+0x1c/0x20
pc : [<c012f0b4>] lr : [<c016c91c>] psr: 20000013
sp : c7e0be28 ip : c7e0be48 fp : c7e0be44
r10: 00000000 r9 : c7e0a000 r8 : c00260a4
r7 : fec64000 r6 : c030f038 r5 : c7dfd100 r4 : 0000000c
r3 : c7d84360 r2 : c7e0bdf8 r1 : c7db6440 r0 : 0000000c
Flags: nzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment user
Control: 0005317f Table: 87df0000 DAC: 00000015
Process rmmod (pid: 1019, stack limit = 0xc7e0a270)
Stack: (0xc7e0be28 to 0xc7e0c000)
be20: c7e0be54 c7e0be38 c006a3c0 c7dfd100 c7e0be54 c7e0be48
be40: c016c91c c012f0ac c7e0be6c c7e0be58 bf000920 c016c910 00000000 c7dfd100
be60: c7e0be8c c7e0be70 bf0081fc bf0008d0 c030f040 bf00a530 c030f074 bf00a530
be80: c7e0be9c c7e0be90 c0170f90 bf0081a8 c7e0beb4 c7e0bea0 c016fbe0 c0170f80
bea0: c030f040 c7e0a000 c7e0bed4 c7e0beb8 c016fce8 c016fb60 bf00a530 bf00a530
bec0: c0320588 c7e0bf3c c7e0bef4 c7e0bed8 c016ee78 c016fc3c 00000000 bf00a530
bee0: 00000000 c7e0bf3c c7e0bf14 c7e0bef8 c01702b4 c016edf0 00000000 bf00a5b8
bf00: 00000880 c7e0bf3c c7e0bf24 c7e0bf18 c01711f4 c017025c c7e0bf34 c7e0bf28
bf20: bf008190 c01711f0 c7e0bfa4 c7e0bf38 c0066310 bf00818c c0089088 6273756d
bf40: 7264685f c7e00063 c0132cc0 c0032fec 00000000 c7dd7934 00001000 40020000
bf60: c00260a4 00000000 c7e0bf84 c7e0bf78 c0055934 00132b80 bf00a5b8 00000880
bf80: c7e0bf84 00000000 00090008 00000000 00098028 00000081 00000000 c7e0bfa8
bfa0: c0025f20 c006612c 00090008 00000000 00098028 00000880 00098278 00098278
bfc0: 00090008 00000000 00098028 00000081 00000001 beba8e68 00000000 00000000
bfe0: 00098278 beba8ac8 00014140 400e96dc 20000010 00098028 e9045000 22540000
Backtrace:
[<c012f09c>] (kobject_put+0x0/0x60) from [<c016c91c>] (put_device+0x1c/0x20)
r4:c7dfd100
[<c016c900>] (put_device+0x0/0x20) from [<bf000920>] (musb_free+0x60/0x70 [musb_hdrc])
I've looked into this and was puzzled by that imbalanced put_device() call
in musb_free(), surrounded by OTG #ifdef. Why it is here, and why only for OTG
case? What I think should be done instead are the otg_put_transceiver() calls,
symmetrical to otg_get_transcaiver() calls in the glue layers. Felipe?
[<bf0008c0>] (musb_free+0x0/0x70 [musb_hdrc]) from [<bf0081fc>] (musb_remove+0x64/0x8c [musb_hdrc])
r5:c7dfd100 r4:00000000
[<bf008198>] (musb_remove+0x0/0x8c [musb_hdrc]) from [<c0170f90>] (platform_drv_remove+0x20/0x24)
r7:bf00a530 r6:c030f074 r5:bf00a530 r4:c030f040
[<c0170f70>] (platform_drv_remove+0x0/0x24) from [<c016fbe0>] (__device_release_driver+0x90/0xdc)
[<c016fb50>] (__device_release_driver+0x0/0xdc) from [<c016fce8>] (driver_detach+0xbc/0xe4)
r5:c7e0a000 r4:c030f040
[<c016fc2c>] (driver_detach+0x0/0xe4) from [<c016ee78>] (bus_remove_driver+0x98/0xc0)
r7:c7e0bf3c r6:c0320588 r5:bf00a530 r4:bf00a530
[<c016ede0>] (bus_remove_driver+0x0/0xc0) from [<c01702b4>] (driver_unregister+0x68/0x78)
r7:c7e0bf3c r6:00000000 r5:bf00a530 r4:00000000
[<c017024c>] (driver_unregister+0x0/0x78) from [<c01711f4>] (platform_driver_unregister+0x14/0x18)
r7:c7e0bf3c r6:00000880 r5:bf00a5b8 r4:00000000
[<c01711e0>] (platform_driver_unregister+0x0/0x18) from [<bf008190>] (musb_cleanup+0x14/0x1c [musb_hdrc])
[<bf00817c>] (musb_cleanup+0x0/0x1c [musb_hdrc]) from [<c0066310>] (sys_delete_module+0x1f4/0x268)
[<c006611c>] (sys_delete_module+0x0/0x268) from [<c0025f20>] (ret_fast_syscall+0x0/0x2c)
r7:00000081 r6:00098028 r5:00000000 r4:00090008
Code: e24cb004 e24dd00c e2504000 0a00000b (e5d43020)
WBR, Sergei
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
