Problem in phy.c, when using fixed network speed
Jenkins, Clive
Clive.Jenkins at xerox.com
Thu Aug 2 19:35:45 EST 2012
> 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
back to before Auto Negotiation became part of the
IEEE802* standard and each manufacturer implemented
its own strategy to establish a link. Although it is
possible "by experiment" to find the speed of your
link partner, it is impossible to determine its
Full/Half Duplex mode. IMHO when a fixed speed and
duplex setting is applied, phy.c should keep that
setting regardless of whether or not the link is
established. Not only is this undesirable behaviour,
but it deviates from the standard.
Clive
More information about the Linuxppc-dev
mailing list