Bug 100527 (IT_39731) - RHEL3_U4 (NET PCNET32) DHCP client setup on NIC VMware don't work in VMware on reboot
Summary: RHEL3_U4 (NET PCNET32) DHCP client setup on NIC VMware don't work in VMware o...
Alias: IT_39731
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: kernel (Show other bugs)
(Show other bugs)
Version: 3.0
Hardware: i386 Linux
Target Milestone: ---
Assignee: John W. Linville
QA Contact:
: 111683 115598 154106 (view as bug list)
Depends On:
Blocks: 123574
TreeView+ depends on / blocked
Reported: 2003-07-23 06:00 UTC by Peter Bieringer
Modified: 2007-11-30 22:06 UTC (History)
12 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2004-12-20 20:54:39 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
fix proposal (672 bytes, patch)
2004-02-19 13:55 UTC, Thomas M Steenholdt
no flags Details | Diff
updated version of the previously submitted patch! (620 bytes, patch)
2004-02-21 21:59 UTC, Thomas M Steenholdt
no flags Details | Diff

External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2004:550 normal SHIPPED_LIVE Updated kernel packages available for Red Hat Enterprise Linux 3 Update 4 2004-12-20 05:00:00 UTC

Description Peter Bieringer 2003-07-23 06:00:16 UTC
Description of problem:
VMware NIC is also not liked by "ifup eth0" in case of DHCP...reports "no link"
:-( but manual setup and "dhclient eth0" works...

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

How reproducible:

Steps to Reproduce:
1.install severn in VMware
2.Use DHCP for NIC

Actual Results:  Interface wouldn't be configured

Expected Results:  Should be configured

Additional info:

Comment 1 Bernd Bartmann 2003-07-23 06:33:14 UTC
Known bug since at least Red Hat 9. Have a look at the knowledge base at 
www.vmware.com and search for DHCP. Article nr. 977 explains a workaround. 

Comment 2 Bill Nottingham 2003-07-23 15:59:30 UTC
This sounds like a vmware issue in that it's not reporting link status properly.

Comment 3 Peter Bieringer 2003-07-23 19:54:12 UTC
According to


here copy & paste:

Getting a DHCP Address in a Red Hat Linux 9.0 Virtual Machine 

When a Red Hat Linux 9.0 guest operating system tries to get a DHCP address, the attempt may fail 
with an error message that states the link is down. On ESX Server, this happens only if you are using the 
vlance driver for your network connection. 

To work around this problem, become root (su -) and use a text editor to edit the following files in the 
guest operating system. If only one of these files exist, make the change for that file only. 



In both cases, [n] is the number of the Ethernet adapter - for example, eth0. 

Add the following section to each of these two files: 

check_link_down () { 

return 1; 


Comment 4 Bill Nottingham 2003-07-23 19:55:57 UTC
Exactly; they're removing the test completely; apparently their vlance driver
doesn't report link state right.

Comment 5 Petr Vandrovec 2003-08-27 18:18:27 UTC
No. pcnet32 kernel driver reports on link on any AMD network device without MII.
Get physical Amd79C970A and watch same error report.

Take a look at the driver. pcnet32_ioctl calls pcnet32_ethtool_ioctl for
SIOCETHTOOL. pcnet32_ethtool_ioctl calls mii_link_ok for ETHTOOL_GLINK.
mii_link_ok calls mii->mdio_read and checks whether BMSR_LSTATUS set. pcnet32's
mdio_read always returns 0 for mii-less devices (if (!lp->mii) return 0);

So driver incorrectly reports no link. Two fixes possible: either properly
implement link status for non-mii case (find whether one of BCR LED registers is
set to track link status, and then read this LED value) or make this ioctl call
returning an error.

Unfortunately I cannot reopen the bug. But it does not change that it is bug in
the kernel, and not in the VMware.

Comment 6 Bill Nottingham 2003-08-27 18:21:30 UTC
Reopening then; kernel does sound appropriate.

Comment 7 Peter Bieringer 2003-11-17 16:09:54 UTC
Still the same on kernel used by Fedora Core 1: 2.4.22-1.2115.nptl

Comment 8 Billy Foss 2003-12-03 15:31:16 UTC
How is this different from:

Some solutions are suggested there.

Comment 9 Petr Vandrovec 2003-12-03 15:36:40 UTC
104711 is newer, and so should be closed as a duplicate. Besides that 
I do not think that we should paper over the pcnet32 driver bug in 
initscript (as 104711 suggests), instead of fixing bug in the kernel.

Comment 10 Dan Naumov 2003-12-08 19:20:35 UTC
*** Bug 111683 has been marked as a duplicate of this bug. ***

Comment 11 Billy Foss 2003-12-18 21:01:11 UTC
FYI, I built 2.6.0-test11 to test and got the same "no link" when 
running against a modified Fedora Core 1.

Any suggestions to getting this moved to the kernel list?

Comment 12 Billy Foss 2003-12-18 21:11:05 UTC
Sorry, I see that is it in the kernel component, but I did not see 
anything related on bugzilla.kernel.org.  I was not sure which is 
more appropriate.  

Comment 13 Bernd Bartmann 2004-02-13 18:59:45 UTC
This bug is still not fixed in kernel-2.4.22-1.2166.

Comment 14 Thomas M Steenholdt 2004-02-19 13:55:03 UTC
Created attachment 97831 [details]
fix proposal

fixes pcnet32_ethtool_ioctl function to only rely on result from mii_link_ok()
when mii is actually available. In cases where mii is not available, assume
link is okay as this is the only way we're ever going to get this working!!!

Please try it out and let me know if it is usable! If it is, i'll try to get it
submitted upstream!

Comment 15 Thomas M Steenholdt 2004-02-19 13:59:20 UTC
It looks as if it has been a while since anyone touched that driver,
so theres a good chance it'll work on earlier versions (including 2.4)
as well... This fix was tested on kernel 2.6.2-1.87 and only under
VMware, where it works!

Comment 16 Bernd Bartmann 2004-02-19 14:01:45 UTC
What's that binary garbage patch attachment?

Comment 17 Thomas M Steenholdt 2004-02-19 14:15:26 UTC
Thats a gzipped patch file... the only reason i gzipped it was because
I had to move it across some windows boxes and wanted to make sure i
didn't get any encoding problems (just as a safety precaution) sorry
for the inconvenience - I should have added that to the description!

Comment 18 Thomas M Steenholdt 2004-02-21 21:56:30 UTC
I've created a second version of the patch for this problem!

I've send it to maintainer and am awaiting some comments...

The new version will actually detect link on the device and does not
just assume that the link is up!

Tested with kernel 2.6.2-1.87 under VMware and is working like a charm!

Comment 19 Thomas M Steenholdt 2004-02-21 21:59:21 UTC
Created attachment 97917 [details]
updated version of the previously submitted patch!

please note that this patch was made against pcnet32.c taken from 2.6.3-bk3
kernel snapshot.

will do proper link detection even on devices that is not mii-capable!

Comment 20 Thomas M Steenholdt 2004-02-27 13:40:41 UTC
patch tested/accepted by upstream maintainer(brazilnut@us.ibm.com). it
should be included in 2.6.3-bk9 from www.kernel.org. I don't know
about the 2.4 kernel although maintainer submitted for 2.4 as well!

Comment 21 Thomas M Steenholdt 2004-02-29 20:52:27 UTC
Fixed in rawhide kernel 2.6.3-1.116 - tested and works here

Comment 23 Sahil Verma 2004-03-19 20:30:50 UTC
This bug can be closed.

https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=104711 is a dupe.

Comment 25 Thomas M Steenholdt 2004-06-01 12:45:40 UTC
The fix is in vanilla kernel trees for both 2.4 and 2.6 and has been
for a while, please just close this bug

Comment 26 Dave Jones 2004-06-14 23:29:11 UTC
*** Bug 115598 has been marked as a duplicate of this bug. ***

Comment 27 Bernd Schmidt 2004-06-22 15:50:14 UTC
Reopening and changing product to RHEL3, so we can track this for the
next QU.

Comment 34 Andrew Robinson 2004-09-22 17:05:17 UTC
I'm getting this bug in RHEL 3 AS U3. I've traced the problem to the 
check_link_down function defined in /etc/sysconfig/network-
scripts/network-functions file. It has something to do with 
check_mii_tool or check_ethtool. Serendipitously, I found that if I 
run check_link_down twice, it succeeds the second time. I don't know 
what this means, but I hope it provides a clue to the developer. This 
seems to be the basis of VMWare's workaround. Before I saw their 
solution, I solved it by adding a preceding call to check_link_down 
in /sbin/ifup. This works, but it is a pain because it is an extra 
step in installing a whole lot of RHEL 3 boxes. This is my 
modification to /sbin/ifup:
if check_link_down ${DEVICE}; then
    echo $" failed; no link present. Check cable?"
    if link set dev ${DEVICE} down >/dev/null 2>&1
    exit 1


check_link_down ${DEVICE}
if check_link_down ${DEVICE}; then
    echo $" failed; no link present. Check cable?"
    if link set dev ${DEVICE} down >/dev/null 2>&1
    exit 1

Andrew Robinson

Comment 35 Thomas M Steenholdt 2004-09-22 20:19:43 UTC
The fix is made to the kernel. However i'm not sure if Red Hat has
backported the fix to the latest RHEL3AS kernel...

Comment 36 Ernie Petrides 2004-09-23 06:47:23 UTC
A fix for this problem has just been committed to the RHEL3 U4
patch pool this evening (in kernel version 2.4.21-20.10.EL).

Comment 37 John Flanagan 2004-12-20 20:54:39 UTC
An errata has been issued which should help the problem 
described in this bug report. This report is therefore being 
closed with a resolution of ERRATA. For more information
on the solution and/or where to find the updated files, 
please follow the link below. You may reopen this bug report 
if the solution does not work for you.


Comment 38 Ernie Petrides 2005-04-13 19:06:55 UTC
*** Bug 154106 has been marked as a duplicate of this bug. ***

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