> > See if this patch helps; I think it should. > > A partial success... It doesn't oops or panic,
Good first step then. :) That didn't actually address the curious question of _why_ your driver would be triggering that cleanup codepath. And what it'd need to do it if oopsing was no longer an option ... > but it got into an > infinite loop as soon as I turn off the UA-1000, repeatedly outputting > these four lines: > > ehci_hcd 0000:00:03.3: devpath 5 ep3in 3strikes > ALSA sound/usb/usbmidi.c:176: urb status -71 > usb 3-5: unlink qh0-00ff/c91dc100 start 0 [17/0 us] > usb 3-5: link qh0-00ff/c91dc100 start 0 [17/0 us] ... see below > Out of curiosity, I tried the following change, to treat -71 (-EPROTO) > as a terminal error in sound/usb/usbmidi.c, and I can now turn the > UA-1000 off and on to my heart's content. > > --- sound/usb/usbmidi.c 2005-08-01 11:25:06.000000000 +0100 > +++ sound/usb/usbmidi.orig.c 2005-07-29 09:52:23.000000000 +0100 > @@ -171,8 +171,7 @@ static int snd_usbmidi_urb_error(int sta > return status; /* killed */ > if (status == -EILSEQ || > status == -ECONNRESET || > - status == -ETIMEDOUT || > - status == -EPROTO) > + status == -ETIMEDOUT) > return -ENODEV; /* device removed/shutdown */ > snd_printk(KERN_ERR "urb status %d\n", status); > return 0; /* continue */ > > > I have no idea whether this is the right thing to do: I expect it's > almost certainly not... The different controllers have different ways of reporting the disconnect faults. In the case of EHCI, EPROTO is indeed one of the faults that will sometimes indicate "device disconnected but khubd hasn't reported it yet". In other cases it will indicate a temporary hardware glitch. See drivers/usb/net/usbnet.c in rx_complete() for one way to cope with those problems. EPROTO is used there as a hint to throttle down resubmits. When it's a recoverable error (cabling/hardware glitch) things recover. Otherwise (disconnect) the driver gets shut down sooner, because it's not spinning forever and livelocking khubd. FWIW I think "usbnet" is one of the few USB drivers to really pay much attention to fault handling/recovery issues ... at the time the audio drivers were written, there were no good models to follow. So that rx_complete() callback might be worth some study. - Dave This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. ------------------------------------------------------- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click _______________________________________________ [email protected] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
