Bug 156688 - network installation not possible with the forcedeth driver
network installation not possible with the forcedeth driver
Status: CLOSED CANTFIX
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: kernel (Show other bugs)
4.0
x86_64 Linux
medium Severity high
: ---
: ---
Assigned To: John W. Linville
Brian Brock
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2005-05-03 08:20 EDT by Udo Seidel
Modified: 2007-11-30 17:07 EST (History)
8 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-10-05 09:14:33 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 Udo Seidel 2005-05-03 08:20:34 EDT
Description of problem:
Network based installation of a HP xw9300 with RHEL4 is not possible since the
the NForce Ethernet controller is not recognized as NIC.

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

anaconda-10.1.1.13-1

How reproducible:

Always


Steps to Reproduce:

Boot with the installation medium and try to install via NFS/FTP/HTTP

  
Actual results:
anaconda logs:

loaded forcedeth from /modules/modules.cgz
inserted /tmp/forcedeth.ko
load module set done
getting kickstart file
no network devices in choose network device
no network drivers for doing kickstart
unable to bring up network


Expected results:

Initialization of the NIC and installation via NFS/FTP/WWW

Additional info:
Comment 2 Jim Paradis 2005-05-03 19:15:24 EDT
Yes, we committed to supporting this for HP.  It's a very hot platform for them,
and forcedeth is the built-in ethernet.

I did some digging and I don't believe this is an installer issue, not a kernel
issue.  Note that it loads the driver without error.  In fact, if I boot the
*same* installer to rescue mode it sees the ethernet controller just fine.

I added a PCI ethernet controller to my Viper and tried to boot to an NFS
install.  At the anaconda welcome screenI switched to the bash console and
attempted to bring up the forcedeth (eth0).  I got the following:

~/bin/sh-3.00# pump -i eth0
Traceback (most recent call last):
  File "/usr/bin/pump", line 30, in ?
    ns = isys.pumpNetDevice(iface, None)
  File "/usr/lib/anaconda/isys.py", line  564, in pumpNetDevice
    return _isys.pumpnetdevice(device)
SystemError: (17, 'File exists')
~/bin/sh-3.00#

In any case, the fact that the device is there and comes up in rescue mode makes
me believe this is not a kernel issue...
Comment 4 Udo Seidel 2005-05-04 02:33:26 EDT
> I did some digging and I don't believe this is an installer issue, not a 
> kernel issue.  

So do I. 


> Note that it loads the driver without error.  In fact, if I boot the
> *same* installer to rescue mode it sees the ethernet controller just fine.

Yes, I can reproduce this behavior ... are there different modules of the
installer activated during install and rescue mode.

Comment 5 Udo Seidel 2005-05-11 02:28:52 EDT
Additional Info:

The ethernet controller is recognized as bridge not as ethernet controller

$ lspci
00:00.0 Memory controller: nVidia Corporation CK804 Memory Controller (rev a3)
00:01.0 ISA bridge: nVidia Corporation: Unknown device 0051 (rev a3)
00:01.1 SMBus: nVidia Corporation CK804 SMBus (rev a2)
00:02.0 USB Controller: nVidia Corporation CK804 USB Controller (rev a2)
00:02.1 USB Controller: nVidia Corporation CK804 USB Controller (rev a3)
00:04.0 Multimedia audio controller: nVidia Corporation CK804 AC'97 Audio
Controller (rev a2)
00:06.0 IDE interface: nVidia Corporation CK804 IDE (rev a2)
00:07.0 IDE interface: nVidia Corporation CK804 Serial ATA Controller (rev a3)
00:08.0 IDE interface: nVidia Corporation CK804 Serial ATA Controller (rev a3)
00:09.0 PCI bridge: nVidia Corporation CK804 PCI Bridge (rev a2)
00:0a.0 Bridge: nVidia Corporation CK804 Ethernet Controller (rev a3)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

00:0e.0 PCI bridge: nVidia Corporation CK804 PCIE Bridge (rev a3)
00:18.0 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron]
HyperTransport Technology Configuration
00:18.1 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Address Map
00:18.2 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] DRAM
Controller
00:18.3 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron]
Miscellaneous Control
00:19.0 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron]
HyperTransport Technology Configuration
00:19.1 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Address Map
00:19.2 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] DRAM
Controller
00:19.3 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron]
Miscellaneous Control
05:05.0 FireWire (IEEE 1394): Texas Instruments TSB43AB22/A IEEE-1394a-2000
Controller (PHY/Link)
0a:00.0 VGA compatible controller: nVidia Corporation NV45GL [Quadro FX 3400]
(rev a2)
61:06.0 SCSI storage controller: LSI Logic / Symbios Logic 53c1030 PCI-X
Fusion-MPT Dual Ultra320 SCSI (rev 07)
61:06.1 SCSI storage controller: LSI Logic / Symbios Logic 53c1030 PCI-X
Fusion-MPT Dual Ultra320 SCSI (rev 07)
81:00.0 VGA compatible controller: nVidia Corporation NV45GL [Quadro FX 3400]
(rev a2)
Comment 6 Dave Jones 2005-05-15 21:18:58 EDT
will be fixed in U1.
Comment 7 John Reiser 2006-01-21 00:08:20 EST
Same problem with Fedora Core 5 test2 on x86_64: cannot perform HTTP network
installation using forcedeth driver, booting from either boot.iso or rescue.iso
CD-ROMs.  Log screens show:
   loaded forcedeth from /modules/modules.cgz
   inserted /tmp/forcedeth.ko
but the installer asks for the operator to select the driver (not found in the
list) or to use a Driver Disk.

Under RHEL4u2, lspci shows the nVidia Corporation CK8S Ethernet Controller
(10de:00df rev a2, part of the nVidia nForce3-250 chipset) as a communications
device.  Under FC5test1, lspci shows it as a Bridge, much like Comment #5. 
Ethernet works under any of {RHEL4u2, FC4, FC5test1} after installation using
CD-ROM or DVD-ROM.

The FC5test2 installer is anaconda-10.91.6.

Comment 8 John W. Linville 2006-01-23 13:04:53 EST
The requisite quirk is not in the upstream (or FC5) kernels.  I can't find any 
record of it being discussed, but I vaguely recalled disinterest in this sort 
of patch upstream.  "Fix the hardware/BIOS" is usually the response to such 
things. 
 
At any rate, please open an FC5 bug if you would like to pursue this.  
However, I'm not at all confident that this patch will be accepted upstream... 
 
http://people.redhat.com/linville/kernels/rhel4/patches/jwltest-forcedeth-quirk.patch 
Comment 9 Rainer Koenig 2006-05-08 05:18:23 EDT
I can confirm this bug is still present in RHEL4 U3! 

Same behaviour as described by Udo when trying a network installation on an
nForce4 system.

The good news is, that I can't reproduce it with Fedora Core 5, here the network
card comes up. 

Problem is occuring on both x86_64 and i386 architecture. 
Comment 10 Jim Paradis 2006-05-16 15:33:47 EDT
Can you boot an install CD in rescue mode, do a "lspci", and tell us what the
Ethernet card shows up as?

Comment 12 Rainer Koenig 2006-06-28 07:03:51 EDT
Sorry for the delay, but the machine went out of my focus for a while. Here is
the output of lspci taken from an installed RHEL4 (if you install from CDROM the
installed system works):

# lspci
00:00.0 RAM memory: nVidia Corporation C51 Host Bridge (rev a2)
00:00.1 RAM memory: nVidia Corporation C51 Memory Controller 0 (rev a2)
00:00.2 RAM memory: nVidia Corporation C51 Memory Controller 1 (rev a2)
00:00.3 RAM memory: nVidia Corporation C51 Memory Controller 5 (rev a2)
00:00.4 RAM memory: nVidia Corporation C51 Memory Controller 4 (rev a2)
00:00.5 RAM memory: nVidia Corporation C51 Host Bridge (rev a2)
00:00.6 RAM memory: nVidia Corporation C51 Memory Controller 3 (rev a2)
00:00.7 RAM memory: nVidia Corporation C51 Memory Controller 2 (rev a2)
00:02.0 PCI bridge: nVidia Corporation C51 PCI Express Bridge (rev a1)
00:03.0 PCI bridge: nVidia Corporation C51 PCI Express Bridge (rev a1)
00:05.0 VGA compatible controller: nVidia Corporation C51 PCI Express Bridge
(rev a2)
00:09.0 RAM memory: nVidia Corporation MCP51 Host Bridge (rev a2)
00:0a.0 ISA bridge: nVidia Corporation MCP51 LPC Bridge (rev a3)
00:0a.1 SMBus: nVidia Corporation MCP51 SMBus (rev a3)
00:0b.0 USB Controller: nVidia Corporation MCP51 USB Controller (rev a3)
00:0b.1 USB Controller: nVidia Corporation MCP51 USB Controller (rev a3)
00:0d.0 IDE interface: nVidia Corporation MCP51 IDE (rev f1)
00:0e.0 IDE interface: nVidia Corporation MCP51 Serial ATA Controller (rev f1)
00:0f.0 IDE interface: nVidia Corporation MCP51 Serial ATA Controller (rev f1)
00:10.0 PCI bridge: nVidia Corporation MCP51 PCI Bridge (rev a2)
00:10.1 Audio device: nVidia Corporation MCP51 High Definition Audio (rev a2)
00:14.0 Bridge: nVidia Corporation MCP51 Ethernet Controller (rev a3)
# lspci -s 14 -vv -n
00:14.0 Class 0680: 10de:0269 (rev a3)
        Subsystem: 1734:10c6
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B-
        Status: Cap+ 66Mhz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort-
<MAbort- >SERR- <PERR-
        Latency: 0 (250ns min, 5000ns max)
        Interrupt: pin A routed to IRQ 233
        Region 0: Memory at f2207000 (32-bit, non-prefetchable) [size=4K]
        Region 1: I/O ports at 8c60 [size=8]
        Capabilities: [44] Power Management version 2
                Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA
PME(D0+,D1+,D2+,D3hot+,D3cold+)
                Status: D0 PME-Enable+ DSel=0 DScale=0 PME-

The Classcode for the device 14 is "bridge" and not "network".

Comment 14 Rainer Koenig 2006-08-31 01:25:10 EDT
FYI: The FSC ESPRIMO E5615 and P5615 got a BIOS option where the customer can
chose if the NIC is operating as a network card or a bridge. By setting this
option to "network card" we can solve the problem. 
Comment 15 James Robertson 2006-08-31 02:59:17 EDT
This issue seems to be apparent on all nvidia nForce 430 and 410 chipset boards.

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