Hi, I hate deadlocks.
khubd is here:
Call Trace:
[<c028d0de>] wait_for_completion+0x6e/0xb0
[<e0609ff9>] usb_start_wait_urb+0x89/0xe0 [usbcore]
[<e060a0a4>] usb_internal_control_msg+0x54/0x70 [usbcore]
[<e060a133>] usb_control_msg+0x73/0x90 [usbcore]
[<e0606e21>] hub_port_init+0x391/0x530 [usbcore]
[<e06072d0>] hub_port_connect_change+0x130/0x3a0 [usbcore]
[<e06077bb>] hub_events+0x27b/0x3a0 [usbcore]
[<e0607915>] hub_thread+0x35/0xe0 [usbcore]
[<c0100ca5>] kernel_thread_helper+0x5/0x10
That won't timeout because of broken OPTi chip issues, so I try
pulling the plug. However, cardctl ends up sitting here:
Call Trace: [<c028c95b>]
__down+0x7b/0xd0
[<c028caba>] __down_failed+0xa/0x10
[<e0604fc0>] .text.lock.usb+0x16/0xc6 [usbcore]
[<e060631b>] usb_disconnect+0x10b/0x120 [usbcore]
[<e0609965>] usb_remove_hcd+0x55/0x90 [usbcore]
[<e060d60c>] usb_hcd_pci_remove+0x1c/0x90 [usbcore]
[<c01b9ab3>] pci_device_remove+0x33/0x40
[<c01f2e43>] device_release_driver+0x63/0x70
[<c01f3089>] bus_remove_device+0x69/0xb0
[<c01f1f54>] device_del+0x54/0x90
[<c01f1f9d>] device_unregister+0xd/0x20
[<c01b773c>] pci_destroy_dev+0x1c/0x70
[...]
because hub_events() has locked the hub for the duration.
I assume that the same thing can happen if you either call cardctl or
physically pull the card at exactly the wrong moment.
Any ideas on how to fix that? Temporarily unlock the hub while sending
the message, and check whether it's still up afterwards?
--
Matthias Urlichs | {M:U} IT Design @ m-u-it.de | [EMAIL PROTECTED]
Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de
- -
The correct way to punctuate a sentence that starts: "Of course it is none
of my business, but --" is to place a period after the word "but." Don't use
excessive force in supplying such a moron with a period. Cutting his throat
is only a momentary pleasure and is bound to get you talked about.
-- Lazarus Long, "Time Enough for Love"
signature.asc
Description: Digital signature
