Problem in phy.c, when using fixed network speed

2 messages, 2 authors, 2012-08-02 · open the first message on its own page

Problem in phy.c, when using fixed network speed

From: Michael Koch <hidden>
Date: 2012-08-01 18:21:34

Hi all,
during testing i encountered a problem with setting up a 5200B 
controller with a MICREL phy at static 100MBit full duplex - without 
autonegotiation.

I performed this as usual with ethtool and was succesful when i had my 
link partner up, providing a link.

When kepping the link partner off, meaning no link at all, my machine 
started to degrade its link capabilities ending 10MBit half duplex.

I tracked it down to drivers/net/phy/phy.c:
in the function phy_state_machine, the case block PHY_FORCING causes 
this (at least for me) undesired behaviour. Calling the 
phy_force_reduction function degrades actually an intentionally static 
setup.

I deactivated those lines, and it works for me.

But anyhow i feel soe need to have a general solution that takes static 
non autonagotiation setups into account.

What do you think?

Hope to hear from you

Michael

RE: Problem in phy.c, when using fixed network speed

From: Jenkins, Clive <hidden>
Date: 2012-08-02 09:46:25

Hi all,
during testing i encountered a problem with setting
up a 5200B controller with a MICREL phy at static
100MBit full duplex - without autonegotiation.

I performed this as usual with ethtool and was
succesful when i had my link partner up, providing
a link.

When kepping the link partner off, meaning no link
at all, my machine started to degrade its link
capabilities ending 10MBit half duplex.

I tracked it down to drivers/net/phy/phy.c:
in the function phy_state_machine, the case block
PHY_FORCING causes this (at least for me) undesired
behaviour. Calling the phy_force_reduction function
degrades actually an intentionally static setup.

I deactivated those lines, and it works for me.

But anyhow i feel soe need to have a general
solution that takes static non autonagotiation
setups into account.

What do you think?

Hope to hear from you

Michael
Yes, I have encountered this before. I think it dates=20
back to before Auto Negotiation became part of the=20
IEEE802* standard and each manufacturer implemented=20
its own strategy to establish a link. Although it is=20
possible "by experiment" to find the speed of your=20
link partner, it is impossible to determine its=20
Full/Half Duplex mode. IMHO when a fixed speed and=20
duplex setting is applied, phy.c should keep that=20
setting regardless of whether or not the link is=20
established. Not only is this undesirable behaviour,=20
but it deviates from the standard.

Clive
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help