Bug 75813

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 :>

(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>
  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

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

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.

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 :-(

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.  

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

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) 

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/