[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20220825042106.GA16015@wunner.de>
Date: Thu, 25 Aug 2022 06:21:06 +0200
From: Lukas Wunner <lukas@...ner.de>
To: Mark Brown <broonie@...nel.org>
Cc: Oleksij Rempel <o.rempel@...gutronix.de>,
Ferry Toth <fntoth@...il.com>, Andrew Lunn <andrew@...n.ch>,
Andre Edich <andre.edich@...rochip.com>,
"David S. Miller" <davem@...emloft.net>,
Sasha Levin <sashal@...nel.org>, kernelci-results@...ups.io,
bot@...nelci.org, gtucker@...labora.com, stable@...r.kernel.org,
netdev@...r.kernel.org, linux-omap@...r.kernel.org
Subject: Re: stable-rc/linux-5.18.y bisection: baseline.login on panda
On Wed, Aug 24, 2022 at 11:47:03PM +0100, Mark Brown wrote:
> On Wed, Aug 24, 2022 at 01:22:12PM -0700, KernelCI bot wrote:
> The KernelCI bisection bot identified 7eea9a60703ca ("usbnet: smsc95xx:
> Forward PHY interrupts to PHY driver to avoid polling") as causing a
> boot regression on Panda in v5.18. The board stops detecting a link
> which breks NFS boot:
>
> <6>[ 4.953613] smsc95xx 2-1.1:1.0 eth0: register 'smsc95xx' at usb-4a064c00.ehci-1.1, smsc95xx USB 2.0 Ethernet, 02:03:01:8c:13:b0
> <6>[ 5.032928] smsc95xx 2-1.1:1.0 eth0: hardware isn't capable of remote wakeup
> <6>[ 5.044036] smsc95xx 2-1.1:1.0 eth0: Link is Down
> <6>[ 25.053924] Waiting up to 100 more seconds for network.
> <6>[ 45.074005] Waiting up to 80 more seconds for network.
> <6>[ 65.093933] Waiting up to 60 more seconds for network.
> <6>[ 85.123992] Waiting up to 40 more seconds for network.
> <6>[ 105.143951] Waiting up to 20 more seconds for network.
> <5>[ 125.084014] Sending DHCP requests ...... timed out!
Looks like v5.19 boots fine (with the offending commit), so only
v5.18-stable and v5.15-stable are affected:
https://storage.kernelci.org/stable-rc/linux-5.19.y/v5.19.3-366-g32f80a5b58e2/arm/multi_v7_defconfig/gcc-10/lab-baylibre/baseline-panda.html
The offending commit was a new feature introduced in v5.19,
it deliberately wasn't tagged for stable. Aggressively
backporting such new features always carries a risk of
regressions.
Off the cuff I don't see that a prerequisite commit is missing
in stable kernels. So just reverting the offending commit in
v5.18-stable and v5.15-stable (but not in v5.19-stable) might
be the simplest solution.
Thanks,
Lukas
Powered by blists - more mailing lists