Red Hat Bugzilla – Bug 153176
forcedeth nForce driver not selectable when manually choosing a network module
Last modified: 2015-01-04 17:18:24 EST
From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.6) Gecko/20050302 Firefox/1.0.1 Fedora/1.0.1-1.3.2 Description of problem: Using noprobe option to start an install, or a network method and forcedeth not automatically detected, one will get prompted to manually choose a network driver. forcedeth driver is not one of these options. Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: 1. Start installer w/ noprobe 2. Browse list of network drivers Actual Results: Forcedeth not found. Expected Results: forcedeth 'nForce Ethernet Driver' should be available Additional info: Related to this bug, the network chip on the MSI K8N Neo Platinum/SLI is not automatically detected. I do not have the PCI ID as of yet to add to initrd, I will file a seperate bug on this issue.
Upon closer look, it appears that the driver DOES load automatically, however the driver is unable to see the hardware device. Perhaps this is a kernel bug instead. Installing from CD to see what happens once OS is installed.
Module DOES seem to function inside the installed os. Seems like the problem is that it doens't work during the installer. Not sure where this bug goes then.
The problem is that the device doesn't show up as a network device according to it's PCI device class.
Hacked around in kudzu-1.1.115-1. Yuck.
(In reply to comment #5) > Hacked around in kudzu-1.1.115-1. Yuck. May I ask what that hack was? I'd like to try in on RHEL4 and FC3
Index: pci.c =================================================================== RCS file: /usr/local/CVS/kudzu/pci.c,v retrieving revision 1.121 retrieving revision 1.123 diff -u -r1.121 -r1.123 --- pci.c 22 Apr 2005 22:05:18 -0000 1.121 +++ pci.c 29 Apr 2005 15:42:12 -0000 1.123 @@ -903,6 +905,10 @@ free(dev->driver); dev->driver = strdup("8139cp"); } + /* nForce4 boards show up with their ethernet controller + * as a bridge; hack it */ + if (dev->vendorId == 0x10de && dev->deviceId == 0x0057) + devtype = PCI_CLASS_NETWORK_ETHERNET; dev->pcidom = p->domain; dev->pcibus = p->bus; dev->pcidev = p->dev; You can also put a pci quirk in the kernel to change the class there (to make it appear correctly to *all* userland tools); I don't have that patch in front of me
Thanks! I was hoping to implement this change in anaconda so loader/init in my pxe initrd can use the nForce network device to install via nfs. Will this fix make anaconda work right if I patch/rebuild/install kudzu, then rebuild anaconda-runtime and use the new loader and init in my initrd? I'm curious how anaconda uses kudzu in a pxe boot to anaconda environment. Thanks again!
Correct. (You only need the loader, not init)
You probably want the new kudzu python module in stage2 as well.
I couldn't find a pci.c in the anaconda src to apply the patch to. I guess I'd need some sort of python workaround to do the same thing you did in pci.c. Suggestions are welcome as I am not well versed in python.
The pci.c is in kudzu; you'd need to apply/build/install that before rebuilding the loader.
Sorry to keep on with this.... I applied the patch to kudzu 1.1.95.10-1, built it and then installed the kudzu and kudzu-devel rpms that were created. I then built anaconda 10.1.1.17-1, then installed the newly created anaconda and anaconda-runtime rpms. Next put /usr/lib/anaconda/loader/loader into my initrd that I pxe boot with. No joy. forcedeth loads and eth0 is bound to 0000:00:0a.0, but keep getting the "no driver found" window where I can use a driver disk. * getting kickstart file * no network devices in choose network device! * no network drivers for doing kickstart I'll attach my pci.c from kudzu. Maybe I put the patch in the wrong place?
Created attachment 114806 [details] pci.c from kudzu 1.1.95-10 (RHEL4)
It looks ok. Note that the RHEL 4 U1 kernel will have the pci quirk for this, solving this that way.