Bug 77992
| Summary: | mii-tool mis-reports link status on 3C905B-FX | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Retired] Red Hat Linux | Reporter: | Gabriel Schulhof <gabrielschulhof> | ||||
| Component: | net-tools | Assignee: | Radek Vokál <rvokal> | ||||
| Status: | CLOSED CURRENTRELEASE | QA Contact: | Ben Levenson <benl> | ||||
| Severity: | medium | Docs Contact: | |||||
| Priority: | medium | ||||||
| Version: | 8.0 | CC: | dgenn, ecki, tilmann | ||||
| Target Milestone: | --- | ||||||
| Target Release: | --- | ||||||
| Hardware: | i686 | ||||||
| OS: | Linux | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | Environment: | ||||||
| Last Closed: | 2004-10-07 15:22:55 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: | |||||||
| Attachments: |
|
||||||
I have fixed this upstream in the CVS which is the core for the next net-tools release. But I guess it is not only a problem with the recognition of an absent MII tranceiver, but also with the steadyly changing kernel ABI. I hope to get this cleaned up for 2.6. Current version attached. It might require a local mii.h copy. Bernd (ecki.de> Created attachment 95322 [details]
future version, please test
sorry, dont have the RH source so no patch
I tried the attached source code on a red hat 9 but still the same problem. However, there are some more strange things happening. The card is at only 10mb but the card and the network could do 100mb. mii-diag says: ./mii-diag Using the default interface 'eth0'. Basic registers of MII PHY #0: c000 c000 c000 c000 c000 c000 c000 c000. The autonegotiated capability is 0000. No common media type was autonegotiated! This is extremely unusual and typically indicates a configuration error. Perhaps the advertised capability set was intentionally limited. Basic mode control register 0xc000: Auto-negotiation disabled, with Speed fixed at 10 mbps, half-duplex. Transceiver in loopback mode! Transceiver currently being reset! Basic mode status register 0xc000 ... c000. Link status: not established. Your link partner advertised c000:. End of basic transceiver information. dmesg says: PCI: Found IRQ 11 for device 00:0e.0 3c59x: Donald Becker and others. www.scyld.com/network/vortex.html See Documentation/networking/vortex.txt 00:0e.0: 3Com PCI 3c905B Cyclone 100baseTx at 0xe400. Vers LK1.1.18-ac 00:50:04:36:ee:54, IRQ 11 product code 544a rev 00.12 date 03-05-99 Internal config register is 0000, transceivers 0xa. 8K byte-wide RAM 5:3 Rx:Tx split, 10baseT interface. Enabling bus-master transmits and whole-frame receives. 00:0e.0: scatter/gather enabled. h/w checksums enabled divert: allocating divert_blk for eth0 I dont understand this, why is mii-diag not reporting that it has not found a tranceiver? Turn off Kudzu at the boot runlevel with chkconfig and reboot and run mii-toll and see what happens. Everything will report fine and the nic will be fine. This is a duplicate bug for the 3c905 series cards an this 1.x version of Kudzu which also affects the Ent. 3 RH products and has been around since Fedora test1 and is still in the release vers as well. |
From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20021003 Description of problem: When using the mii-tool util from net-tools 1.60 (As shipped with RedHat 8.0) on a system having a 3C905B-FX card installed, it reports "no link", even when the interface is up and running. Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: 1. On a system as described above, run mii-tool 2.Watch it tell you there's no link, even though you're logged in via, say, SSH. Actual Results: mii-tool reports "no link". Expected Results: Based on what mii-diag reports, I believe it should be "No MII transceiver present" Additional info: I dove into the source code for mii-tool, only to find that it is a simplified version of Donald Becker's mii-diag. I compared the code (mii-diag says "No MII transceiver", whereas mii-tool reports "no link"). In mii-tool.c, on line 212, it says: if (mii_val[0] == 0xffff) { fprintf (stderr, "No MII trasceiver present!\n") ; return -1 ; } The equivalent lines in mii-diag.c are: if (mii_val[0] == 0xffff || mii_val[1] == 0x0000) { fprintf (stderr, "No MII transceiver present!\n") return -1 ; } I added printf statements to mii-tool.c, which allowed me to discover that, in the case of the 3C905B-FX, both mii_val[0] and mii_val[1] are set to 0x0000. As a result, the card passes mii-tools's check, but mii-diag (correctly?) diagnoses the fact that there is no MII transceiver. If mii-tool did the same check as mii-diag, it too would conclude that "No MII transceiver present!". This would allow the check_link_down function to work properly out of the box and, as a result, it wouldn't have to be hacked to return 1 right away, without running any checks.