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):
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"
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 == 0xffff)
fprintf (stderr, "No MII trasceiver present!\n") ;
return -1 ;
The equivalent lines in mii-diag.c are:
if (mii_val == 0xffff || mii_val == 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 and mii_val 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
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.
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
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:
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.
PCI: Found IRQ 11 for device 00:0e.0
3c59x: Donald Becker and others. www.scyld.com/network/vortex.html
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
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.