On Fri, 30 Jan 2009, Oliver Neukum wrote: > Hi, > > ejecting a PC-card that contains an ohci controler hangs the ejecting task. > During the ejection pci_disable_device() is called: > Jan 30 14:45:37 linux-daoy kernel: [<c0202ba0>] pci_disable_device+0x3d/0x50 > Jan 30 14:45:37 linux-daoy kernel: [<f8048425>] usb_hcd_pci_remove+0x80/0x87 [usbcore] > Jan 30 14:45:37 linux-daoy kernel: [<c0204c81>] pci_device_remove+0x19/0x39 > Jan 30 14:45:37 linux-daoy kernel: [<c02669c9>] __device_release_driver+0x61/0x7e > Jan 30 14:45:37 linux-daoy kernel: [<c0266a97>] device_release_driver+0x1b/0x26 > Jan 30 14:45:37 linux-daoy kernel: [<c026625d>] bus_remove_device+0x75/0x8f > Jan 30 14:45:37 linux-daoy kernel: [<c0264fe5>] device_del+0xf1/0x148 > Jan 30 14:45:37 linux-daoy kernel: [<c0265047>] device_unregister+0xb/0x15 > Jan 30 14:45:37 linux-daoy kernel: [<c02010e7>] pci_stop_dev+0x23/0x2d ... > That disables the card's interrupt line and tries to call usb_kill_urb() after that Your description contains a few mistakes. usb_kill_urb is called from within usb_remove_hcd, which also unregisters the interrupt handler. Both those things happen _before_ pci_disable_device. > which forever waits for an interrupt (presumably the doorbell interrupt) Your stack dump seems to show that pci_disable_device is waiting, not usb_kill_urb. By the time pci_disable_device is called, the entire USB bus and all the devices on it have been unregistered, their drivers unbound, and all URBs terminated. Even if some errant routine did manage to call usb_kill_urb after that point, the newly-added usb_hcd_synchronize_unlinks code would prevent the call from ever reaching the HCD. > Taking an extra reference to the pci device doesn't help. > What is to be done? Are you sure you really understand the nature of the problem? Alan Stern -- 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
