Bug 149682 - tg3 module in RHEL ES4.0 does not work properly
Summary: tg3 module in RHEL ES4.0 does not work properly
Alias: None
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: kernel   
(Show other bugs)
Version: 4.0
Hardware: i386
OS: Linux
Target Milestone: ---
: ---
Assignee: John W. Linville
QA Contact:
URL: http://evuraan.blogspot.com/2005/02/r...
: 149977 (view as bug list)
Depends On:
TreeView+ depends on / blocked
Reported: 2005-02-25 01:43 UTC by Anu Matthew
Modified: 2007-11-30 22:07 UTC (History)
7 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2005-10-10 18:01:13 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description Anu Matthew 2005-02-25 01:43:40 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0

Description of problem:
The tg3 (tg3.ko) module included in the CD-1 of RHEL ES4.0 does not work. 

While kickstarting, it fails to get a DHCP response. Even if IP is assigned manually, it fails to get onto the network. 

First time it fails, the message is 

pump told us: No DHCP reply recieved

If dhcp is retried, it comes back with a slightly different message:

pump told us: SIOCSIFADDR: No such device

(My dhcp setup is correct, it works fine with the updated ES3.0 media)

Finally, if Ip is assigned manually, it still fails to get onto the network:

loader: failed to set default route: Network in unreachable 

Version-Release number of selected component (if applicable):
RHEL ES 4.0 release 1.0 

How reproducible:

Steps to Reproduce:
1. (On a machine with Broadcom 5703X NICs)  Boot from rhel es4.0 boot cd (assuming that you already have the dhcp setup), and at boot prompt, go "ks=http://whatever/ks.cfg ksdevice=eth0", it tries to find an IP adderss and there it fails 
2. Or, boot from rheles4.0, and try assigning IP manually, it still fails to get to network. 

Actual Results:  Failed in both cases. the dhcp server sees no request from the cards, switches see a lot of errors. 

Expected Results:  a) Should have gotten a dhcp response when trying dhcp
b) Connectivity to the kickstart server

Additional info:

Please refer to http://evuraan.blogspot.com/2005/02/rhel-es-40-release-1-miseries-while.html, I have uploaded the screenshots...

Comment 1 Trond H. Amundsen 2005-02-25 14:09:00 UTC
Just a "mee too". I get the exact same behaviour on a newly purchased
Dell Optiplex GX280, using the onboard Broadcom controller.

Comment 2 Chris Lumens 2005-03-01 18:52:39 UTC
*** Bug 149977 has been marked as a duplicate of this bug. ***

Comment 3 Anu Matthew 2005-03-01 22:26:41 UTC
For the record, this issue is also present in AS 4.0 too (release 1) . 

Comment 4 teuben 2005-03-01 22:39:16 UTC
Also for the record (as listed in now duplicated Bug 149977) I then used
the bcm5700-7.3.5.tar.gz driver from broadcom.com and got
the card to work fine (in FC3).

Comment 5 Carl Boberg 2005-03-15 21:30:14 UTC
Seen similar problem on RHAS4 on DELL PE2550 with builtin broadcom
gigabit card.
It gets network for a while but then it dies and it blurbs on screen
some messages sort of like "screaming panic", "nobody cared?", "try
booting with acpi=off"

It got me bloody pissed since RHAS3 on the same machine worked really
well and this showed up during an upgrade...

Such is life i guess...

Comment 6 Joshua Daniel Franklin 2005-03-21 21:43:08 UTC
I had this problem and ended up installing with "linux text askmethod"
(network worked fine, I just had to enter what was in my kickstart file by hand).
For some reason the regular graphical install had the same network problem,
though I could ifconfig eth0 with the shell and then it would work.

The sad thing is that if I had a shell during stage1 I could have just 
configured eth0 myself with ifconfig since this seems to be just a pump

Comment 7 Steve Cleveland 2005-04-13 22:02:23 UTC
I haven't had a problem with gx280's (with the broadcom card using the tg3
driver), but I have had it with HP ProLiant DL145's (AMD64 using the x86_64
kernel) with tg3 and Dell gx270's (e1000).

One way I found to work around the problem is to specify the IP settings in the
pxelinux.cfg/default file or on the pxelinux prompt.  Not ideal, but I'm able to
use my kickstart files.

Comment 8 John W. Linville 2005-04-25 18:14:07 UTC
I have test kernels w/ an update tg3 driver available here: 
Would you mind trying your PXE/kickstart install using the kernels from there?  
Please post the results.  Thanks! 

Comment 9 Trond H. Amundsen 2005-05-03 08:17:00 UTC
John, I've tried the 2.6.9-6.41.EL.jwltest.20.i686 kernel, but I don't get it to
work. The install process stops abruptly after the kernel has been loaded, and
the machine is locked (i.e. the keyboard doesn't work anymore). Maybe I didn't
do it right, this is new territory for me. Here's what I did to create the new
boot image, in case you have comments:

  1. Picked out boot.iso from the distribution, loop-mounted it and copied all
     files to /tmp/bootcd-test

  2. Installed the test kernel via rpm, and copied
     /boot/vmlinuz-2.6.9-6.41.EL.jwltest.20 to /tmp/bootcd-test/isolinux/vmlinuz
     (i.e. replaced the vmlinuz file from boot.iso with the one from the test

  3. Created a new bootable iso file with
     'mkisofs -o /test.iso -b isolinux/isolinux.bin -c isolinux/boot.cat \
     -no-emul-boot -boot-load-size 4 -boot-info-table -l -R -r /tmp/bootcd-test'
     and burned test.iso onto a CD.

The machine (a new Dell Optiplex GX280) was booted with the new image with the
results described above. The weird thing is that the install process didn't seem
to want to try and fire up the network at all. The install process stopped
asking for language, which, if I remember correctly, it shouldn't do since this
is spesified in the kickstart file. The command given to isolinux was 'linux

Weirder still, the regular boot.iso from the distribution worked with the same
machine on a different network, when using DHCP instead of a spesified IP
address. I'm at a loss here :)

Comment 10 John W. Linville 2005-05-03 17:25:44 UTC
I think it is not working because it doesn't have the correct modules for the 
new kernel.  Bear with me, this could get a little rough... :-) 
# All as root... 
cd /tmp/bootcd-test/isolinux 
zcat initrd.img > /tmp/initrd 
mkdir /mnt/initrd 
mount -o loop /tmp/initrd /mnt/initrd 
cd /tmp 
mkdir -p 2.6.9-6.41.EL.jwltest.20/i686 
zcat /mnt/initrd/modules/modules.cgz | cpio -id 
cd 2.6.9-6.37.EL/i686 # U1-Beta -- change if necessary for your CD image 
for i in * 
 cp `find /lib/modules/2.6.9-6.41.EL.jwltest.20 -name $i` \ 
cd - 
find 2.6.9-6.41.EL.jwltest.20 | cpio -o H crc | gzip -9 \ 
 > /mnt/initrd/modules/modules.cgz 
rm -rf 2.6.9-6.37.EL 
rm -rf 2.6.9-6.41.EL.jwltest.20 
cd /tmp/bootcd-test/isolinux 
umount /mnt/initrd 
gzip -c9 /tmp/initrd > initrd.img 
rm /tmp/initrd 
The above should come between steps 2 and 3 from comment 9.  Simple, eh? :-) 
I appreciate your help!  Thanks! 

Comment 11 Trond H. Amundsen 2005-05-20 15:49:38 UTC
Simple and intuitive, yes ;) Anyway, I've tried your recipe with the
2.6.9-6.46.EL.jwltest.27.i686 kernel, and it doesn't work. Same result as the
stock rhel4 kernel. The log shows the following (hand-written from screen since
I don't have a shell that early in the boot process, and the machine doesn't
have a floppy drive anyway, which is kinda annoying):

<6>tg3: eth0: Link is up at 100Mps, full duplex
<6>tg3: eth0: Flow control is on for TX and on for RX

So far so good, but then it says:

<131>May 20 13:00:34 loader: failed to set default route: Network is unreachable

As stated in comment #9, the network initialization only fails if the network
segment doesn't have a DHCP server, and you are prompted for IP address etc.
When using DHCP, everything works as expected. My money is on some weird timing
problem, but I really don't have a clue..

PS. Sorry for the delay, I had to wait for a machine to become available.

Comment 12 John W. Linville 2005-06-01 14:05:13 UTC
I have heard of some issues recently w/ the firmware on some tg3 cards from 
HP.  Would you mind trying to find a tg3 firmware update from HP, and then 
giving the kernels from comment 8 another shot? 
Sorry for the PITA...wierdness can be difficult to debug... :-) 

Comment 13 J. Parsons 2005-06-02 21:37:35 UTC
I'm encountering this problem on a Dell box with Broadcom cards.  This box was running fine under 
RHEL3 ES; it is unable to see the network under RHEL4 ES (and so I can't kickstart this system).

Comment 14 John W. Linville 2005-06-10 19:20:07 UTC
Looking again at comment 5, has (all of) you tried booting w/ "acpi=off" on 
the kernel command line?  That is especially appropriate for those whose boxes 
worked fine under RHEL3 but not RHEL4... 
Please post the result of using "acpi=off"...thanks! 

Comment 15 J. Parsons 2005-06-12 18:45:33 UTC
I just tried a kickstart with acpi=off; the card was still unable to DHCP an address.  The card does work 
fine after installation -- it seems to be just kickstarting from the CD that's broken.

Comment 16 Christopher T. Beers 2005-06-20 20:23:27 UTC
Just a quick update.  After banging my head against the wall today running into the same issues described 
originally (DHCP, no route, Broadcom cards) on an IBM XServies X336 machine using RHEL 4 AS Update 1 
fixes my problem.

I see the release notes include an updated driver, so maybe this fixes others issues

Comment 17 John W. Linville 2005-06-21 12:29:24 UTC
As everyone else tried using RHEL4 U1? 

Comment 19 John W. Linville 2005-06-28 17:47:51 UTC
New test kernels available at the same location as comment 8.  These include 
an update to tg3 version 3.32-rh.  Please give them a try to see if they work 
w/ PXE booting...thanks! 

Comment 20 John W. Linville 2005-07-06 19:44:53 UTC
New test kernels available, w/ tg3 updated to 3.33-rh...  

Comment 23 John W. Linville 2005-10-10 18:01:13 UTC
Closed due to lack of response.  Please re-open when the requested information 
becomes available...thanks! 

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