All of lore.kernel.org
 help / color / mirror / Atom feed
From: Stefan Agner <stefan@agner.ch>
To: David Miller <davem@davemloft.net>, teg@jklm.no, f.fainelli@gmail.com
Cc: fabio.estevam@freescale.com, systemd-devel@lists.freedesktop.org,
	netdev@vger.kernel.org, u.kleine-koenig@pengutronix.de,
	l.stach@pengutronix.de
Subject: Re: Configuring ethernet link fails with No such device
Date: Tue, 12 Apr 2016 18:29:35 -0700	[thread overview]
Message-ID: <f888bb515fbeb7f8202bda89509eed8a@agner.ch> (raw)
In-Reply-To: <20160412.114435.458888996741613334.davem@davemloft.net>

[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

      reply	other threads:[~2016-04-13  1:29 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-04-11 22:46 Configuring ethernet link fails with No such device Stefan Agner
2016-04-11 23:10 ` Florian Fainelli
2016-04-12  1:29 ` David Miller
2016-04-12  7:25   ` Stefan Agner
2016-04-12  8:58 ` Bob Ham
2016-04-12 15:44   ` David Miller
2016-04-13  1:29     ` Stefan Agner [this message]

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=f888bb515fbeb7f8202bda89509eed8a@agner.ch \
    --to=stefan@agner.ch \
    --cc=davem@davemloft.net \
    --cc=f.fainelli@gmail.com \
    --cc=fabio.estevam@freescale.com \
    --cc=l.stach@pengutronix.de \
    --cc=netdev@vger.kernel.org \
    --cc=systemd-devel@lists.freedesktop.org \
    --cc=teg@jklm.no \
    --cc=u.kleine-koenig@pengutronix.de \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.