From: Johan Hovold <johan@kernel.org>
To: Nix <nix@esperi.org.uk>
Cc: Johan Hovold <johan@kernel.org>, Greg KH <greg@kroah.com>,
linux-usb@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: 4.20.7: pl2303 not working (post-4.19 regression) (limited info so far, not yet bisected)
Date: Wed, 20 Feb 2019 10:29:20 +0100 [thread overview]
Message-ID: <20190220092920.GH4072@localhost> (raw)
In-Reply-To: <87sgwls7xi.fsf@esperi.org.uk>
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
prev parent reply other threads:[~2019-02-20 9:29 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-02-16 16:26 4.20.7: pl2303 not working (post-4.19 regression) (limited info so far, not yet bisected) Nix
2019-02-16 19:47 ` Greg KH
2019-02-17 19:13 ` Nix
2019-02-18 7:58 ` Johan Hovold
2019-02-18 10:32 ` Nix
2019-02-20 9:29 ` Johan Hovold [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20190220092920.GH4072@localhost \
--to=johan@kernel.org \
--cc=greg@kroah.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
--cc=nix@esperi.org.uk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.