E.g. with the macb driver, which uses phylib, there is no link anymore when the link partner changes its abilities. This is because no autonegotiation is done again on link changes and hence the LPA register is not updated. Steps for reproduction: - Connect a 10/100 device to a 10/100 switch, configure switch port to 100Full - Enable interface, link will be present - Configure device to 10Full, link will be lost - Configure switch to 10Full Result: Link should be present at that point, but isn't ... debug messages in genphy_read_status show that lpa is still at 0x4101 (100Full). Note that all that is on an AT91SAM9G20 board (hence macb driver) with a Dawicom 9161 PHY connected to its Ethernet port, but AFAICT all phylib enabled drivers should suffer from this.
(switched to email. Please respond via emailed reply-to-all, not via the bugzilla web interface). On Tue, 26 Jan 2010 16:24:35 GMT bugzilla-daemon@bugzilla.kernel.org wrote: > http://bugzilla.kernel.org/show_bug.cgi?id=15147 > > Summary: phylib: no re-negotiation after link partner abilities > changed > Product: Drivers > Version: 2.5 > Platform: All > OS/Version: Linux > Tree: Mainline > Status: NEW > Severity: normal > Priority: P1 > Component: Network > AssignedTo: drivers_network@kernel-bugs.osdl.org > ReportedBy: dannybaumann@web.de > Regression: No > > > E.g. with the macb driver, which uses phylib, there is no link anymore when > the > link partner changes its abilities. This is because no autonegotiation is > done > again on link changes and hence the LPA register is not updated. > > Steps for reproduction: > - Connect a 10/100 device to a 10/100 switch, configure switch port to > 100Full > - Enable interface, link will be present > - Configure device to 10Full, link will be lost > - Configure switch to 10Full > > Result: > Link should be present at that point, but isn't ... debug messages in > genphy_read_status show that lpa is still at 0x4101 (100Full). > > Note that all that is on an AT91SAM9G20 board (hence macb driver) with a > Dawicom 9161 PHY connected to its Ethernet port, but AFAICT all phylib > enabled > drivers should suffer from this. > From the above it appears that this is a regression. Can you tell us which kernel version(s) were OK and which are not? Thanks.
Hi, > > Summary: phylib: no re-negotiation after link partner abilities > > changed [...] > > Component: Network > > AssignedTo: drivers_network@kernel-bugs.osdl.org > > ReportedBy: dannybaumann@web.de > > Regression: No ^^^^^^^^^^^^^^ ;-) > > E.g. with the macb driver, which uses phylib, there is no link anymore when > the > > link partner changes its abilities. This is because no autonegotiation is > done > > again on link changes and hence the LPA register is not updated. > > > > Steps for reproduction: > > - Connect a 10/100 device to a 10/100 switch, configure switch port to > 100Full > > - Enable interface, link will be present > > - Configure device to 10Full, link will be lost > > - Configure switch to 10Full > > > > Result: > > Link should be present at that point, but isn't ... debug messages in > > genphy_read_status show that lpa is still at 0x4101 (100Full). > > > > Note that all that is on an AT91SAM9G20 board (hence macb driver) with a > > Dawicom 9161 PHY connected to its Ethernet port, but AFAICT all phylib > enabled > > drivers should suffer from this. > > > > From the above it appears that this is a regression. > > Can you tell us which kernel version(s) were OK and which are not? As far as I am aware of, this is not a regression, at least not in phylib (if any, it's a regression for drivers that were converted to phylib). A code part that does re-negotiation when link is down after link was up for some time has never been present in the state machine. In the PHY_NOLINK state, all that has ever been done is doing phy_read_status and checking the new link state calculated from there. Unfortunately, I don't have a good idea what would be the best thing to do there. As far as I can tell from the basic MII PHY registers, there is no way to distinct the "no link and no carrier = no cable connected" and the "no link, but carrier = negotiation failed" states. If there was such a way, the fix probably would involve re-negotiating when going from state 1 to state 2 (or regularly using a timer when staying in state 2). But maybe I am missing something. Regards, Danny