From: Juerg Haefliger <juerg.haefliger@canonical.com>
To: Andrew Lunn <andrew@lunn.ch>
Cc: Juerg Haefliger <juerg.haefliger@canonical.com>,
netdev@vger.kernel.org, woojung.huh@microchip.com
Subject: Re: lan78xx: /sys/class/net/eth0/carrier stuck at 1
Date: Tue, 3 Nov 2020 13:47:12 +0100 [thread overview]
Message-ID: <20201103134712.6de0c2b5@gollum> (raw)
In-Reply-To: <20201023130519.GB745568@lunn.ch>
[-- Attachment #1: Type: text/plain, Size: 4199 bytes --]
On Fri, 23 Oct 2020 15:05:19 +0200
Andrew Lunn <andrew@lunn.ch> wrote:
> On Fri, Oct 23, 2020 at 08:29:59AM +0200, Juerg Haefliger wrote:
> > On Wed, 21 Oct 2020 21:35:48 +0200
> > Andrew Lunn <andrew@lunn.ch> wrote:
> >
> > > On Wed, Oct 21, 2020 at 05:00:53PM +0200, Juerg Haefliger wrote:
> > > > Hi,
> > > >
> > > > If the lan78xx driver is compiled into the kernel and the network cable is
> > > > plugged in at boot, /sys/class/net/eth0/carrier is stuck at 1 and doesn't
> > > > toggle if the cable is unplugged and replugged.
> > > >
> > > > If the network cable is *not* plugged in at boot, all seems to work fine.
> > > > I.e., post-boot cable plugs and unplugs toggle the carrier flag.
> > > >
> > > > Also, everything seems to work fine if the driver is compiled as a module.
> > > >
> > > > There's an older ticket for the raspi kernel [1] but I've just tested this
> > > > with a 5.8 kernel on a Pi 3B+ and still see that behavior.
> > >
> > > Hi Jürg
> >
> > Hi Andrew,
> >
> >
> > > Could you check if a different PHY driver is being used when it is
> > > built and broken vs module or built in and working.
> > >
> > > Look at /sys/class/net/eth0/phydev/driver
> >
> > There's no such file.
>
> I _think_ that means it is using genphy, the generic PHY driver, not a
> specific vendor PHY driver? What does
>
> /sys/class/net/eth0/phydev/phy_id contain.
There is no directory /sys/class/net/eth0/phydev.
$ ls /sys/class/net/eth0/
addr_assign_type broadcast carrier_down_count dev_port duplex ifalias link_mode netdev_group phys_port_name proto_down statistics type
addr_len carrier carrier_up_count device flags ifindex mtu operstate phys_switch_id queues subsystem uevent
address carrier_changes dev_id dormant gro_flush_timeout iflink name_assign_type phys_port_id power speed tx_queue_len
> > Given that all works fine as long as the cable is unplugged at boot points
> > more towards a race at boot or incorrect initialization sequence or something.
>
> Could be. Could you run
>
> mii-tool -vv eth0
Hrm. Running that command unlocks the carrier flag and it starts toggling on
cable unplug/plug. First invocation:
$ sudo mii-tool -vv eth0
Using SIOCGMIIPHY=0x8947
eth0: negotiated 1000baseT-FD flow-control, link ok
registers for MII PHY 1:
1040 79ed 0007 c132 05e1 cde1 000f 0000
0000 0200 0800 0000 0000 0000 0000 3000
0000 0000 0088 0000 0000 0000 3200 0004
0040 a000 a000 0000 a035 0000 0000 0000
product info: vendor 00:01:f0, model 19 rev 2
basic mode: autonegotiation enabled
basic status: autonegotiation complete, link ok
capabilities: 1000baseT-FD 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD
advertising: 1000baseT-FD 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD flow-control
link partner: 1000baseT-FD 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD flow-control
Subsequent invocation:
$ sudo mii-tool -vv eth0
Using SIOCGMIIPHY=0x8947
eth0: negotiated 1000baseT-FD flow-control, link ok
registers for MII PHY 1:
1040 79ed 0007 c132 05e1 cde1 000d 0000
0000 0200 0800 0000 0000 0000 0000 3000
0000 0000 0088 0000 0000 0000 3200 0004
0040 a000 0000 0000 a035 0000 0000 0000
product info: vendor 00:01:f0, model 19 rev 2
basic mode: autonegotiation enabled
basic status: autonegotiation complete, link ok
capabilities: 1000baseT-FD 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD
advertising: 1000baseT-FD 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD flow-control
link partner: 1000baseT-FD 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD flow-control
In the first invocation, register 0x1a shows a pending link-change interrupt
(0xa000) which wasn't serviced (and cleared) for some reason. Dumping the
registers cleared that interrupt bit and things start working correctly
afterwards. Nor sure yet why that first interrupt is ignored.
...Juerg
> in the good and bad case.
>
> Andrew
>
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
next prev parent reply other threads:[~2020-11-03 12:47 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-10-21 15:00 lan78xx: /sys/class/net/eth0/carrier stuck at 1 Juerg Haefliger
2020-10-21 19:35 ` Andrew Lunn
2020-10-23 6:29 ` Juerg Haefliger
2020-10-23 13:05 ` Andrew Lunn
2020-11-03 12:47 ` Juerg Haefliger [this message]
2020-11-03 15:27 ` Andrew Lunn
2020-11-06 8:56 ` Juerg Haefliger
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20201103134712.6de0c2b5@gollum \
--to=juerg.haefliger@canonical.com \
--cc=andrew@lunn.ch \
--cc=netdev@vger.kernel.org \
--cc=woojung.huh@microchip.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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).