Bug 150733 - RHEL 3 Update 3 dhcp fails on Dell 1750, BroadCom BCM5704
Summary: RHEL 3 Update 3 dhcp fails on Dell 1750, BroadCom BCM5704
Keywords:
Status: CLOSED WORKSFORME
Alias: None
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: kernel
Version: 3.0
Hardware: i386
OS: Linux
medium
medium
Target Milestone: ---
Assignee: John W. Linville
QA Contact: Brian Brock
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2005-03-10 00:35 UTC by Michael T. Halligan
Modified: 2007-11-30 22:07 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2005-05-04 18:40:26 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)

Description Michael T. Halligan 2005-03-10 00:35:54 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US;
rv:1.7.6) Gecko/20050223 Firefox/1.0.1

Description of problem:
When attempting to use the kickstart/netboot images for RHEL3U4, to do
a PXE install, DHCP fails. The first DHCP request works fine, and then
the linux install loads, but the linux dhcp process fails without any
error message.  This is true both with Update 3, and Update 4. The
images for Update 1 and Update 2 work fine.

Version-Release number of selected component (if applicable):
2.4.21-27.ELBOOT

How reproducible:
Always

Steps to Reproduce:
1.Pxeboot the netboot image
2. Watch the dhcp fail.

Actual Results:  Once the netboot image is loaded, the box ceases to
send out any network traffic. It sits at the network configuration screen.

Expected Results:  The server should send a DHCP message, get it's IP
address, and get it's next-server so it knows what kickstart file to grab.

Additional info:

I believe this to be a bug with the tg3 driver. This makes pxebooting
impossible.

Comment 1 Michael T. Halligan 2005-03-10 21:00:13 UTC
Correction, this doesn't make "pxebooting" impossible, because the pxeboot
process works well. It's after the pxe boot, once the redhat image is loaded,
where things fail..

Comment 2 John W. Linville 2005-03-11 15:49:43 UTC
Can you see any non-PXE DHCP traffic on the wire?  Perhaps you can
attach the output of something like tcpdump or ethereal running at the
DHCP server (hopefully on an isolated network)?  Thanks!

Comment 3 John W. Linville 2005-03-15 14:41:05 UTC
Is STP enabled on the switch port?  If so, can you disable it and try
again?

When the tg3 driver loads, it will re-init the hardware which probably
causes the link to go down.  If STP is enabled, it could take 30+
seconds for the link to become usable again.  That may be long enough
to cause DHCP to fail.

Comment 4 John W. Linville 2005-05-04 18:40:26 UTC
Closed due to lack of response.  Please reopen if the requested information 
becomes available. 


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