On Thu, Sep 30, 2021 at 11:30:17AM +0200, Oliver Neukum wrote: > > On 29.09.21 11:52, Jason-ch Chen wrote: > > On Wed, 2021-09-29 at 08:14 +0000, Hayes Wang wrote: > >> > > Hi Hayes, > > > > Sometimes Rx submits rapidly and the USB kernel driver of opensource > > cannot receive any disconnect event due to CPU heavy loading, which > > finally causes a system crash. > > Do you have any suggestions to modify the r8152 driver to prevent this > > situation happened? > > > > Regards, > > Jason > > > Hi, > > Hayes proposed a solution. Basically you solve this the way HID or WDM do it > delaying resubmission. This makes me wonder whether this problem is specific > to any driver. If it is not, as I would argue, do we have a deficiency > in our API? > > Should we have something like: usb_submit_delayed_urb() ? There has been some discussion about this in the past. In general, -EPROTO is almost always a non-recoverable error. In usually occurs when a USB cable has been unplugged, before the upstream hub has notified the kernel about the unplug event. It also can occur when the device's firmware has crashed. I do tend to think there is a deficiency in our API, and that it should be fixed by making the core logically disable an endpoint (clear the ep->enabled flag) whenever an URB for that endpoint completes with -EPROTO, -EILSEQ, or -ETIME status. (In retrospect, using three distinct status codes for these errors was a mistake.) Then we wouldn't have to go through this piecemeal approach, modifying individual drivers to make them give up whenever they get one of these errors. But then we'd have also have to make sure drivers have a way to logically re-enable endpoints, for the unlikely case that the error can be recovered from. Certainly set-config, set-interface, and clear-halt should do this. Anything else? Alan Stern
