* Issues with smsc95xx driver since a049a30fc27c
@ 2021-12-17 15:45 Martyn Welch
2021-12-18 16:45 ` Andrew Lunn
0 siblings, 1 reply; 10+ messages in thread
From: Martyn Welch @ 2021-12-17 15:45 UTC (permalink / raw)
To: netdev
Cc: Krzysztof Kozlowski, Marek Szyprowski, Gabriel Hojda,
Markus Reichl, Steve Glendinning, UNGLinuxDriver,
David S. Miller, Jakub Kicinski, stable
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
^ permalink raw reply [flat|nested] 10+ messages in thread* Re: Issues with smsc95xx driver since a049a30fc27c
2021-12-17 15:45 Issues with smsc95xx driver since a049a30fc27c Martyn Welch
@ 2021-12-18 16:45 ` Andrew Lunn
2021-12-18 17:23 ` Gabriel Hojda
0 siblings, 1 reply; 10+ messages in thread
From: Andrew Lunn @ 2021-12-18 16:45 UTC (permalink / raw)
To: Martyn Welch
Cc: netdev, Krzysztof Kozlowski, Marek Szyprowski, Gabriel Hojda,
Markus Reichl, Steve Glendinning, UNGLinuxDriver,
David S. Miller, Jakub Kicinski, stable
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 <martyn.welch@collabora.com>
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
^ permalink raw reply [flat|nested] 10+ messages in thread* Re: Issues with smsc95xx driver since a049a30fc27c
2021-12-18 16:45 ` Andrew Lunn
@ 2021-12-18 17:23 ` Gabriel Hojda
2021-12-18 18:22 ` Andrew Lunn
0 siblings, 1 reply; 10+ messages in thread
From: Gabriel Hojda @ 2021-12-18 17:23 UTC (permalink / raw)
To: Andrew Lunn
Cc: Martyn Welch, netdev, Krzysztof Kozlowski, Marek Szyprowski,
Markus Reichl, Steve Glendinning, UNGLinuxDriver,
David S. Miller, Jakub Kicinski, stable
On 2021-12-18 18:45, Andrew Lunn wrote:
> 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 <martyn.welch@collabora.com>
> 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)
^ permalink raw reply [flat|nested] 10+ messages in thread* Re: Issues with smsc95xx driver since a049a30fc27c
2021-12-18 17:23 ` Gabriel Hojda
@ 2021-12-18 18:22 ` Andrew Lunn
2021-12-18 18:32 ` Andrew Lunn
0 siblings, 1 reply; 10+ messages in thread
From: Andrew Lunn @ 2021-12-18 18:22 UTC (permalink / raw)
To: Gabriel Hojda
Cc: Martyn Welch, netdev, Krzysztof Kozlowski, Marek Szyprowski,
Markus Reichl, Steve Glendinning, UNGLinuxDriver,
David S. Miller, Jakub Kicinski, stable
> 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.
> [ 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"
>
> [ 11.742916] Generic PHY usb-001:002:01: attached PHY driver
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
^ permalink raw reply [flat|nested] 10+ messages in thread* Re: Issues with smsc95xx driver since a049a30fc27c
2021-12-18 18:22 ` Andrew Lunn
@ 2021-12-18 18:32 ` Andrew Lunn
2021-12-18 20:33 ` Gabriel Hojda
[not found] ` <c95954ec12dfcf8877c1bf92047c0268@yo2urs.ro>
0 siblings, 2 replies; 10+ messages in thread
From: Andrew Lunn @ 2021-12-18 18:32 UTC (permalink / raw)
To: Gabriel Hojda
Cc: Martyn Welch, netdev, Krzysztof Kozlowski, Marek Szyprowski,
Markus Reichl, Steve Glendinning, UNGLinuxDriver,
David S. Miller, Jakub Kicinski, stable
> 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
^ permalink raw reply [flat|nested] 10+ messages in thread* Re: Issues with smsc95xx driver since a049a30fc27c
2021-12-18 18:32 ` Andrew Lunn
@ 2021-12-18 20:33 ` Gabriel Hojda
2021-12-20 10:37 ` Markus Reichl
[not found] ` <c95954ec12dfcf8877c1bf92047c0268@yo2urs.ro>
1 sibling, 1 reply; 10+ messages in thread
From: Gabriel Hojda @ 2021-12-18 20:33 UTC (permalink / raw)
To: Andrew Lunn
Cc: Martyn Welch, netdev, Krzysztof Kozlowski, Marek Szyprowski,
Markus Reichl, Steve Glendinning, UNGLinuxDriver,
David S. Miller, Jakub Kicinski, stable
On 2021-12-18 20:32, Andrew Lunn wrote:
>> 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
^ permalink raw reply [flat|nested] 10+ messages in thread* Re: Issues with smsc95xx driver since a049a30fc27c
2021-12-18 20:33 ` Gabriel Hojda
@ 2021-12-20 10:37 ` Markus Reichl
0 siblings, 0 replies; 10+ messages in thread
From: Markus Reichl @ 2021-12-20 10:37 UTC (permalink / raw)
To: Gabriel Hojda, Andrew Lunn
Cc: Martyn Welch, netdev, Krzysztof Kozlowski, Marek Szyprowski,
Steve Glendinning, UNGLinuxDriver, David S. Miller,
Jakub Kicinski, stable
Am 18.12.21 um 21:33 schrieb Gabriel Hojda:
> On 2021-12-18 20:32, Andrew Lunn wrote:
>>> 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
^ permalink raw reply [flat|nested] 10+ messages in thread
[parent not found: <c95954ec12dfcf8877c1bf92047c0268@yo2urs.ro>]
* Re: Issues with smsc95xx driver since a049a30fc27c
[not found] ` <c95954ec12dfcf8877c1bf92047c0268@yo2urs.ro>
@ 2021-12-20 8:53 ` Andrew Lunn
2021-12-20 20:04 ` Gabriel Hojda
2021-12-20 21:28 ` Gabriel Hojda
0 siblings, 2 replies; 10+ messages in thread
From: Andrew Lunn @ 2021-12-20 8:53 UTC (permalink / raw)
To: Gabriel Hojda; +Cc: Martyn Welch, netdev
> # ip link set eth0 up
> # ip link show eth0
> 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP
> mode DEFAULT group default qlen 1000
> link/ether ee:f1:a8:e7:0c:8f brd ff:ff:ff:ff:ff:ff
>
> ... now link is up with the same mac address
>
> # ifconfig eth0
> eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
> inet6 2a02:2f09:3d09:1b00:ecf1:a8ff:fee7:c8f prefixlen 64 scopeid
> 0x0<global>
> inet6 fe80::ecf1:a8ff:fee7:c8f prefixlen 64 scopeid 0x20<link>
> inet6 fd00:cafe::c772:d58f:1061:4df3 prefixlen 64 scopeid
> 0x0<global>
> inet6 fd00:cafe::ecf1:a8ff:fee7:c8f prefixlen 64 scopeid
> 0x0<global>
> inet6 2a02:2f09:3d09:1b00:eef4:bb1d:f9d5:febc prefixlen 64 scopeid
> 0x0<global>
These make use of multicast. Router Advertisements are multicast, both
at L2 and L3, by the router to the Internet.
> # ping -6 -c 10 ipv6.l.google.com
> PING ipv6.l.google.com(ipv6.l.google.com (2a00:1450:400d:806::200e)) 56 data
> bytes
> From odroid (2a02:2f09:3d09:1b00:eef4:bb1d:f9d5:febc) icmp_seq=1 Destination
> unreachable: Address unreachable
> ...
> --- ipv6.l.google.com ping statistics ---
> 10 packets transmitted, 0 received, +7 errors, 100% packet loss, time 9311ms
ping uses unicast.
> ... neither does it work for my local router, so network layer 3 does not
> seem to work
I think it is still pointing towards L2 unicast.
> next, when i have time and if there's still no progress, i think i should
> try to insert:
>
> ret = smsc95xx_reset(dev);
> if (ret)
> goto free_pdata;
>
> before
>
> ret = phy_connect_direct(dev->net, pdata->phydev,
> &smsc95xx_handle_link_change,
> PHY_INTERFACE_MODE_MII);
>
> in smsc95xx_bind() to try to emulate the old behavior for the first call to
> start_phy().
Yes, that will be in interesting experiment. Something in
smsc95xx_reset() is required.
Andrew
^ permalink raw reply [flat|nested] 10+ messages in thread* Re: Issues with smsc95xx driver since a049a30fc27c
2021-12-20 8:53 ` Andrew Lunn
@ 2021-12-20 20:04 ` Gabriel Hojda
2021-12-20 21:28 ` Gabriel Hojda
1 sibling, 0 replies; 10+ messages in thread
From: Gabriel Hojda @ 2021-12-20 20:04 UTC (permalink / raw)
To: Andrew Lunn; +Cc: Martyn Welch, netdev
[-- Attachment #1: Type: text/plain, Size: 2627 bytes --]
On 2021-12-20 10:53, Andrew Lunn wrote:
>> # ip link set eth0 up
>> # ip link show eth0
>> 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel
>> state UP
>> mode DEFAULT group default qlen 1000
>> link/ether ee:f1:a8:e7:0c:8f brd ff:ff:ff:ff:ff:ff
>>
>> ... now link is up with the same mac address
>>
>> # ifconfig eth0
>> eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
>> inet6 2a02:2f09:3d09:1b00:ecf1:a8ff:fee7:c8f prefixlen 64
>> scopeid
>> 0x0<global>
>> inet6 fe80::ecf1:a8ff:fee7:c8f prefixlen 64 scopeid
>> 0x20<link>
>> inet6 fd00:cafe::c772:d58f:1061:4df3 prefixlen 64 scopeid
>> 0x0<global>
>> inet6 fd00:cafe::ecf1:a8ff:fee7:c8f prefixlen 64 scopeid
>> 0x0<global>
>> inet6 2a02:2f09:3d09:1b00:eef4:bb1d:f9d5:febc prefixlen 64
>> scopeid
>> 0x0<global>
>
> These make use of multicast. Router Advertisements are multicast, both
> at L2 and L3, by the router to the Internet.
>
>> # ping -6 -c 10 ipv6.l.google.com
>> PING ipv6.l.google.com(ipv6.l.google.com (2a00:1450:400d:806::200e))
>> 56 data
>> bytes
>> From odroid (2a02:2f09:3d09:1b00:eef4:bb1d:f9d5:febc) icmp_seq=1
>> Destination
>> unreachable: Address unreachable
>> ...
>> --- ipv6.l.google.com ping statistics ---
>> 10 packets transmitted, 0 received, +7 errors, 100% packet loss, time
>> 9311ms
>
> ping uses unicast.
>
>> ... neither does it work for my local router, so network layer 3 does
>> not
>> seem to work
>
> I think it is still pointing towards L2 unicast.
>
>> next, when i have time and if there's still no progress, i think i
>> should
>> try to insert:
>>
>> ret = smsc95xx_reset(dev);
>> if (ret)
>> goto free_pdata;
>>
>> before
>>
>> ret = phy_connect_direct(dev->net, pdata->phydev,
>> &smsc95xx_handle_link_change,
>> PHY_INTERFACE_MODE_MII);
>>
>> in smsc95xx_bind() to try to emulate the old behavior for the first
>> call to
>> start_phy().
>
> Yes, that will be in interesting experiment. Something in
> smsc95xx_reset() is required.
>
> Andrew
well, i recompiled 5.15.10 with that change and network is still not
working. then i disabled NetworkManager and rebooted. after boot i
issued following commands:
# ethtool -d eth0
# ip link set dev eth0 up
# ethtool -d eth0
for 5.15.5 (working kernel), 5.15.8 (unmodified, not working kernel),
5.15.10 (modified as above, not working kernel).
obviously, in these register dumps there are 3 different mac addresses
(8 bytes at offset 0x0104) ... but the rest could provide a clue (for
someone who can make sense of those values).
Gabriel
[-- Attachment #2: 5.15.5-test.txt --]
[-- Type: text/plain, Size: 2370 bytes --]
# ethtool -d eth0
Offset Values
------ ------
0x0000: 00 00 30 97 00 00 00 00 00 00 00 00 00 00 00 00
0x0010: 04 00 00 00 22 14 00 00 00 00 00 00 00 20 00 00
0x0020: 80 00 00 00 00 00 11 01 8f 00 00 ff a1 30 f8 00
0x0030: 00 00 00 00 00 00 00 00 25 00 00 00 50 00 00 00
0x0040: 00 00 00 80 00 00 00 00 00 00 00 00 00 00 00 00
0x0050: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0060: 00 00 00 00 00 00 00 00 00 80 00 00 00 20 00 00
0x0070: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0080: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0090: 00 00 00 00 01 00 00 00 00 00 00 00 00 00 00 00
0x00a0: 00 00 04 00 00 00 01 00 00 00 00 00 00 00 00 00
0x00b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x00c0: 00 00 00 00 1e 00 00 00 00 00 00 00 00 00 00 00
0x00d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x00e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x00f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0100: 0c 00 00 00 bd 89 00 00 ee 97 78 58 00 00 00 00
0x0110: 00 00 00 00 c0 08 00 00 01 c1 00 00 00 00 00 00
0x0120: 00 81 00 00 ff ff 00 00 00 00 00 00 00 00 00 00
0x0130: 01 00 01 00
# ip link set dev eth0 up
# ethtool -d eth0
Offset Values
------ ------
0x0000: 00 00 30 97 00 00 00 00 00 00 00 00 00 00 00 00
0x0010: 04 00 00 00 22 14 00 00 00 00 00 00 00 20 00 00
0x0020: 80 00 00 00 00 00 11 01 8f 00 00 ff a1 30 f8 00
0x0030: 00 00 00 00 00 00 00 00 25 00 00 00 50 00 00 00
0x0040: 00 00 00 80 00 00 00 00 00 00 00 00 00 00 00 00
0x0050: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0060: 00 00 00 00 00 00 00 00 00 80 00 00 00 20 00 00
0x0070: 00 00 00 00 3d 00 3d 00 00 00 00 00 59 01 59 01
0x0080: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0090: 00 00 00 00 01 00 00 00 00 00 00 00 00 00 00 00
0x00a0: 00 00 04 00 00 00 01 00 00 00 00 00 00 00 00 00
0x00b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x00c0: 00 00 00 00 1e 00 00 00 00 00 00 00 00 00 00 00
0x00d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x00e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x00f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0100: 0c 20 00 00 0c 8f 00 00 ee f1 a8 e7 00 00 40 40
0x0110: 02 01 04 80 40 08 00 00 2d 78 00 00 00 00 00 00
0x0120: 00 81 00 00 ff ff 00 00 00 00 00 00 00 00 00 00
0x0130: 01 00 01 00
[-- Attachment #3: 5.15.8-test.txt --]
[-- Type: text/plain, Size: 2370 bytes --]
# ethtool -d eth0
Offset Values
------ ------
0x0000: 00 00 30 97 00 00 00 00 00 00 00 00 00 00 00 00
0x0010: 04 00 00 00 22 14 00 00 00 00 00 00 00 20 00 00
0x0020: 80 00 00 00 00 00 11 01 8f 00 00 ff a1 30 f8 00
0x0030: 00 00 00 00 00 00 00 00 25 00 00 00 50 00 00 00
0x0040: 00 00 00 80 00 00 00 00 00 00 00 00 00 00 00 00
0x0050: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0060: 00 00 00 00 00 00 00 00 00 80 00 00 00 20 00 00
0x0070: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0080: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0090: 00 00 00 00 01 00 00 00 00 00 00 00 00 00 00 00
0x00a0: 00 00 04 00 00 00 01 00 00 00 00 00 00 00 00 00
0x00b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x00c0: 00 00 00 00 1e 00 00 00 00 00 00 00 00 00 00 00
0x00d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x00e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x00f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0100: 0c 00 00 00 23 84 00 00 12 a8 1c 00 00 00 00 00
0x0110: 00 00 00 00 00 08 00 00 00 30 00 00 00 00 00 00
0x0120: 00 81 00 00 ff ff 00 00 00 00 00 00 00 00 00 00
0x0130: 01 00 01 00
# ip link set dev eth0 up
# ethtool -d eth0
Offset Values
------ ------
0x0000: 00 00 30 97 00 00 00 00 00 00 00 00 00 00 00 00
0x0010: 04 00 00 00 22 14 00 00 00 00 00 00 00 20 00 00
0x0020: 80 00 00 00 00 00 11 01 8f 00 00 ff a1 30 f8 00
0x0030: 00 00 00 00 00 00 00 00 25 00 00 00 50 00 00 00
0x0040: 00 00 00 80 00 00 00 00 00 00 00 00 00 00 00 00
0x0050: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0060: 00 00 00 00 00 00 00 00 00 80 00 00 00 20 00 00
0x0070: 00 00 00 00 00 00 00 00 00 00 00 00 03 01 03 01
0x0080: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0090: 00 00 00 00 01 00 00 00 00 00 00 00 00 00 00 00
0x00a0: 00 00 04 00 00 00 01 00 00 00 00 00 00 00 00 00
0x00b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x00c0: 00 00 00 00 1e 00 00 00 00 00 00 00 00 00 00 00
0x00d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x00e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x00f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0100: 0c 20 00 00 23 84 00 00 12 a8 1c 00 00 00 00 40
0x0110: 02 01 00 80 40 08 00 00 2d 78 00 00 00 00 00 00
0x0120: 00 81 00 00 ff ff 00 00 00 00 00 00 00 00 00 00
0x0130: 01 00 01 00
[-- Attachment #4: 5.15.10-test.txt --]
[-- Type: text/plain, Size: 2370 bytes --]
# ethtool -d eth0
Offset Values
------ ------
0x0000: 00 00 30 97 00 00 00 00 00 00 00 00 00 00 00 00
0x0010: 04 00 00 00 22 14 00 00 00 00 00 00 00 20 00 00
0x0020: 80 00 00 00 00 00 11 01 8f 00 00 ff a1 30 f8 00
0x0030: 00 00 00 00 00 00 00 00 25 00 00 00 50 00 00 00
0x0040: 00 00 00 80 00 00 00 00 00 00 00 00 00 00 00 00
0x0050: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0060: 00 00 00 00 00 00 00 00 00 80 00 00 00 20 00 00
0x0070: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0080: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0090: 00 00 00 00 01 00 00 00 00 00 00 00 00 00 00 00
0x00a0: 00 00 04 00 00 00 01 00 00 00 00 00 00 00 00 00
0x00b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x00c0: 00 00 00 00 1e 00 00 00 00 00 00 00 00 00 00 00
0x00d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x00e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x00f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0100: 0c 00 00 00 26 45 00 00 d6 1b 00 d2 00 00 00 00
0x0110: 00 00 00 00 00 08 00 00 00 30 00 00 00 00 00 00
0x0120: 00 81 00 00 ff ff 00 00 00 00 00 00 00 00 00 00
0x0130: 01 00 01 00
# ip link set dev eth0 up
# ethtool -d eth0
Offset Values
------ ------
0x0000: 00 00 30 97 00 00 00 00 00 00 00 00 00 00 00 00
0x0010: 04 00 00 00 22 14 00 00 00 00 00 00 00 20 00 00
0x0020: 80 00 00 00 00 00 11 01 8f 00 00 ff a1 30 f8 00
0x0030: 00 00 00 00 00 00 00 00 25 00 00 00 50 00 00 00
0x0040: 00 00 00 80 00 00 00 00 00 00 00 00 00 00 00 00
0x0050: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0060: 00 00 00 00 00 00 00 00 00 80 00 00 00 20 00 00
0x0070: 00 00 00 00 df 00 df 00 00 00 00 00 9f 01 9f 01
0x0080: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0090: 00 00 00 00 01 00 00 00 00 00 00 00 00 00 00 00
0x00a0: 00 00 04 00 00 00 01 00 00 00 00 00 00 00 00 00
0x00b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x00c0: 00 00 00 00 1e 00 00 00 00 00 00 00 00 00 00 00
0x00d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x00e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x00f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0100: 0c 20 00 00 26 45 00 00 d6 1b 00 d2 00 00 00 40
0x0110: 02 01 30 80 40 08 00 00 2d 78 00 00 00 00 00 00
0x0120: 00 81 00 00 ff ff 00 00 00 00 00 00 00 00 00 00
0x0130: 01 00 01 00
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Issues with smsc95xx driver since a049a30fc27c
2021-12-20 8:53 ` Andrew Lunn
2021-12-20 20:04 ` Gabriel Hojda
@ 2021-12-20 21:28 ` Gabriel Hojda
1 sibling, 0 replies; 10+ messages in thread
From: Gabriel Hojda @ 2021-12-20 21:28 UTC (permalink / raw)
To: Andrew Lunn; +Cc: Martyn Welch, netdev
On 2021-12-20 10:53, Andrew Lunn wrote:
>>> next, when i have time and if there's still no progress, i think i
>>> should
>> try to insert:
>>
>> ret = smsc95xx_reset(dev);
>> if (ret)
>> goto free_pdata;
>>
>> before
>>
>> ret = phy_connect_direct(dev->net, pdata->phydev,
>> &smsc95xx_handle_link_change,
>> PHY_INTERFACE_MODE_MII);
>>
>> in smsc95xx_bind() to try to emulate the old behavior for the first
>> call to
>> start_phy().
>
> Yes, that will be in interesting experiment. Something in
> smsc95xx_reset() is required.
>
> Andrew
since the above experiment did not work, i studied usbnet_open() in
usbnet.c which really tries to reset() and then check_connect() ...
after that i tried following patch which restored network functionality:
-----------------------------------------------------------------------------
--- a/drivers/net/usb/smsc95xx.c 2021-12-17 11:30:17.000000000
+0200
+++ b/drivers/net/usb/smsc95xx.c 2021-12-20 22:47:30.401385947
+0200
@@ -1961,7 +1961,8 @@
.bind = smsc95xx_bind,
.unbind = smsc95xx_unbind,
.link_reset = smsc95xx_link_reset,
- .reset = smsc95xx_start_phy,
+ .reset = smsc95xx_reset,
+ .check_connect = smsc95xx_start_phy,
.stop = smsc95xx_stop,
.rx_fixup = smsc95xx_rx_fixup,
.tx_fixup = smsc95xx_tx_fixup,
-----------------------------------------------------------------------------
i guess a call to smsc95xx_reset() is needed before phy_start() ...
Gabriel
^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2021-12-20 22:32 UTC | newest]
Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-12-17 15:45 Issues with smsc95xx driver since a049a30fc27c Martyn Welch
2021-12-18 16:45 ` Andrew Lunn
2021-12-18 17:23 ` Gabriel Hojda
2021-12-18 18:22 ` Andrew Lunn
2021-12-18 18:32 ` Andrew Lunn
2021-12-18 20:33 ` Gabriel Hojda
2021-12-20 10:37 ` Markus Reichl
[not found] ` <c95954ec12dfcf8877c1bf92047c0268@yo2urs.ro>
2021-12-20 8:53 ` Andrew Lunn
2021-12-20 20:04 ` Gabriel Hojda
2021-12-20 21:28 ` Gabriel Hojda
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).