On Mon, 6 Jun 2016, Michał Pecio wrote: > > Apparently this bug also prevented scheduling of endpoints which > > failed to schedule once in the past. Formerly I was getting only one > > > > usbatm_submit_urb: urb 0xffff8807f1568b00 submission failed (-28)! > > > > from ueagle-atm and now I'm getting regular spam. I think there's good > > chance that even on pre-3.18 kernels (which don't crash) iso streams > > silently drop data if the first submission fails and the driver > > retries. > > > > I'll be able to do some functional testing later... > > Sending this from the Eagle on OHCI. Works fine after 1 hour, 0.5GB and > few USB reconnections. > > As I said, it now reports ENOSPC errors if there are low-speed devices > or significant isochronous transfers on the bus. It's quite possible that those are genuine errors. That is, the requested bandwidth may be more than the bus can provide. What does /sys/kernel/debug/usb/devices show when everything is plugged in and running? (You may need to mount /sys/kernel/debug first.) The information in that file will tell us how much bandwidth is allocated and how much is required. You should also see what is in /sys/kernel/debug/usb/ohci/*/periodic (fill in the * with the device name for the controller which these devices are plugged into). > And as I suspected, 3.14 happily lets me run this modem and a low-speed > keyboard and a 192kB/s audio stream, all at the same time and with no > errors whatsoever :) Only it takes pppd a few minutes to even establish > the ppp session. I don't think there were any significant changes to the bandwidth allocation routines in ohci-hcd between those kernel releases, but perhaps there were. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
