| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <11991339-711b-442d-a1e4-8c3393b12b0a@gmail.com> Date: Fri, 14 Nov 2025 13:48:01 -0800 From: Florian Fainelli <f.fainelli@...il.com> To: Heiner Kallweit <hkallweit1@...il.com>, Fabio Estevam <festevam@...il.com> Cc: Russell King - ARM Linux <linux@...linux.org.uk>, edumazet <edumazet@...gle.com>, netdev <netdev@...r.kernel.org>, Andrew Lunn <andrew@...n.ch> Subject: Re: LAN8720: RX errors / packet loss when using smsc PHY driver on i.MX6Q On 11/14/25 13:33, Heiner Kallweit wrote: > On 11/14/2025 10:15 PM, Fabio Estevam wrote: >> Hi Andrew, >> >> On Thu, Nov 13, 2025 at 7:35 PM Andrew Lunn <andrew@...n.ch> wrote: >> >>> Maybe dump all 32 registers when genphy and smsc driver are being used >>> and compare them? >> >> The dump of all the 32 registers are identical in both cases: >> >> ./mii-diag -vvv >> mii-diag.c:v2.11 3/21/2005 Donald Becker (becker@...ld.com) >> http://www.scyld.com/diag/index.html >> Using the default interface 'eth0'. >> Using the new SIOCGMIIPHY value on PHY 0 (BMCR 0x3100). >> The autonegotiated capability is 01e0. >> The autonegotiated media type is 100baseTx-FD. >> Basic mode control register 0x3100: Auto-negotiation enabled. >> You have link beat, and everything is working OK. >> This transceiver is capable of 100baseTx-FD 100baseTx 10baseT-FD 10baseT. >> Able to perform Auto-negotiation, negotiation complete. >> Your link partner advertised cde1: Flow-control 100baseTx-FD >> 100baseTx 10baseT-FD 10baseT, w/ 802.3X flow control. >> End of basic transceiver information. >> >> libmii.c:v2.11 2/28/2005 Donald Becker (becker@...ld.com) >> http://www.scyld.com/diag/index.html >> MII PHY #0 transceiver registers: >> 3100 782d 0007 c0f1 05e1 cde1 0009 ffff >> ffff ffff ffff ffff ffff ffff ffff 0000 >> 0040 0002 60e0 ffff 0000 0000 0000 0000 >> ffff ffff 0000 000a 0000 00c8 0000 1058. >> Basic mode control register 0x3100: Auto-negotiation enabled. >> Basic mode status register 0x782d ... 782d. >> Link status: established. >> Capable of 100baseTx-FD 100baseTx 10baseT-FD 10baseT. >> Able to perform Auto-negotiation, negotiation complete. >> Vendor ID is 00:01:f0:--:--:--, model 15 rev. 1. >> No specific information is known about this transceiver type. >> I'm advertising 05e1: Flow-control 100baseTx-FD 100baseTx 10baseT-FD 10baseT >> Advertising no additional info pages. >> IEEE 802.3 CSMA/CD protocol. >> Link partner capability is cde1: Flow-control 100baseTx-FD 100baseTx >> 10baseT-FD 10baseT. >> Negotiation completed. >> >> After pinging with the Generic PHY driver: >> >> # ethtool -S eth0 | grep error >> tx_crc_errors: 0 >> rx_crc_errors: 0 >> rx_xdp_tx_errors: 0 >> tx_xdp_xmit_errors: 0 >> >> After pinging with the SMSC PHY driver: >> >> # ethtool -S eth0 | grep err >> tx_crc_errors: 0 >> IEEE_tx_macerr: 0 >> IEEE_tx_cserr: 0 >> rx_crc_errors: 19 The CRC errors should be a clear sign that you have a serious electrical issue here as the MAC is not capable of de-framing what is coming out of the PHY properly. Given that you use RMII this would indicate that your PHY's TX CLK, which is a RX CLK on the MAC side may not be stable, do you have a scope you could use to check that it looks correct? Anything on the PCB itself that could hinder the clock signal quality? Given that you don't see it at 10Mbits/sec, this would suggest you have an issue with data sampling and rise/fall times of the clock being misaligned with when the data is present on the data lines. -- Florian
Powered by blists - more mailing lists