Bug 68442 - no dhcp reply during kickstart when using tg3 module on Dell 2650
no dhcp reply during kickstart when using tg3 module on Dell 2650
Status: CLOSED RAWHIDE
Product: Red Hat Linux
Classification: Retired
Component: anaconda (Show other bugs)
7.3
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Jeremy Katz
Mike McLean
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2002-07-10 04:55 EDT by Mads Vaagland
Modified: 2014-01-21 17:48 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2003-05-25 10:50:51 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 Mads Vaagland 2002-07-10 04:55:24 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 Galeon/1.2.5 (X11; Linux i686; U;) Gecko/20020613

Description of problem:
When kicstaring Dell PowerEdge 2650 boxes, with the onboard Broadcom
gigabit-nic, dhcp doesn't work. This only happens during kickstart, with  box
connected to autonegotiation switch. The use of dhcp during manual installation
works fine. This setup works flawless on out PowerEdge 2450 and 2550 boxes,
which have onboard intel eepro100 NICs.

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


How reproducible:
Always

Steps to Reproduce:
1. Create a custom kickstart diskette containing the tg3 module used by the
broadcom gigabit cards. This module is found in the drvnet bootimage, and should
be copyed into the bootnet image.
2. Perform a kickstart with the box connectet to a link negotiation capable switch.


	

Actual Results:  Pump failes to request a dhcp lease after the installer has
loaded the tg3.o module. Installer returnes to interactive installation, and
selecting dhcp to configure the nic during interactive installation works fine.
Looking at the system log (Alt-F4) when dhcp has failed, it seems that
pump starts querying for dhcp before the NIC is done negotiating link-speed.
If my assumptions are correct, this would explain why dhcp works fine
the second time (during interactive installation).
I've tryed connecting a 10Mbit half duplex hub in between the switch and the
machine. With the hub connected, linkspeed is forced to 10Mbit half duplex, and
kickstart works fine. Comparing the system log, I get the "eth0: link up"
message prior to output from pump when connected throug 10Mbit hub, but
connected directly to 100Mbit or 1Gbit switch port, the "eth0: link up" message
appears after pump has started sending dhcp discover.
I have tryed both onboard NIC's, with the same result.

Expected Results:  I would expect pump to get dhcp reply during kickstart when
connected to a link negotion capable partner, not only during manual
installation or by connecting to a forced link speed partner.

Additional info:

System setup is a Dell PowerEdge 2650, with broadcom onboard 10/100/1000Mbit
NICs, connected to 1Gpbs Cisco Catalyst 4006 switch-port. I have also tryed
connecting to 10/100Mbit ports on the same switch, and 10/100Mbit ports on a
Cisco Catalyst 3500 Series XL switch. All with same result.

relevant parts of systemlog from failed kickstart attempts:
<6> tg3.c: v0.97 (mar 13, 2002)
<6> PCI: Assigned IRQ7 for device 03:06.0
<6> eth0: Tigon3 [partno(BMC95701A10) rev 0105 PHY(5701)] (PCIX:133MHz:64-bit)
10/100/1000BaseT Ethernet 00:065b:3e:f2:de
<6> PCI: Assigned IRQ11 for device 03:08.0
<6> eth1: Tigon3 [partno(BMC95701A10) rev 0105 PHY(5701)] (PCIX:133MHz:64-bit)
10/100/1000BaseT Ethernet 00:065b:3e:f2:df
<135> Jul 10 07:42:06 loader: PUMP: sending discover <135> Jul 10 07:42:06
loader: breq: opcode: 1 <135> Jul 10 07:42:06 loader: breq: hw: 1 <135> Jul 10
07:42:06 loader: breq: hwlength: 6 <135> Jul 10 07:42:06 loader: breq: hopcount:
0 <135> Jul 10 07:42:06 loader: breq: xid: 0x3e5b27fb <135> Jul 10 07:42:06
loader: breq: secs: 0 <135> Jul 10 07:42:06 loader: breq: ciaddr: 0.0.0.0 <135>
Jul 10 07:42:06 loader: breq: server_ip: 0.0.0.0 <135> Jul 10 07:42:06 loader:
breq: bootp-gw_ip: 0.0.0.0 <135> Jul 10 07:42:06 loader: breq: hwaddr: <135> Jul
10 07:42:06 loader: breq: servername: <135> Jul 10 07:42:06 loader: breq:
bootfile: <135> Jul 10 07:42:06 loader: breq: vendor: 0x63 0x53 0x82 0x63 <135>
Jul 10 07:42:06 loader: breq: vendor: 53  1 0x01 <135> Jul 10 07:42:06 loader:
breq: vendor: 0xff
<4> eth0: Link is up at 1000Mpbs, full duplex
<4> eth0: Flow control is on for TX and on for RX
Comment 1 Seth Vidal 2002-07-10 23:08:26 EDT
I can confirm I've seen this same problem on 3com gigabit nics in non-dell machines.

Also on SMC gig nics. (model number illuding me at the moment)
Comment 2 Jeremy Katz 2003-01-03 00:26:49 EST
Added code to CVS so that we check for an active link before doing the DHCP
reply and give it five seconds to settle before trying the DHCP request.
Comment 3 Brent Fox 2003-05-25 10:50:51 EDT
I'm going through Bugzilla closing some bugs that have been marked as Modified
for some period of time.  I believe that most of these issues have been fixed,
so I'm resolving these bugs as Rawhide.  If the bug you are seeing still exists,
please reopen this report and mark it as Reopened.

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