Bug 199462 - mii-tool and ethtool inconsistent for tg3 devices
Summary: mii-tool and ethtool inconsistent for tg3 devices
Alias: None
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: kernel
Version: 4.0
Hardware: i386
OS: Linux
Target Milestone: ---
: ---
Assignee: John W. Linville
QA Contact: Brian Brock
Depends On:
Blocks: 198694
TreeView+ depends on / blocked
Reported: 2006-07-19 18:02 UTC by Bryn M. Reeves
Modified: 2007-11-30 22:07 UTC (History)
1 user (show)

Clone Of:
Last Closed: 2006-08-08 13:26:12 UTC

Attachments (Terms of Use)

Description Bryn M. Reeves 2006-07-19 18:02:55 UTC
After forcing tg3 duplex settings with mii-tool, ethtool and mii-tool give
inconsistent output:

# mii-tool -F 100baseTx-HD eth0
# mii-tool eth0
eth0: 100 Mbit, half duplex, link ok

ethtool eth0
Settings for eth0:
       Supported ports: [ MII ]
       Supported link modes:   10baseT/Half 10baseT/Full
                               100baseT/Half 100baseT/Full
                               1000baseT/Half 1000baseT/Full
       Supports auto-negotiation: Yes
       Advertised link modes:  Not reported
       Advertised auto-negotiation: No
       Speed: 100Mb/s
       Duplex: Full       <-------- Should be Half
       Port: Twisted Pair
       PHYAD: 1
       Transceiver: internal
       Auto-negotiation: off
       Supports Wake-on: g
       Wake-on: d
       Current message level: 0x000000ff (255)
       Link detected: yes 

Version-Release number of selected component (if applicable):

How reproducible:
All broaadcom cards tested so far show this behavior.

Steps to Reproduce:
1. Force NIC speed/duplex settings with mii-tool
2. Inspect settings with mii-tool/ethtool
3. ethtool shows the old settings
Actual results:
Changes made with mii-tool are not reported by ethtool.

Expected results:
Changes made with either tool are reflected by the other.

Additional info:
Attempting to reproduce this on an Intel e1000 device produced a different
problem - ethtool & mii-tool were consistent, but mii-tool setting were ignored

Comment 1 Bryn M. Reeves 2006-07-19 20:49:21 UTC
FYI, this problem was originally reported by the customerr on RHEL3. I have been
able to reproduce the symptoms in RHEL4 and FC5 also.

Comment 3 John W. Linville 2006-07-25 20:02:35 UTC
Hmmm...not sure what the right answer is here...

The problem is caused by the fact that the mii-tool interface allows the user 
to directly pound on the hardware registers, while the ethtool interface 
believes it knows the state.  So the ethtool handler doesn't query that actual 
hardware state.

While it may seem obvious to make ethtool query the hardware, that kinda 
breaks the model pictured for the ethtool API (i.e. the driver should control 
the hardware w/o the user messing behind its back).  The mii-tool and ethtool 
interfaces are fundamentally incompatible, with the mii-tool interface being 
now deprecated.

Obviously, I advise that you do NOT use mii-tool with your device if at all 
possible.  The "right" answer may be to disable mii-tool support in tg3 (and 
it sounds like e1000 as well).

I'll mull this over...

Comment 7 John W. Linville 2006-08-08 13:26:12 UTC
I don't see any reasonable way to fix this, given the nature of the two APIs.  
And, removing mii-tool support is out of the question because it breaks the 
RHEL support model and because there potentially are responsible uses for the 

So, the only reasonable disposition for this is WONTFIX.  I'm sorry.  Please 
avoid using mii-tool (in favor of ethool) whenever possible.

Note You need to log in before you can comment on or make changes to this bug.