About the "PHY reset until link up" warning
Subsystems (2)
Hi,
When a cable is not connected while an interface goes up, the "PHY reset until link up" warning is logged. Looking back in the history, this warning was added in:
commit a7154cb8326c6015b6c5d9ce482d2a1f4c268d99
Author: François Romieu <[email protected]> Date: Wed Jun 2 12:03:02 2004 -0400
[PATCH] r8169: link handling and phy reset rework
Link handling changes (Andy Lutomirski <[email protected]>):
- removed rtl8169_hw_phy_reset() and its busy loop;
- RTL8169_PHY_TIMEOUT is x10 to account for the removal of the phy_link_down_cnt loop in rtl8169_phy_timer();
- added spinlocking in timer context for rtl8169_phy_timer to avoid messing with the {set/get}_settings commands issued via ethtool;
- more TBI stuff.
This patch differs from the former version on the following points:
- the LinkChg irq does not enable the phy timer when the link goes down any more;
- the phy timer is not enabled in rtl8169_set_speed();
- removal of the initial renegotiation hack.
(via git://git.kernel.org/pub/scm/linux/kernel/git/tglx/history.git)
If this is a (hardware) bug workaround, can't it be restricted to that specific hardware or removed altogether (perhaps firmware / other updates fixed it already?). Otherwise, what about removing this debug message?
Manually running "ip link set eth1 down" brings the interface down and no resets are being attempted. Another way to stop resetting the interface is inserting a cable, wait for link up and remove it again. This presumably works because rtl8169_down() removes the reset timer.
Regards,
Peter
Peter Wu <[email protected]> :
[...]
Quoted 3 lines
If this is a (hardware) bug workaround, can't it be restricted to that specific hardware or removed altogether (perhaps firmware / other updates fixed it already?).
It tastes of QA nightmare. It can't be proven safe easily.
Link failure sucks. If nowhere else, I'll play safe, shamanic with the phy and I want big pesky messages when something goes unusual.
Quoted 1 line
Otherwise, what about removing this debug message?
It can be disabled with the msglvl option of ethtool.
It should stop after a few seconds if runtime power management is enabled.
I can change my mind but I haven't seen much need for a policy change yet.
Signature · 1 line
Ueimor
David Miller
maintainerFrom: Francois Romieu <[email protected]>
Date: Mon, 22 Jul 2013 23:43:58 +0200
Quoted 2 lines
I can change my mind but I haven't seen much need for a policy change yet.
In every case where this issue has popped up, we have decided that printing messages when the cable is simply unplugged is very undesirable.
I used to print messages on link failure in all the early drivers I wrote, it was a bad decision.
David Miller <[email protected]> :
Quoted 1 line
From: Francois Romieu <[email protected]>
[...]
Quoted 6 lines
Quoted 2 lines
I can change my mind but I haven't seen much need for a policy change yet.
In every case where this issue has popped up, we have decided that printing messages when the cable is simply unplugged is very undesirable.
I could agree if there had not been any progress made with runtime power management.
Quoted 2 lines
I used to print messages on link failure in all the early drivers I wrote, it was a bad decision.
I know something is very wrong when it repeats itself a lot in a PR.
Feel free to take any message silenting patch if someone feels it worth.
Signature · 1 line
Ueimor