Bug 199462
| Summary: | mii-tool and ethtool inconsistent for tg3 devices | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 4 | Reporter: | Bryn M. Reeves <bmr> |
| Component: | kernel | Assignee: | John W. Linville <linville> |
| Status: | CLOSED WONTFIX | QA Contact: | Brian Brock <bbrock> |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | 4.0 | CC: | jbaron |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | i386 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2006-08-08 13:26:12 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
| Bug Depends On: | |||
| Bug Blocks: | 198694 | ||
FYI, this problem was originally reported by the customerr on RHEL3. I have been able to reproduce the symptoms in RHEL4 and FC5 also. 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... 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 API. So, the only reasonable disposition for this is WONTFIX. I'm sorry. Please avoid using mii-tool (in favor of ethool) whenever possible. |
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): kernel-2.6.9-34.0.2.EL ethtool-1.8-4 net-tools-1.60-37.EL4.6 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 completely.