On Mon, Feb 18, 2019 at 10:32:57AM +0000, Nix wrote: > On 18 Feb 2019, Johan Hovold stated: > > > On Sun, Feb 17, 2019 at 07:13:52PM +0000, Nix wrote: > >> I'm still fairly sure this is a regression -- my machines are often up > >> for a lot longer than that and I've never seen this before I upgraded to > >> 4.20.x -- but I don't think I'm going to identify it by mindless > >> bisection. I might have to actually *think* about it. > > > > I doubt it's a regression in usb-serial as essentially nothing changed > > with respect to pl2303 or core since 4.19. > > Yeah, I came to that conclusion as well. > > > The -ENOSPC you're seeing is returned by the host controller to > > indicate: > > > > This request would overcommit the usb bandwidth reserved for > > periodic transfers (interrupt, isochronous). > > Side note: probably not related to *this* -ENOSPC, which I've been > seeing for a few releases now and which appears to break Chromium's U2F > negotiation when the USB bus has sufficiently weird devices on it (like, > uh, my wireless mouse): > > <https://bugs.chromium.org/p/chromium/issues/detail?id=932699> > > (I say "probably not related" because it's much older and long predates > the pl2303 trouble.)
Yeah, hard to tell from a quick look. > > but if you're saying you can reproduce this on "every box" it may not be > > related to any particular host-controller driver (or USB topology). > > They are all xhci, at least. The pl2303 is USB 2. One machine, a > two-year-old Broadwell server, says: > So the quirks are all totally different, and the controllers are quite > different as well... Yeah, but they are all xhci as you point out so theoretically it could be an xhci driver regression. Johan
