Bug 75813 - erroneous mii-tool output (results in n/w being down)
erroneous mii-tool output (results in n/w being down)
Status: CLOSED CURRENTRELEASE
Product: Red Hat Linux
Classification: Retired
Component: kernel (Show other bugs)
8.0
i686 Linux
medium Severity medium
: ---
: ---
Assigned To: Arjan van de Ven
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2002-10-12 19:48 EDT by Andrew Parker
Modified: 2008-08-01 12:22 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2004-09-30 11:40:03 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Andrew Parker 2002-10-12 19:48:09 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (compatible; Konqueror/3; Linux)

Description of problem:
mii-tool is reporting "eth0: 10 Mbit, half duplex, no link" for one of my NICs when it is 100Mb and it should say 'link ok'

This is preventing ifup eth0 from working (i get a "failed; no link present.  Check cable?' error), so the n/w is down at boot time.

running dhclient manually configures the NIC ok.

i don't know if the scripts worked the same in 7.2, but the same hardware had no problems.

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


How reproducible:
Always

Steps to Reproduce:
1.run /sbin/mii-tool
2.
3.
	

Actual Results:  eth0: 10 Mbit, half duplex, no link
eth1: negotiated 100baseTx-FD, link ok


Expected Results:  eth0: 100 Mbit, half duplex, link ok   (this is an assumption)
eth1: negotiated 100baseTx-FD, link ok

Additional info:

eth0 is on board NIC (detected Intel EtherExpress Pro 100B) (mobo is a Supermicro PIIIDME)
eth1 is PCI NIC (detected NatSemi DP83815 fast thernet)

mii-tool -V is the same as it was in 7.2
     mii-tool.c 1.9 2000/04/28 00:56:08 (David Hinds)

please feel free to contact me if there is any additional info you need from me
Comment 1 Need Real Name 2002-11-17 16:32:52 EST
i have the same problem, but with a pcmcia SMC 2632W-V2 wireless card.

the redhat scripts use mii-tool to check link status.

mii-tool reports no link even when a ping works!

resetting has no effect.
maybe mii-tool doesn't get along with the driver or 
maybe it isn't meant to support wireless cards - but the redhat
script uses it...

here is the output from mii-tool:
[root@host213 network-scripts]# mii-tool -R -v eth1
resetting the transceiver...
[root@host213 network-scripts]# mii-tool -v eth1
eth1: 10 Mbit, half duplex, no link
  product info: vendor 00:00:00, model 0 rev 0
  basic mode:   10 Mbit, half duplex
  basic status: no link
  capabilities:
  advertising:
[root@host213 network-scripts]# mii-tool -r -v eth1
restarting autonegotiation...
[root@host213 network-scripts]# mii-tool -v eth1
eth1: 10 Mbit, half duplex, no link
  product info: vendor 00:00:00, model 0 rev 0
  basic mode:   10 Mbit, half duplex
  basic status: no link
  capabilities:
  advertising:

see ping works there _must_ be a link:
[root@host213 network-scripts]# ping fw
PING fw (192.168.2.1) from 192.168.2.101 : 56(84) bytes of data.
64 bytes from fw (192.168.2.1): icmp_seq=1 ttl=64 time=2.90 ms
64 bytes from fw (192.168.2.1): icmp_seq=2 ttl=64 time=2.53 ms
64 bytes from fw (192.168.2.1): icmp_seq=3 ttl=64 time=2.89 ms

so when pcmcia card is plugged in and net.agent executes...
and ifup eth1 is executed i get the messages about
their being no link about like this (from ifup)

  echo -n $"Determining IP information for ${DEVICE}..."
    if check_link_down ${DEVICE}; then
        echo $" failed; no link present.  Check cable?"
        ip link set ${DEVICE} down >/dev/null 2>&1

so, i login as root and execute dhclient eth1 and all works just
fine.

wireless card wasn't supported out of the box here is the info
on it:
[root@host213 pcmcia]# cat smc.conf
device "pcmf502r"
  class "network" module "pcmf502r"

card "SMC 2632W V2 11 Mbps Wireless PCMCIA Card"
  manfid 0x01bf, 0xb301
  bind "pcmf502r"


thanks :>
Comment 2 Andrew Parker 2002-11-17 21:28:20 EST
(Additional info relating to my original post)

Output from dmesg yields what may be a clue.  Initially it reports an invalid 2
byte EEPROM checksum.  Later on, there's another checksum that passes, this time
its a 4 byte checksum, so its presumably a different one.  Not sure if this is
relevant, or just a red herring.



eth0: Invalid EEPROM checksum 0x47c4, check settings before activating this devi
ce!
eth0: OEM i82557/i82558 10/100 Ethernet, 00:30:48:10:0A:8D, IRQ 16.
  Receiver lock-up bug exists -- enabling work-around.
  Board assembly 000d80-134, Physical connectors present:
  Primary interface chip i82553-A/B PHY #2.
  General self-test: passed.
  Serial sub-system self-test: passed.
  Internal registers self-test: passed.
  ROM checksum self-test: passed (0x04f4518b).
  Receiver lock-up workaround activated.
natsemi.c:v1.07 1/9/2001  Written by Donald Becker <becker@scyld.com>
  http://www.scyld.com/network/natsemi.html
  (unofficial 2.4.x kernel port, version 1.07+LK1.0.14, Nov 27, 2001  Jeff Garzi
k, Tjeerd Mulder)
divert: allocating divert_blk for eth1
Comment 3 Pádraig Brady 2003-01-23 07:53:33 EST
OK this hits me also in phoebe with a SiS900 eth0.
A little investigation shows that there is a time
dependency of about 2.375 seconds (on my Celery 866)
between `ip link show` saying link is up and mii-tool
recognising likewise. Here's my test script:

#!/bin/sh
mii-tool eth0
ip link show eth0
if ! LC_ALL=C ip link show eth0 2>/dev/null| grep -q UP ; then
   ip link set eth0 up >/dev/null 2>&1
   timeout=0
   while [ $timeout -le 10 ]; do
	LC_ALL=C ip link show eth0 2>/dev/null | grep -q UP && break
	usleep 500000
	timeout=$((timeout+1))
   done
fi
usleep 2375000 #any shorter and mii-tool will say "no link"
mii-tool eth0

---------------------------------------
And the output from the script (showing a
sucessful run since I added the delay).
---------------------------------------
[root@localhost root]# sh -x test_SiS900
+ mii-tool eth0
eth0: no autonegotiation, 100baseTx-HD, link ok
+ ip link show eth0
2: eth0: <BROADCAST,MULTICAST> mtu 1500 qdisc pfifo_fast qlen 100
    link/ether 00:90:f5:0c:07:f3 brd ff:ff:ff:ff:ff:ff
+ LC_ALL=C
+ ip link show eth0
+ grep -q UP
+ ip link set eth0 up
+ timeout=0
+ '[' 0 -le 10 ']'
+ LC_ALL=C
+ ip link show eth0
+ grep -q UP
+ break
+ usleep 2375000
+ mii-tool eth0
eth0: no autonegotiation, 100baseTx-HD, link ok
Comment 4 Habig, Alec 2003-04-17 13:46:53 EDT
Still a problem in rh9.  Rather a nasty one, as if you don't know what part of
the script to edit, you'll think that your networking is fatally broken. 
(although commenting out the link check in /sbin/ifup works fine, of course).

On the 5 machines of mine with this problem, Padraig's delay for a few seconds
workaround does not help (the mii-tool output remains broken indefinitely).  Let
me know if there's debugging output from these machines which could help resolve
the issue.

Bug 75062 is a dupe of this bug, by the way, if you want to consolidate them.
Comment 5 Pádraig Brady 2003-04-18 06:25:11 EDT
Hi Alec, what network card/driver have you?
I just checked and this problem was "fixed"
for me between 8.0.92 and 8.0.94 for SiS900.
I had a look at the driver code and it's
been changing a bit including mii specific stuff.

Hrm but the duplex setting doesn't seem to be
negotiated now :-(
Comment 6 Habig, Alec 2003-05-07 13:59:07 EDT
Oops, sorry for the late reply, forgot to add myself to the CC list.

All using the 3c59x driver.  A Dell Precsion 420 has the problem (a 530 does
not, both machines have 3C905C's), and all four Micron Millenia (3C905c-TX) have
the problem.  

The really weird thing - both Dells have a PCI version fo the NIC in addition to
the integrated one.  And on the 420 with the problem, one NIC works fine and the
other doesn't.

On the cases where the link is not detected by mii-tool, it also can't even find
the vendor ID or any other information.

Note that aside from the mii-tools output, all the NICs work just fine, they
show up correctly at boot, can be passed kernel parameters, etc.  
Comment 7 Phil Knirsch 2004-04-20 08:36:27 EDT
This really sounds much more like a kernel driver problem than a
problem of the userland tools. They simply use the ioctl() calls which
the drivers either do or don't implement correctly.

Reassigning to kernel.

Read ya, Phil
Comment 8 Julio Velloso 2004-07-16 08:10:59 EDT
I change i my case the file modules.conf, and all work fine.

options 3c59x options=8

Options Line  Media Type  
options 3c59x options=0  "10baseT"  
options 3c59x options=1  "10Mbs AUI"  
options 3c59x options=3  "10base2"  
options 3c59x options=4  "100baseTX"  
options 3c59x options=5  "100baseFX"  
options 3c59x options=8  "Autonegotiate"  
options 3c59x options=9  "MII-External"  
options 3c59x options=10  "Default" (10baseT) 
Comment 9 Bugzilla owner 2004-09-30 11:40:03 EDT
Thanks for the bug report. However, Red Hat no longer maintains this version of
the product. Please upgrade to the latest version and open a new bug if the problem
persists.

The Fedora Legacy project (http://fedoralegacy.org/) maintains some older releases, 
and if you believe this bug is interesting to them, please report the problem in
the bug tracker at: http://bugzilla.fedora.us/

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