I've had some reports of the smsc95xx driver failing to work for the
ODROID-X2 and ODROID-U3 since a049a30fc27c was merged (also backported
to 5.15.y stable branch, which I believe is what those affected by this
are using).
Since then we have performed a number of tests, here's what we've found
so far:
ODROID-U3 (built-in LAN9730):
- No errors reported from smsc95xx driver, however networking broken
(can not perform DHCP via NetworkManager, Fedora user space).
- Networking starts working if device forced into promiscuous mode
(Gabriel noticed this whilst running tcpdump)
ODROID-X2 (built in LAN9514):
- Networking not brought up (Using Debian Buster and Bullseye with
traditional `/etc/network/interfaces` approach).
- As with Odroid-u3, works when running in promiscuous mode.
OrangePi Zero with LAN9500A EVK:
- Network works fine. Interface can be taken up and down, cable
unplugged and replugged, network continues to work (Debian based
user space).
Raspberry Pi 1 rev 2 (built-in LAN9512):
- Network works fine. (Raspberry OS user space)
Raspberry Pi 2 (built-in LAN9514):
- Booting with DHCP performed by kernel, appears to be working:
https://lava.collabora.co.uk/scheduler/job/5240174
- Tested in LAVA (traditional `/etc/network/interfaces` approach),
networking appears to be working:
https://lava.collabora.co.uk/scheduler/job/5247952
- It has been noted that U-Boot uses this device during boot, which
may be having an impact, however the driver appears to be resetting
the chip at device bind. Have not been able to replicate this on the
ODROID-X2 (U-boot environment there doesn't have the network
driver). This is interesting as the Raspberry Pi 2 and ODROID-X2
appear to have the same device, yet ones working and the other
isn't.
Not sure how to approach this now, I've yet to find a device I have
access to that is impacted by this issue.
Martyn
From: Andrew Lunn <andrew@lunn.ch> Date: 2021-12-18 16:45:16
On Fri, Dec 17, 2021 at 03:45:08PM +0000, Martyn Welch wrote:
I've had some reports of the smsc95xx driver failing to work for the
ODROID-X2 and ODROID-U3 since a049a30fc27c was merged (also backported
to 5.15.y stable branch, which I believe is what those affected by this
are using).
Since then we have performed a number of tests, here's what we've found
so far:
ODROID-U3 (built-in LAN9730):
- No errors reported from smsc95xx driver, however networking broken
(can not perform DHCP via NetworkManager, Fedora user space).
- Networking starts working if device forced into promiscuous mode
(Gabriel noticed this whilst running tcpdump)
ODROID-X2 (built in LAN9514):
- Networking not brought up (Using Debian Buster and Bullseye with
traditional `/etc/network/interfaces` approach).
- As with Odroid-u3, works when running in promiscuous mode.
Hi Martyn
Promisc mode is really odd, given what
commit a049a30fc27c1cb2e12889bbdbd463dbf750103a
Author: Martyn Welch [off-list ref]
Date: Mon Nov 22 18:44:45 2021 +0000
net: usb: Correct PHY handling of smsc95xx
does. Has it been confirmed this is really the patch which causes
the problem?
Does mii-tool -vvv how any difference between the working and broken
case?
Can you also confirm the same PHY driver is used before/after this
patch. There is a chance one is using a specific PHY driver and the
other genphy.
Andrew
From: Gabriel Hojda <hidden> Date: 2021-12-18 17:38:38
On 2021-12-18 18:45, Andrew Lunn wrote:
On Fri, Dec 17, 2021 at 03:45:08PM +0000, Martyn Welch wrote:
quoted
I've had some reports of the smsc95xx driver failing to work for the
ODROID-X2 and ODROID-U3 since a049a30fc27c was merged (also backported
to 5.15.y stable branch, which I believe is what those affected by this
are using).
Since then we have performed a number of tests, here's what we've found
so far:
ODROID-U3 (built-in LAN9730):
- No errors reported from smsc95xx driver, however networking broken
(can not perform DHCP via NetworkManager, Fedora user space).
- Networking starts working if device forced into promiscuous mode
(Gabriel noticed this whilst running tcpdump)
ODROID-X2 (built in LAN9514):
- Networking not brought up (Using Debian Buster and Bullseye with
traditional `/etc/network/interfaces` approach).
- As with Odroid-u3, works when running in promiscuous mode.
Hi Martyn
Promisc mode is really odd, given what
commit a049a30fc27c1cb2e12889bbdbd463dbf750103a
Author: Martyn Welch [off-list ref]
Date: Mon Nov 22 18:44:45 2021 +0000
net: usb: Correct PHY handling of smsc95xx
does. Has it been confirmed this is really the patch which causes
the problem?
Does mii-tool -vvv how any difference between the working and broken
case?
Can you also confirm the same PHY driver is used before/after this
patch. There is a chance one is using a specific PHY driver and the
other genphy.
Andrew
hi Andrew,
on my odroid-u3, with all kernel versions since 5.15.6 (where the patch was applied) and also with 5.16.y if tcpdump is running the network works. when tcpdump process is killed/stopped, networking stops working.
1. as a test that this is the offending patch, i've recompiled the fedora kernel 5.15.7 with the patch reverted and everything was working normally as it last worked with 5.15.5
2.1. kernel 5.15.5 - "mii-tool -vvv eth0"
Using SIOCGMIIPHY=0x8947
eth0: negotiated 1000baseT-HD flow-control, link ok
registers for MII PHY 1:
3100 782d 0007 c101 01e1 45e1 0001 ffff
ffff ffff ffff ffff ffff 0000 0000 0000
0040 0002 00e1 ffff 0000 0000 0000 0000
0b9d 0000 0000 000a 0000 00c8 0000 1058
product info: vendor 00:01:f0, model 16 rev 1
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
2.2. kernel 5.15.8 - "mii-tool -vvv eth0"
Using SIOCGMIIPHY=0x8947
eth0: negotiated 1000baseT-HD flow-control, link ok
registers for MII PHY 1:
3100 782d 0007 c101 01e1 45e1 0003 ffff
ffff ffff ffff ffff ffff 0000 0000 0000
0040 0002 00e1 ffff 0000 0000 0000 0000
0b9d 0000 0000 000a 0000 00c8 0000 1058
product info: vendor 00:01:f0, model 16 rev 1
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
3.1 kernel 5.15.5 - "dmesg | grep -i phy"
[ 0.000000] Booting Linux on physical CPU 0xa00
[ 0.000000] GIC physical location is 0x10490000
[ 2.290065] libphy: Fixed MDIO Bus: probed
[ 6.763235] samsung-usb2-phy 125b0000.exynos-usbphy: supply vbus not found, using dummy regulator
[ 8.045968] libphy: smsc95xx-mdiobus: probed
[ 23.261816] Generic PHY usb-001:002:01: attached PHY driver (mii_bus:phy_addr=usb-001:002:01, irq=POLL)
3.1 kernel 5.15.8 - "dmesg | grep -i phy"
[ 0.000000] Booting Linux on physical CPU 0xa00
[ 0.000000] GIC physical location is 0x10490000
[ 3.291292] libphy: Fixed MDIO Bus: probed
[ 10.198145] samsung-usb2-phy 125b0000.exynos-usbphy: supply vbus not found, using dummy regulator
[ 11.740943] libphy: smsc95xx-mdiobus: probed
[ 11.742916] Generic PHY usb-001:002:01: attached PHY driver (mii_bus:phy_addr=usb-001:002:01, irq=POLL)
From: Andrew Lunn <andrew@lunn.ch> Date: 2021-12-18 18:22:29
hi Andrew,
on my odroid-u3, with all kernel versions since 5.15.6 (where the patch was
applied) and also with 5.16.y if tcpdump is running the network works. when
tcpdump process is killed/stopped, networking stops working.
O.K, thanks for confirming this. It is a clue to the problem, but i
have 0 idea what it actually means, yet.
2.1. kernel 5.15.5 - "mii-tool -vvv eth0"
Using SIOCGMIIPHY=0x8947
eth0: negotiated 1000baseT-HD flow-control, link ok
registers for MII PHY 1:
3100 782d 0007 c101 01e1 45e1 0001 ffff
ffff ffff ffff ffff ffff 0000 0000 0000
0040 0002 00e1 ffff 0000 0000 0000 0000
0b9d 0000 0000 000a 0000 00c8 0000 1058
product info: vendor 00:01:f0, model 16 rev 1
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
2.2. kernel 5.15.8 - "mii-tool -vvv eth0"
Using SIOCGMIIPHY=0x8947
eth0: negotiated 1000baseT-HD flow-control, link ok
registers for MII PHY 1:
3100 782d 0007 c101 01e1 45e1 0003 ffff
^ 3 vs 1.
but otherwise, they look the same. And it has completed autoneg, and
got the same results. So i would say, the PHY is not the problem, it
is a MAC problem.
genphy for both.
O.K, stab in the dark. Does the hardware need to be programmed with
the MAC address? When does this happen? If this is going wrong, it
could explain the promisc mode. If the MAC address has not been
programmed, it has no idea what packets are for itself. Put it into
promisc mode, and it will receive everything, including what it is
supposed to receive. But looking at the offending patch, it is not
obvious how it has anything to do with MAC addresses. The only
unbalanced change in that patch is that smsc95xx_reset(dev) has
disappeared, not moved to somewhere else.
Andrew
From: Andrew Lunn <andrew@lunn.ch> Date: 2021-12-18 18:32:50
O.K, stab in the dark. Does the hardware need to be programmed with
the MAC address? When does this happen? If this is going wrong, it
could explain the promisc mode. If the MAC address has not been
programmed, it has no idea what packets are for itself. Put it into
promisc mode, and it will receive everything, including what it is
supposed to receive. But looking at the offending patch, it is not
obvious how it has anything to do with MAC addresses. The only
unbalanced change in that patch is that smsc95xx_reset(dev) has
disappeared, not moved to somewhere else.
Ah!
smsc95xx_reset() calls smsc95xx_set_mac_address(). So that fits.
smsc95xx_reset() is also called in smsc95xx_bind(), but maybe that is
not enough?
Andrew
From: Gabriel Hojda <hidden> Date: 2021-12-18 20:48:40
On 2021-12-18 20:32, Andrew Lunn wrote:
quoted
O.K, stab in the dark. Does the hardware need to be programmed with
the MAC address? When does this happen? If this is going wrong, it
could explain the promisc mode. If the MAC address has not been
programmed, it has no idea what packets are for itself. Put it into
promisc mode, and it will receive everything, including what it is
supposed to receive. But looking at the offending patch, it is not
obvious how it has anything to do with MAC addresses. The only
unbalanced change in that patch is that smsc95xx_reset(dev) has
disappeared, not moved to somewhere else.
Ah!
smsc95xx_reset() calls smsc95xx_set_mac_address(). So that fits.
smsc95xx_reset() is also called in smsc95xx_bind(), but maybe that is
not enough?
Andrew
hi Andrew,
the odroid-u3 has no preconfigured mac address. the kernel from the vendor is patched to read a file in /etc and set the mac address read from it. with the mainline kernel the interface gets a random mac address that can later be changed by NetworkManager & Co. (as far as i know there's no "smsc95xx.macaddr=xx:xx:xx:xx:xx:xx" kernel boot parameter).
u-boot should be able to set the mac addreess, but it doesn't even detect the network interface and i get a message like "No NET interface" (even though i've tried the steps at https://github.com/ARM-software/u-boot/blob/master/doc/README.odroid).
Gabriel
From: Markus Reichl <hidden> Date: 2021-12-20 11:17:35
Am 18.12.21 um 21:33 schrieb Gabriel Hojda:
On 2021-12-18 20:32, Andrew Lunn wrote:
quoted
quoted
O.K, stab in the dark. Does the hardware need to be programmed with
the MAC address? When does this happen? If this is going wrong, it
could explain the promisc mode. If the MAC address has not been
programmed, it has no idea what packets are for itself. Put it into
promisc mode, and it will receive everything, including what it is
supposed to receive. But looking at the offending patch, it is not
obvious how it has anything to do with MAC addresses. The only
unbalanced change in that patch is that smsc95xx_reset(dev) has
disappeared, not moved to somewhere else.
Ah!
smsc95xx_reset() calls smsc95xx_set_mac_address(). So that fits.
smsc95xx_reset() is also called in smsc95xx_bind(), but maybe that is
not enough?
Andrew
hi Andrew,
the odroid-u3 has no preconfigured mac address. the kernel from the vendor is patched to read a file in /etc and set the mac address read from it. with the mainline kernel the interface gets a random mac address that can later be changed by NetworkManager & Co. (as far as i know there's no "smsc95xx.macaddr=xx:xx:xx:xx:xx:xx" kernel boot parameter).
u-boot should be able to set the mac addreess, but it doesn't even detect the network interface and i get a message like "No NET interface" (even though i've tried the steps at https://github.com/ARM-software/u-boot/blob/master/doc/README.odroid).
Gabriel
Hi,
same issue on odroid-x2 which has no preconfigured mac address either.
I use plain Debian buster and bullseye with traditional
/etc/network/interfaces
auto eth0
allow-hotplug eth0
iface eth0 inet dhcp
hwaddress ether c2:c5:aa:9e:aa:55
iface eth0 inet6 dhcp
Gruß,
--
Markus Reichl