After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 766179 - NM wrongly determines carrier detection capability with some ethernet drivers
NM wrongly determines carrier detection capability with some ethernet drivers
Status: RESOLVED FIXED
Product: NetworkManager
Classification: Platform
Component: general
1.2.x
Other Linux
: Normal normal
: ---
Assigned To: NetworkManager maintainer(s)
NetworkManager maintainer(s)
Depends on:
Blocks:
 
 
Reported: 2016-05-09 15:12 UTC by Beniamino Galvani
Modified: 2016-05-12 10:10 UTC
See Also:
GNOME target: ---
GNOME version: ---

Attachments
bring up interface before getting capabilities (1.12 KB, patch)
2016-05-09 15:24 UTC, Carlo Caione 		none Details | Review

Description Beniamino Galvani 2016-05-09 15:12:28 UTC 
Some ethernet drivers return -EBUSY to the GLINK ethtool request if the interface is not brought up before. For example, using the stmmac driver, NM reports:

   <info> (eth0): driver 'stmmaceth' does not support carrier detection

because support for the capability is detected during realize_start_setup() when the interface is still down.
Comment 1 Carlo Caione 2016-05-09 15:24:44 UTC 
Created attachment 327527 [details] [review]
bring up interface before getting capabilities
Comment 2 Carlo Caione 2016-05-09 15:26:31 UTC 
The problem is also described here http://billauer.co.il/blog/2014/01/networkmanager-carrier-detect/ but I encountered the same issue on a different SoC using the same ethernet driver. The attachment shows my current workaround.
Comment 3 Thomas Haller 2016-05-09 16:39:10 UTC 
(In reply to Carlo Caione from comment #1)
> Created attachment 327527 [details] [review] [review]
> bring up interface before getting capabilities

I think, a better fix is to re-fetch the capabilies after the device is up.
This patch -- aside not being for master, where device-construction works different -- already brings the device in the constructor up. That think that is not intended.


How about https://cgit.freedesktop.org/NetworkManager/NetworkManager/log/?h=th/device-carrier-cap-bgo766179 ?
Comment 4 Beniamino Galvani 2016-05-11 09:44:20 UTC 
(In reply to Thomas Haller from comment #3)
> How about
> https://cgit.freedesktop.org/NetworkManager/NetworkManager/log/?h=th/device-
> carrier-cap-bgo766179 ?

In realize_start_setup() we subscribe to NM_CONFIG_SIGNAL_CONFIG_CHANGED if the device supports carrier detection. If the capability is discovered later in bring_up(), I think we should still subscribe to signal if not done before.