On Mon, 6 Jun 2016, Michał Pecio wrote: > > > 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. > > Possible. This modem runs 1007 byte ISO IN and 32 byte INT IN. > OHCI scheduler accepts a further 48 byte ISO stream, but rejects > 192 byte ISO and low-speed stuff. That's clear enough. ISO IN 1007 bytes -> 793 us INT IN 32 bytes -> 35 us ------ 825 us The additional requirements are: ISO IN 48 bytes -> 45 us -> 870 us total ISO IN 192 bytes -> 158 us -> 983 us total and the spec allows only 900 us from each frame to be allocated for periodic transfers. That's why the additional 48-byte stream is okay but the additional 192-byte stream isn't. > Anyway, this wasn't my point, because... > > > > 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. > > I think *we* made a change to bandwidth allocation, namely, we killed a > bug which bypasses bandwidth allocation :) > > If ed_schedule fails and leaves the ed in OPER state, the next time > somebody tries to use this endpoint, ohci_urb_enqueue skips the whole > block which normally calls ed_schedule. Only by some dark magic, which > I don't comprehend, the buffers end up being submitted to the hardware. periodic_link() gets called from only one place: ed_schedule(). Did you remember to check ed_schedule()'s other call site, in finish_unlinks()? Maybe that's where the "dark magic" is. > Something like that is visible in the log I posted yesterday: ueagle > driver resubmits this failing urb like crazy but *only once* the branch > 'if (ed->state==ED_IDLE)' is taken and ed_schedule() called. Despite > this, however, the modem starts to work once I disconnect other stuff. It sounds like the ueagle-atm driver ought to be more careful about resubmitting URBs after an ENOSPC error. Regardless, the change you tested in ed_schedule() seems to be the bug fix we want. Would you like to submit a patch, or shall I? 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
