Configuring ethernet link fails with No such device

Configuring ethernet link fails with No such device

[Stefan Agner]

Hi All,

I traced an issue in which we tried configuring duplex mode and speed in
a systemd-udevd .link file failed with the following error:
"Could not set speed or duplex of eth0 to 0 Mbps (half): No such device"

The FEC driver (fec_main.c) does not initialize phy_dev until the device
has been opened, and therefor the callback fec_enet_(get|set)_settings
returns -19.

What is the expectation/definition when link configuration should be
possible? Only after the network device got opened or before?

Or in other words: Is this a Kernel or systemd issue? At what point is
link configuration "guaranteed" to work?

It seems that the FEC driver used to probe the PHY earlier, it has been
moved to the open callback with commit 418bd0d4df ("netdev/fec: fix
ifconfig eth0 down hang issue")...

There has been a similar report on the systemd-devel mailing list a
while ago, probably the same underlying issue:
https://www.mail-archive.com/systemd-devel@lists.freedesktop.org/msg33186.html

Re: Configuring ethernet link fails with No such device

[Florian Fainelli]

On 11/04/16 15:46, Stefan Agner wrote:
> Hi All,
> 
> I traced an issue in which we tried configuring duplex mode and speed in
> a systemd-udevd .link file failed with the following error:
> "Could not set speed or duplex of eth0 to 0 Mbps (half): No such device"
> 
> The FEC driver (fec_main.c) does not initialize phy_dev until the device
> has been opened, and therefor the callback fec_enet_(get|set)_settings
> returns -19.
> 
> What is the expectation/definition when link configuration should be
> possible? Only after the network device got opened or before?

It seems to me like systemd tries to configure the device while we are
still opening it, which is arguably something that can be done, but you
are in a transient state, the interface is not completely ready yet.

> 
> Or in other words: Is this a Kernel or systemd issue? At what point is
> link configuration "guaranteed" to work?

Past ndo_open() had a chance to return, therefore connect to the PHY
device, is when the configuration/information querying is able to succeed.

> 
> It seems that the FEC driver used to probe the PHY earlier, it has been
> moved to the open callback with commit 418bd0d4df ("netdev/fec: fix
> ifconfig eth0 down hang issue")...

Part of the reason for doing that, is that probing for the PHY during
the driver's probe function could leave you with unused HW that is
powered on for no good reason. Until we get into ndo_open, we have no
clue if the interface is going to be used or not, so it is better to
move part of the HW initialization as late as possible in the process.

> 
> There has been a similar report on the systemd-devel mailing list a
> while ago, probably the same underlying issue:
> https://www.mail-archive.com/systemd-devel@lists.freedesktop.org/msg33186.html
> 
> --
> Stefan
> 


-- 
Florian

Re: Configuring ethernet link fails with No such device

[David Miller]

From: Stefan Agner <stefan@agner.ch>
Date: Mon, 11 Apr 2016 15:46:08 -0700

> What is the expectation/definition when link configuration should be
> possible? Only after the network device got opened or before?

Only after it is open.  Drivers almost always have the entire chip in
powerdown state when it is not open, so we wouldn't be able to
properly do link settings even if we wanted to when the device is
closed.

Re: Configuring ethernet link fails with No such device

[Stefan Agner]

On 2016-04-11 18:29, David Miller wrote:
> From: Stefan Agner <stefan@agner.ch>
> Date: Mon, 11 Apr 2016 15:46:08 -0700
> 
>> What is the expectation/definition when link configuration should be
>> possible? Only after the network device got opened or before?
> 
> Only after it is open.  Drivers almost always have the entire chip in
> powerdown state when it is not open, so we wouldn't be able to
> properly do link settings even if we wanted to when the device is
> closed.

I see. Afact it is a udev rule which triggers the built-in link setup
code:
https://github.com/systemd/systemd/blob/09541e49ebd17b41482e447dd8194942f39788c0/rules/80-net-setup-link.rules

The udev rule is triggering on action add (=> probe on driver level). At
least on the device I tested, it seems that there is no event on open...
Any other ideas what could be used as trigger to configure the link?

Re: Configuring ethernet link fails with No such device

[Bob Ham]

On Mon, 2016-04-11 at 15:46 -0700, Stefan Agner wrote:

> The FEC driver (fec_main.c) does not initialize phy_dev until the
> device
> has been opened, and therefor the callback
> fec_enet_(get|set)_settings
> returns -19.

I saw the same problem with the FEC driver.  From what I recall, it
became clear that there was a problem with the driver returning from
the eth device initialisation before the PHY was initialised, which
apparently is Bad and Wrong.

> Or in other words: Is this a Kernel or systemd issue?

From what I recall, both; an issue with the FEC driver, and issues in
systemd/udevd's handling of link-level settings.

-- 
Bob Ham <bob.ham@collabora.com>
Software Engineer

>>>>>>>>
Open First 
Collabora is hiring!
Please check out our latest opportunities here:
http://bit.ly/Collabora-Careers
<<<<<<<<



_______________________________________________
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: Configuring ethernet link fails with No such device

[David Miller]

From: Bob Ham <bob.ham@collabora.com>
Date: Tue, 12 Apr 2016 09:58:12 +0100

> On Mon, 2016-04-11 at 15:46 -0700, Stefan Agner wrote:
> 
>> Or in other words: Is this a Kernel or systemd issue?
> 
> From what I recall, both; an issue with the FEC driver, and issues in
> systemd/udevd's handling of link-level settings.

This is my impression of the situation as well.
_______________________________________________
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: Configuring ethernet link fails with No such device

[Stefan Agner]

[added Tom Gundersen as he seemed to have worked on udev's net link
built-in]

On 2016-04-12 08:44, David Miller wrote:
> From: Bob Ham <bob.ham@collabora.com>
> Date: Tue, 12 Apr 2016 09:58:12 +0100
> 
>> On Mon, 2016-04-11 at 15:46 -0700, Stefan Agner wrote:
>>
>>> Or in other words: Is this a Kernel or systemd issue?
>>
>> From what I recall, both; an issue with the FEC driver, and issues in
>> systemd/udevd's handling of link-level settings.
> 
> This is my impression of the situation as well.

The execution order looks as follows for the FEC driver (taken from a
recent kernel with some additional printks, serial console):

...
[    1.157086] fec_probe
...
[    1.190350] fec_enet_mii_init
[    1.205446] libphy: fec_enet_mii_bus: probed
[    1.217849] fec 400d1000.ethernet eth0: registered PHC device 0
...
[   10.751060] dev_ethtool, rc -19 => (ETHTOOL_GSET) Too early...
[   11.262333] fec_enet_open
[   11.479928] fec_enet_mii_probe => Or/and too late...

Looking at the journal:
...
Apr 13 01:02:49 colibri-vf systemd[1]: Started udev Coldplug all
Devices.
...
Apr 13 01:02:50 colibri-vf kernel: mdev_ethtool, rc -19
...
Apr 13 01:02:50 colibri-vf systemd-udevd[197]: Could not set speed or
duplex of eth0 to 0 Mbps (half): No such device
...
Apr 13 01:02:51 colibri-vf kernel: fec_enet_open
...
Apr 13 01:02:51 colibri-vf kernel: fec_enet_mii_probe

The service "udev Coldplug all Devices" essentially executes:
udevadm trigger --type=subsystems --action=add ; udevadm trigger
--type=devices --action=add

I guess the "add" udev event is generated due to the fact that the
device has successfully been probed. If the kernel is allowed to
initialize the PHY as late as at open time, systemd should configure the
link at a point after link up... Do you agree on that?

Afact there is no udev event on link up, hence this would not be a mere
udev rule change...?

So I think the issue is either a systemd/udev issue or a FEC driver
issue. And the solution is one of this two options:
- Move (all the) PHY probes at driver probe time, then the PHY will be
probed when udev processes the add event
- Or move systemd/networkd/udev link processing, set the link settings
only after the device has been opened (link up).

Florian brought up a good point in another answer:
> Part of the reason for doing that, is that probing for the PHY during
> the driver's probe function could leave you with unused HW that is
> powered on for no good reason. Until we get into ndo_open, we have no
> clue if the interface is going to be used or not, so it is better to
> move part of the HW initialization as late as possible in the process.

Therefor I think only option 2 is actually viable.

--
Stefan






_______________________________________________
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel