This bug can be reproduced by a USB to SD/MMC/MS/CF adaptor that cannot handle SDHC. The failure of the adaptor to recognize/connect the SDHC which uses a slightly different protocol, triggers the error by looping the probe/reset/probe long enough to get messages and state out of sync.
After further investigation, what appeared to be a recursive call that attempted to device_del twice, it turns out that the problem is that the device_add never happened because the adaptor did a reset (and sent a message back) before the initialization was complete. It seems that the device_add in question, the top scsi device is last and the disconnect/reset occurs before we get that far. I cleaned up the power structures init only to fall into the sysfs cleanup of its uninit'ed structures (this moves the null deref from device_del->device_pm_remove to device_del->dpm_sysfs_remove, essentially the next line in device_del. The problem (and its solution) is that usb_disable_device has to be held off until the initialization is complete. There is a race here in that the failure->reset->reconnect sequence loops around a number of times before it eventually fails. If the setup completes (even in error), the disconnect "does the right thing". There are a number of other open bugs that show a similar signature even though they may be serial or other usb type devs. -- USB stops working after a while https://bugs.launchpad.net/bugs/228746 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
