- call usb_find_interface_driver (usb.c)
- call the probe routine (driver)
- driver at some point calls usb_reset_device (hub.c)
- attempt to acquire
the semaphone again and driver hangs
usb deadlock problem
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
I'm having a problem with a device driver. The driver calls
usb_reset_device() from the driver's probe function. This causes a
deadlock on the semaphore:
usb_address0_sem -- defined in linux/drivers/usb/hub.c
My question is: is it legal to call usb_reset_device() from the probe
routine? In other words, is this a driver problem or a usb sub-system
problem?
The driver was written by someone else and I'm just trying to make it
work. The driver downloads firmware to the device and then apparently
needs to reset it. The documentation for the device is only available
after signing an NDA so I don't have access yet. I have communicated
with the driver writer and he seems to indicate that the reset is
necessary. I'm not sure why he's not seeing the problem.
More specifically the sequence is this:
- load driver
- plug in usb device
- acquire semaphore in usb_hub_port_connect_change (hub.c)
- call usb_new_device (usb.c)
- call usb_find_drivers (usb.c)
- call usb_find_interface_driver (usb.c)
- call the probe routine (driver)
- driver at some point calls usb_reset_device (hub.c)
- attempt to acquire the semaphone again and driver hangs
I've tried it with suse 7.1, 7.2, and 8.0 (2.4.0, 2.4.4, and 2.4.18) and
with an unmodified 2.4.19 all with the same results. Also have used
both "uhci" and "usb-uhci" and get the same results.
--
Mitch
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
