netdev - Re: smsc95xx warning after a 'reboot' command

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Thu, 3 Mar 2022 03:32:13 +0100
From:   Andrew Lunn <andrew@...n.ch>
To:     Fabio Estevam <festevam@...il.com>
Cc:     Steve Glendinning <steve.glendinning@...well.net>,
        UNGLinuxDriver@...rochip.com, netdev <netdev@...r.kernel.org>
Subject: Re: smsc95xx warning after a 'reboot' command

On Wed, Mar 02, 2022 at 09:40:54PM -0300, Fabio Estevam wrote:
> On Wed, Mar 2, 2022 at 8:50 PM Andrew Lunn <andrew@...n.ch> wrote:
> 
> > If i'm reading this correctly, this is way to late, the device has
> > already gone. The PHY needs to be stopped while the device is still
> > connected to the USB bus.
> >
> > I could understand a trace like this with a hot unplug, but not with a
> > reboot. I would expect things to be shut down starting from the leaves
> > of the USB tree, so the smsc95xx should have a chance to perform a
> > controlled shutdown before the device is removed.
> >
> > This code got reworked recently. smsc95xx_disconnect_phy() has been
> > removed, and the phy is now disconnected in smsc95xx_unbind(). Do you
> > get the same stack trace with 5.17-rc? Or is it a different stack
> > trace?
> 
> Just tested 5.17-rc6 and I get no stack strace at all after a 'reboot' command:
> 
> [   21.953945] ci_hdrc ci_hdrc.1: remove, state 1
> [   21.958418] usb usb2: USB disconnect, device number 1
> [   21.963493] usb 2-1: USB disconnect, device number 2
> [   21.964227] smsc95xx 2-1.1:1.0 eth1: Failed to read reg index 0x00000114: -19
> [   21.968469] usb 2-1.1: USB disconnect, device number 3
> [   21.970808] smsc95xx 2-1.1:1.0 eth1: unregister 'smsc95xx'
> usb-ci_hdrc.1-1.1, smsc95xx USB 2.0 Ethernet
> [   21.975619] smsc95xx 2-1.1:1.0 eth1: Error reading MII_ACCESS
> [   21.975625] smsc95xx 2-1.1:1.0 eth1: __smsc95xx_mdio_read: MII is busy
> [   22.002479] smsc95xx 2-1.1:1.0 eth1: Failed to read reg index 0x00000114: -19
> [   22.009630] smsc95xx 2-1.1:1.0 eth1: Error reading MII_ACCESS
> [   22.015392] smsc95xx 2-1.1:1.0 eth1: __smsc95xx_mdio_read: MII is busy
> [   22.021939] smsc95xx 2-1.1:1.0 eth1: Failed to read reg index 0x00000114: -19
> [   22.029087] smsc95xx 2-1.1:1.0 eth1: Error reading MII_ACCESS
> [   22.034845] smsc95xx 2-1.1:1.0 eth1: __smsc95xx_mdio_read: MII is busy
> [   22.041743] smsc95xx 2-1.1:1.0 eth1: hardware isn't capable of remote wakeup
> [   22.068706] usb 2-1.4: USB disconnect, device number 4
> [   22.077327] ci_hdrc ci_hdrc.1: USB bus 2 deregistered
> [   22.085222] ci_hdrc ci_hdrc.0: remove, state 4
> [   22.089685] usb usb1: USB disconnect, device number 1
> [   22.095284] ci_hdrc ci_hdrc.0: USB bus 1 deregistered
> [   22.122356] imx2-wdt 30280000.watchdog: Device shutdown: Expect reboot!
> [   22.129073] reboot: Restarting system
> 
> I applied a049a30fc 27c ("net: usb: Correct PHY handling of smsc95xx")
> into 5.10.102, but it did not help.

I'm not a USB expert, but to me, it looks like the smsc95xx device is
being disconnected, rather than being unloaded. So it is already gone
by the time the PHY device is disconnected.

It would be good to have somebody who understands USB net devices to
take a look at this, in particularly the order. I'm wondering if there
is a hub in the middle, and the hub is being disabled, or a regulator
for the hub etc?

    Andrew