Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Date:   Mon, 18 Feb 2019 08:58:51 +0100
From:   Johan Hovold <johan@kernel.org>
To:     Nix <nix@esperi.org.uk>
Cc:     Greg KH <greg@kroah.com>, johan@kernel.org,
        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)
Message-ID: <20190218075851.GA4072@localhost>
References: <87o97bu2bt.fsf@esperi.org.uk>
 <20190216194758.GA10756@kroah.com>
 <877edytehb.fsf@esperi.org.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <877edytehb.fsf@esperi.org.uk>
User-Agent: Mutt/1.11.3 (2019-02-01)
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Sun, Feb 17, 2019 at 07:13:52PM +0000, Nix wrote:
> On 16 Feb 2019, Greg KH told this:
> 
> > On Sat, Feb 16, 2019 at 04:26:30PM +0000, Nix wrote:
> >> So I just tried to connect up to my ancient Soekris firewall's serial
> >> console to try to bisect a problem where it stopped booting in 4.20, and
> >> found I couldn't.
> >> 
> >> minicom says:
> >> 
> >> minicom: cannot open /dev/ttyUSB0: Input/output error
> >> 
> >> and in the dmesg we see
> >> 
> >> [705576.028170] pl2303 ttyUSB0: failed to submit interrupt urb: -28
> >>
> >> Booting to 4.19, everything works fine. (A random GalliumOS Chromebook
> [...]
> >
> > bisection would be great, thanks!
> 
> Rrrg. This is going to be harder than I thought. Rebooting, everything
> works fine! So this is something that kicks in after something less than
> eight days uptime, consistently on every box I own, but is fine on
> reboot.

Tough one.

> 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.

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).

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).

Johan