Hi, There seems to be a mismatch with the behaviour of dummy_hcd and composite regarding removal after the move to new style udc_start/stop. I get an oops with: modprobe dummy_hcd modprobe g_serial rmmod g_serial Process rmmod (pid: 4233, threadinfo ffff88006c7e6000, task ffff88006c78e930) Stack: ffffffffa00a026b ffff88006c73a9a0 ffffffffa004f8a0 ffffffffa0050300 ffffffffa004c5de ffff880079fc43c0 ffffffffa0050330 ffff88006c73a9a0 ffffffffa004f8a0 0000000000000000 ffffffffa004cade ffff88006c739400 Call Trace: [<ffffffffa00a026b>] ? composite_disconnect+0x3b/0x80 [g_serial] [<ffffffffa004c5de>] ? set_link_state+0x20e/0x2f0 [dummy_hcd] [<ffffffffa004cade>] ? dummy_pullup+0x10e/0x140 [dummy_hcd] [<ffffffffa000304b>] ? usb_gadget_remove_driver+0x4b/0x80 [udc_core] [<ffffffffa00030e4>] ? usb_gadget_unregister_driver+0x64/0x90 [udc_core] [<ffffffffa00a364e>] ? cleanup+0xd/0x13 [g_serial] [<ffffffffa00a3641>] ? override_id.isra.24+0x3d/0x3d [g_serial] [<ffffffff8106849d>] ? sys_delete_module+0x16d/0x230 [<ffffffff814c3522>] ? system_call_fastpath+0x16/0x1b Code: 38 c2 74 10 0f 1f 80 00 00 00 00 f3 90 0f b6 07 38 d0 75 f7 c3 66 66 66 66 66 2e 0f 1f 84 00 00 00 00 00 9c 58 fa ba 00 01 00 00 <f0> 66 0f c1 17 0f b6 ce 38 d1 74 0d 0f 1f 40 00 f3 90 0f b6 17 RIP [<ffffffff814c2ac8>] _raw_spin_lock_irqsave+0x8/0x30 Which is caused by usb_gadget_remove_driver calling composite_unbind(), which clears the gadget data, and then usb_gadget_disconnect -> dummy_pullup -> set_link_state which calls composite_disconnect which then oopses as the gadget_data is gone. So who is to blame? Should we protect composite_disconnect with a cdev test to adjust dummy_hcd to not call it? This is with 3.3.4, but I don't right away see any relevant changes in git. -- Bye, Peter Korsgaard -- 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
