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