On Wed, 28 Apr 2004 [EMAIL PROTECTED] wrote:

> I think one of the threads is updfstab, lsusb, or kudzu, which access 
> the device's pipe 0 through the /proc directory, while the other thread 
> is just cdrom.c trying to do some stuff with the drive.  I'm not sure
> how 
> one could keep these things from running simultaneously.  But, once this
> 
> problem happens, the USB driver can't even be unloaded--one must reboot 
> the system to get the USB subsystem working again!

That shouldn't happen.  Even if the stall isn't cleared and things 
continue to go wrong, the usb-storage driver should be able to recover 
once that other process is no longer using the device.

> I'm not looking to re-architect the drivers--I just want to do something
> to keep the system from failing when this happens.
> 
> Perhaps I could keep the proc_ioctls from running until the device isn't
> being used by usb-storage,

That sounds feasible.

>  or maybe just make the transport layer of
> usb-storage retry the clear_feature command for a while if the pipe
> already has an URB going, instead of simply failing and moving on to
> the next step without clearing the stall...?

You could do that.  Check for -ENXIO error codes and retry in a short 
loop with usb_stor_control_msg().

Alan Stern



-------------------------------------------------------
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g. 
Take an Oracle 10g class now, and we'll give you the exam FREE. 
http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel

Reply via email to