Re: 60+% ping packet loss on Pi3 under -current and stable-13
Date: Wed, 04 May 2022 15:41:25 UTC
After updating one of the troublesome Pi3s to FreeBSD pelorus.zefox.org 13.1-STABLE FreeBSD 13.1-STABLE #53 stable/13-n250662-0625715977d: Wed May 4 06:23:14 PDT 2022 bob@pelorus.zefox.org:/usr/obj/usr/src/arm64.aarch64/sys/GENERIC arm64 a series of error messages appeared on the serial console. I've not seen them before and wonder if they might be relevant to the connectivity problems lately seen. The machine was freshly-rebooted and at the time would not answer ping, though it did successfully set time using ntp. I got on the console to start an outbound ping, which usually sufficed to let inbound ssh connections work. Here's the console: Starting background file system checks in 60 seconds. Wed May 4 08:10:53 PDT FreeBSD/arm64 (pelorus.zefox.org) (ttyu0) login: bob Password: Last login: Tue May 3 09:01:03 from gateway.zefox.net FreeBSD 13.1-STABLE #53 stable/13-n250662-0625715977d: Wed May 4 06:23:14 PDT 2022 bob@pelorus.zefox.org:/usr/obj/usr/src/arm64.aarch64/sys/GENERIC [message of the day omitted] bob@pelorus:~ % ping 50.1.20.31 > ping.log & [1] 937 bob@pelorus:~ % May 4 08:12:19 pelorus su[952]: bob to root on /dev/pts/0 smsc0: error: usb error on tx: USB_ERR_IOERROR smsc0: warning: bulk read error, USB_ERR_IOERROR smsc0: warning: Failed to read register 0x118 smsc0: warning: Failed to read register 0x114 smsc0: warning: MII is busy smsc0: warning: Failed to read register 0x114 smsc0: warning: MII is busy smsc0: warning: Failed to read register 0x2c smsc0: warning: failed to read initial AFC_CFG, error 18 smsc0: warning: Failed to read register 0x114 smsc0: warning: MII is busy smsc0: at uhub1, port 1, addr 3 (disconnected) smsc0: warning: Failed to read register 0x114 smsc0: warning: MII is busy smsc0: warning: Failed to read register 0x114 smsc0: warning: MII is busy smsc0: warning: Failed to read register 0x114 smsc0: warning: MII is busy smsc0: warning: Failed to read register 0x114 smsc0: warning: MII is busy smsc0: warning: Failed to read register 0x114 smsc0: warning: MII is busy smsc0: warning: Failed to read register 0x114 smsc0: warning: MII is busy smscphy0: detached miibus0: detached smsc0: detached ping: sendto: No route to host usbd_setup_device_desc: getting device descriptor at addr 3 failed, USB_ERR_SHORT_XFER ping: sendto: No route to host smsc0 on uhub1 smsc0: <vendor 0x0424 product 0xec00, rev 2.00/2.00, addr 3> on usbus1 smsc0: chip 0xec00, rev. 0002 miibus0: <MII bus> on smsc0 smscphy0: <SMC LAN8700 10/100 interface> PHY 1 on miibus0 smscphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto smsc0: chip 0xec00, rev. 0002 ping: sendto: No route to host ping: sendto: No route to host There were no further ping errors and I was able to log in via ssh before noticing the errors on the console. An immediate run of usbconfig dump_stats reported: root@pelorus:/usr/home/bob # usbconfig dump_stats ugen1.1: <DWCOTG OTG Root HUB> at usbus1, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=SAVE (0mA) { UE_CONTROL_OK : 0 UE_ISOCHRONOUS_OK : 0 UE_BULK_OK : 0 UE_INTERRUPT_OK : 0 UE_CONTROL_FAIL : 0 UE_ISOCHRONOUS_FAIL : 0 UE_BULK_FAIL : 0 UE_INTERRUPT_FAIL : 0 } ugen1.2: <vendor 0x0424 product 0x9514> at usbus1, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=SAVE (2mA) { UE_CONTROL_OK : 791 UE_ISOCHRONOUS_OK : 0 UE_BULK_OK : 0 UE_INTERRUPT_OK : 4 UE_CONTROL_FAIL : 0 UE_ISOCHRONOUS_FAIL : 0 UE_BULK_FAIL : 0 UE_INTERRUPT_FAIL : 0 } ugen1.3: <vendor 0x0424 product 0xec00> at usbus1, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=ON (2mA) { UE_CONTROL_OK : 15495 UE_ISOCHRONOUS_OK : 0 UE_BULK_OK : 1435 UE_INTERRUPT_OK : 0 UE_CONTROL_FAIL : 29 UE_ISOCHRONOUS_FAIL : 0 UE_BULK_FAIL : 2 UE_INTERRUPT_FAIL : 0 } ugen1.4: <FTDI FT232R USB UART> at usbus1, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON (90mA) { UE_CONTROL_OK : 31 UE_ISOCHRONOUS_OK : 0 UE_BULK_OK : 25290 UE_INTERRUPT_OK : 0 UE_CONTROL_FAIL : 0 UE_ISOCHRONOUS_FAIL : 0 UE_BULK_FAIL : 3 UE_INTERRUPT_FAIL : 0 } ugen1.5: <JMicron SABRENT> at usbus1, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=ON (500mA) { UE_CONTROL_OK : 83 UE_ISOCHRONOUS_OK : 0 UE_BULK_OK : 5527 UE_INTERRUPT_OK : 0 UE_CONTROL_FAIL : 0 UE_ISOCHRONOUS_FAIL : 0 UE_BULK_FAIL : 61 UE_INTERRUPT_FAIL : 0 } root@pelorus:/usr/home/bob # Might this suggest any further experiments? I believe this is the first time errors other than on the boot drive have been reported using dump_stats. Thanks for reading, bob prohaska