Network not working after updating to 5.15.61

[jaketri]

Describe the bug

Network does not work on Raspberry Pi 2 and 3 after updating kernel from 5.15.56 to 5.15.61

I notice kernel patch for 5.15.61 have changes to smsc95xx driver ... Not sure if that is the root cause but look suspicious coincidence.

Steps to reproduce the behaviour

Install 5.15.61 kernel on RPi2 or RPi3 and notice LAN not working.

Device (s)

Raspberry Pi 2 Mod. B, Raspberry Pi 3 Mod. B

System

Using Arch Linux ARM

rpi2b ~ # vcgencmd version
Aug 23 2022 14:24:57
Copyright (c) 2012 Broadcom
version bf881c824bac214626a9f78094d614f7db462c34 (clean) (release) (start)
rpi2b ~ # uname -a
Linux rpi2b 5.15.61-1-rpi-ARCH #1 SMP Tue Aug 23 13:21:13 MDT 2022 armv7l GNU/Linux

Logs

No response

Additional context

No response

[bittin]

i have the same problem with Raspberry Pi OS on a Pi 3

[stevegk]

Just built 5.15.60 using tag a309898 on Arch and it works OK for me on a Pi 2 rev 1.1. 5.15.61 based on tag e1f6a09 doesn't.

[rien333]

For the record: this only affects networking through eth0, not through wlan0.

Relevant forum issue: https://archlinuxarm.org/forum/viewtopic.php?f=65&t=16149

[jlabundy]

Hi there—just chiming in to report the same issue after moving from 5.15.56 to 5.15.61 as well.

[semeion]

Yeah, i can confirm this issue.

I had same issue after update my RPI3 Archlinux-ARM from 5.15.56 to 5.15.61

[JackMauro]

Same issue with Raspbian GNU/Linux 11 (bullseye), upgrading from 5.15.32-v7+ to 5.15.61 on raspberry 3b.

[jaketri]

Just built 5.15.60 using tag a309898 on Arch and it works OK for me on a Pi 2 rev 1.1. 5.15.61 based on tag e1f6a09 doesn't.

To check if my original suspicion was correct, I build 5.15.61 kernel from tag e1f6a09 but patch in the old drivers/net/usb/smsc95xx.c file from 5.15.60 tag a309898 ...

Sorry for my delayed update but It took me almost a full day to finish the build ....

Anyway, surprise surprise !!! ... LAN is working fine with the Frankenstein kernel build using 5.15.61 with old drivers/net/usb/smsc95xx.c file!

[pelwell]

I can confirm that the onboard Ethernet is non-functional on a 3B with 5.15.61 - the link is shown as being down. Reverting the two most recent commits to drivers/net/usb/smsc95xx.c (b574d1e and eaf3a09 ) restores the connectivity. ( Full disclosure - I'm testing on the downstream branch rpi-5.16.y, but I don't think there are significant differences in this area. )

Any suggestions, @l1k?

[pelwell]

Unsurprisingly the PHY is still detecting link changes, but the 95xx driver is unaware of them because it is no longer polling and apparently not receiving an interrupt of any kind.

Unplugged:

$ sudo mii-tool -v eth0
eth0: no link
  product info: vendor 00:80:0f or 00:01:f0, model 12 rev 3
  basic mode:   autonegotiation enabled
  basic status: no link
  capabilities: 1000baseT-HD 1000baseT-FD 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD
  advertising:  1000baseT-HD 1000baseT-FD 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD
  link partner: 1000baseT-HD 1000baseT-FD 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD flow-control

Connected:

$ sudo mii-tool -v eth0
eth0: negotiated 1000baseT-HD flow-control, link ok
  product info: vendor 00:80:0f or 00:01:f0, model 12 rev 3
  basic mode:   autonegotiation enabled
  basic status: autonegotiation complete, link ok
  capabilities: 1000baseT-HD 1000baseT-FD 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD
  advertising:  1000baseT-HD 1000baseT-FD 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD
  link partner: 1000baseT-HD 1000baseT-FD 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD flow-control
~$ ifconfig eth0
eth0: flags=4099<UP,BROADCAST,MULTICAST>  mtu 1500
        ether b8:27:ec:23:45:67  txqueuelen 1000  (Ethernet)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 0  bytes 0 (0.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

[l1k]

This was also reported by Mark Brown the other day:
https://lore.kernel.org/all/[email protected]/

TL;DR: The feature shouldn't have been backported to stable kernels. Way too risky. Stable maintainers backported it even though it wasn't tagged for stable. I'd suggest reverting it in the downstream tree until stable maintainers revert it. The feature is working fine in v5.19, but I'd advise against using it on older kernels for now. There have been a lot of changes in the various drivers involved and it's difficult to figure out what's missing.

[pelwell]

Understood - thanks for the quick response.

[pelwell]

The back-ports to 5.15 and 5.18 have been reverted.

[bittin]

Great, downgrading my Pi3 :)

[popcornmix]

rpi-update kernel has been updated with reverted kernel commits.

[bittin]

perfect, thx @popcornmix

[l1k]

I've asked Sasha and Greg for a revert in 5.15-stable and 5.18-stable:

https://lore.kernel.org/netdev/[email protected]/

[pelwell]

They can hardly say no...

[bittin]

thanks for fixing it downstream and working on fixing it upstream too

[jaketri]

Thank you for the quick fix!