Bug 164913 - HP xw9300 does not have network support with latest RHEL3U6
HP xw9300 does not have network support with latest RHEL3U6
Status: CLOSED CANTFIX
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: kernel (Show other bugs)
3.0
x86_64 Linux
medium Severity medium
: ---
: ---
Assigned To: John W. Linville
Brian Brock
: FutureFeature
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2005-08-02 12:00 EDT by Bill Peck
Modified: 2007-11-30 17:07 EST (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-11-01 14:08:01 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
lspci info (3.58 KB, text/plain)
2005-09-15 18:12 EDT, Bill Peck
no flags Details
screenshot of console3 (162.52 KB, image/png)
2005-09-27 10:52 EDT, Bill Peck
no flags Details

  None (edit)
Description Bill Peck 2005-08-02 12:00:32 EDT
Description of problem:

HP xw9300 does not have network support with latest RHEL3U6.  I don't believe
this has ever had network support in RHEL3.

Version-Release number of selected component (if applicable):
rel-eng/RHEL3-U6-re0801.0/x86_64/x86_64-WS


Additional info:
http://rhts.lab.boston.redhat.com/cgi-bin/rhts/test_log.cgi?id=500092

+--------------------+ Dynamic IP +---------------------+
|                                                       | 
| Sending request for IP information for eth0...        | 
|                                                       | 
+-------------------------------------------------------+ 
                                                         

                                                         
                                                          
                                                          
                                                          
                                                          
                                                         

+--------------------+ Configure TCP/IP +---------------------+
|                                                             | 
| Please enter the IP configuration for this machine. Each    | 
| item should be entered as an IP address in dotted-decimal   | 
| notation (for example, 1.2.3.4).                            | 
|                                                             | 
|        [*] Use dynamic IP configuration (BOOTP/DHCP)        | 
|                                                             | 
|           IP address:           ___________
Comment 1 John W. Linville 2005-08-03 09:59:41 EDT
Need an lspci for this machine... 
Comment 2 Bill Peck 2005-09-15 18:10:25 EDT
Some more info on this problem...

Anaconda install does not work via dhcp or by setting a static IP.  This we
knew.  But, if I do a cd install and then bring the network up after the install
it works fine.  

Also, if we turn spanning tree off on the port we can install via the network
with no problems.

So this definatly seems like an Anaconda bug to me.

I'll attach the lspci info as well
Comment 3 Bill Peck 2005-09-15 18:12:02 EDT
Created attachment 118872 [details]
lspci info
Comment 4 Ernie Petrides 2005-09-15 21:23:12 EDT
Reassigning to "anaconda" component based on comment #2.
Comment 5 Jeremy Katz 2005-09-15 21:40:37 EDT
Having spanning tree enabled _CAN NOT WORK_ without imposing delays of
approximately a minute on all users on all network bringups.  This is not
acceptable.  If you are using spanning tree, then portfast *MUST* be enabled on
the port.
Comment 6 Bill Peck 2005-09-16 10:45:05 EDT
Let me explain some more details since I don't know network details at this
level very well.

With portfast on Anaconda fails, with portfast off Anaconda succeeds. 
Using the same network port with another machine it works (portfast on).
Comment 7 Jeremy Katz 2005-09-19 14:16:11 EDT
I wonder if this is related to bug 167674, then.  Definitely sounds more like a
driver bug than instaler
Comment 8 Ernie Petrides 2005-09-19 19:46:42 EDT
Dumping back into Linville's lap.
Comment 9 John W. Linville 2005-09-20 13:38:43 EDT
I'm planning a forcedeth driver update for RHEL3.  The update includes the 
patch from bug 167674.  Test kernels are available here: 
 
   http://people.redhat.com/linville/kernels/rhel3/ 
 
Jeremy, will Bill be able to use my test kernels to get far enough w/ anaconda 
to know whether or not things are working?  Can you advise?  Thanks! 
Comment 10 Jeremy Katz 2005-09-20 13:44:52 EDT
Not without a tree -- the module will need to be loaded and as its in the initrd
and not the vmlinuz, that gets tricky.
Comment 15 Bill Peck 2005-09-20 16:34:32 EDT
Just tried installing with the tree Jeremy mentioned above.  I get these errors.

/tmp/forcedeth.o: unresolved symbol dev_activate
/tmp/forcedeth.o: unresolved symbol dev_deactivate
failed to insert /tmp/forcedeth.o
Comment 16 John W. Linville 2005-09-20 19:53:52 EDT
I'm terribly sorry.  You are the victim of a recently added (and apparently 
busted) patch.  I have revamped the patch and rebuilt.  I have new test 
kernels available now.  Thanks again! 
Comment 19 Bill Peck 2005-09-21 10:12:24 EDT
ummm..  I'm still getting the same error on boot.

These are the initrd.img and vmlinuz I'm using...

[root@rhts-results pxeboot]# ls -l
/mnt/porkchop/redhat/devel/katzj/i386/i386/images/pxeboot
total 3380
-rw-r--r--  6 root root 2544159 Sep 20 20:44 initrd.img
-rw-r--r--  2 root root     288 Sep 20 20:44 README
-rw-r--r--  6 root root  900757 Sep 20 20:44 vmlinuz
Comment 20 John W. Linville 2005-09-21 15:36:06 EDT
Apparently there was a problem w/ rebuilding Jeremy's tree.  So, your second 
test was actually the same kernel as before. :-( 
 
Hopefully Jeremy will get a chance to spin another tree for us before too 
long... :-) 
Comment 21 Bill Peck 2005-09-21 15:41:13 EDT
yeah.. I spoke to jeremy this morning..  last build he tried failed to generate
a vmlinuz because of the size.
Comment 23 Bill Peck 2005-09-27 10:50:06 EDT
Jeremy did build a new tree, he just didn't post anything here.

I tried that tree and it does load the driver now but I'm still stuck with no
dhcp working.  Here is the output from console 2:

* need to set up networking
* going to pick interface
* going to do getNetConfig
* waiting for link...
* 0 seconds.
* pump told us: No DHCP reply received
* waiting for link...
* 0 seconds.
* pump told us: No DHCP reply received

I tried to get an address twice.

I'm going to attach console3 output as a picture since its a lot of information.


I also assigned it its address statically and that allows me to go to the nfs
server page but it won't mount the nfs server, and pinging the static address
shows its not up.
Comment 24 Bill Peck 2005-09-27 10:52:01 EDT
Created attachment 119297 [details]
screenshot of console3
Comment 25 John W. Linville 2005-09-27 11:15:57 EDT
What does the "0 seconds" represent?  I hope it is waiting longer than that  
for the DHCP reply...?  
  
Why do we still use pump for the installer, anyway?  
  
Comment 23 suggests that the forcedeth driver is not working for you at all.   
Is that so?  Wasn't it working previously at least "if we turn spanning tree 
off on the port we can install via the network with no problems"? 
Comment 26 Jeremy Katz 2005-09-27 11:34:54 EDT
0 seconds is the amount of time that we waited for the ethernet adapter to
report that it had a valid link (via ethtool or mii, whichever is supported).

We still use pump in the installer because there is _NOTHING_ else which is a
library and a library is pretty much required for the statically linked, no
external binaries loader :-)
Comment 27 Bill Peck 2005-09-27 11:48:46 EDT
I've tried the following installs:

nightly/rawhide-20050927/i386
nightly/RHEL4-U2-re0926.nightly/x86_64/x86_64-AS
jeremy's rhel3 build above (i386)

All of the above fail to get dhcp.

I have rhel4 x86_64 installed on the machine (When it was in jeff burkes cube it
installed over the network fine).  When I boot that distro up it brings the
network up correctly everytime it boots.  This is using the same network cable
and port which fails for the above installs.

If networking works after install it should work for install.

Comment #25 - if we turn off fast port then anaconda brings the interface up. 
Which seems odd since Jeremy states it needs to be on for spanning tree.
Comment 28 John W. Linville 2005-09-27 13:28:17 EDT
That sounds more like a portfast problem to me.  I would have to agree with 
Jeremy, turning portfast off as a solution sounds counter-intuitive. 
 
Do you have access to the statistics for that individual switch port?  Can you 
observe those statistics while anaconda attempts to bring-up the port?  I'd be 
interested to know if they are getting through to the port.  Similarly, 
watching for the requests at the server might be useful as well. 
Comment 29 John W. Linville 2005-11-01 14:08:01 EST
Closed due to lack of response.  Please reopen when the requested information 
becomes available...thanks! 

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