Hide Forgot
[This is a copy of bug 714243 but for the RHEL6 product line] Description of problem: The "sfc.ko" network driver is a kernel modules shipped within the kernel default RPM(s) that gets installed, but it is not included in the initrd for the installer. This means that Solarflare network interfaces cannot be configured at install time nor used during the install e.g. for iSCSI based installations Version-Release number of selected component (if applicable): RHEL6.0 or 6.1 install DVD image, (and pxeboot and xen initrd images) How reproducible: 100% (or by inspection) Steps to Reproduce: 1. Install a Solarflare network adapter (PCI vendor ID 1924) 2. Boot from RHEL6.X 64 bit media (likely to affect other versions as well) 3. Continue through installation Actual results: No "sfc.ko" driver is loaded even though PCI devices with matching ID are present. No option to configure ethX devices that correspond to network ports on the Solarflare network adapter Expected results: Options to configure all ethX devices that correspond to network ports on the enumerated Solarflare network adapter(s). This is what happens for nearly all other networking adapters during install. Additional info: Note I work for Solarflare Communications but I followed the instructions on the account creation page and used a secondary e-mail address (considering this is a public forum). Please note that sfc.ko has a small number of dependencies on other modules $ grep sfc modules.dep modules.dep:sfc: i2c-algo-bit mdio i2c-core mtdpart mtdcore I have identified these places where there are already a number of network adapter modules present on the install ISO: images/pxeboot/initrd.img I also note that the "pci.ids" file does not have vendor (1924:) or device IDs for the network adapters that the sfc.ko driver supports.
anaconda doesn't need to list most kernel modules explicitly anymore. As long as sfc.ko is listed in modules.networking (it doesn't appear to be), we'll pick it up. Reassigning.
Looking at the kernel spec (admittedly for a Fedora14 kernel) I found: ============================== collect_modules_list networking \ 'register_netdev|ieee80211_register_hw|usbnet_probe|phy_driver_register' ============================== sfc.ko calls "register_netdevice()" rather than "register_netdev()" which is why it does not end up in modules.networking Adding register_netdevice into the above call certainly adds sfc.ko to modules.networking; but as I noted in the original comment sfc.ko depends on "mtd,i2c-core,mdio,i2c-algo-bit" and I am unsure what ensures that they are also included in the initrds
This should be a pretty easy fix. I think once we add register_netdevice to modules.networking that should do it. I'll test to be sure.
Adding 'register_netdevice' to the collect_modules_list line is pretty easy and does add sfc.ko to modules.networking. The trick is making sure the other modules are included. The output of 'modinfo sfc' indicates that these modules are needed for sfc.ko to load: depends: i2c-core,mdio,i2c-algo-bit None of these modules show up in any of the modules.* files, so some symbols will need to be added to account for them. It looks like adding 'i2c_add_numbered_adapter' will give me 'i2c-algo-bit.ko' (and 'i2c-algo-pca.ko') in the initrd. These are pretty small 28k total, so that seems reasonable. There seems to be some magic with how mdio is chosen to load and I haven't quite figured it out yet. Since other drivers (like ixgbe) depend on mdio it must get included via some others means.
Sorry I forgot to mention the 'i2c-core' module. I think that will get loaded automatically since we are adding i2c-algo-bit and it depends on i2c-core, but maybe not. I need to revisit how this works and see if I can remember how to build a test initrd like the installer will use (rather than the one dracut will use that has the kitchen-sink).
OK, so I picked apart the installer initrd from 6.1 and see that mdio, i2c-core, and i2c-algo-bit are already included: # find . -type f | egrep 'mdio|i2c' ./net/mdio.ko.gz ./i2c/i2c-core.ko.gz ./i2c/algos/i2c-algo-bit.ko.gz ./i2c/busses/i2c-via.ko.gz ./i2c/busses/i2c-stub.ko.gz This means we just need to add 'register_netdevice' to the modules.networking file.
This request was evaluated by Red Hat Product Management for inclusion in a Red Hat Enterprise Linux maintenance release. Product Management has requested further review of this request by Red Hat Engineering, for potential inclusion in a Red Hat Enterprise Linux Update release for currently deployed products. This request is not yet committed for inclusion in an Update release.
qa_ack+. We do not have Solarflare network adapater in beaker. It would be better to contact the customer to verify this bug, for us. Will the customer test this bug for us?
(In reply to comment #10) > We do not have Solarflare network adapater in beaker. It would be better to > contact the customer to verify this bug, for us. Will the customer test this > bug for us? Yes; someone at Solarflare would be available to test this Would you supply updated installation media? or an updated pxeboot initrd+kernel Many thanks
Patch(es) available on kernel-2.6.32-192.el6
On latest livecd (rhevh-6.2-20111010.0.iso) image found a 2.6.32-206.el6.x86_64 kernel, with the ThinkPink ~ 3553 $ gzip -dc /mnt/isolinux/initrd0.img | cpio -itv| fgrep sfc drwxr-xr-x 2 root root 0 Oct 10 15:45 lib/modules/2.6.32-206.el6.x86_64/kernel/drivers/net/sfc -rwxr--r-- 1 root root 329600 Oct 4 18:39 lib/modules/2.6.32-206.el6.x86_64/kernel/drivers/net/sfc/sfc.ko sfc module in the initrd0.img. This is OK for SanityOnly. I don't know a bootable image is ever built with the 192.el6 kernel, will investigate further.
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. http://rhn.redhat.com/errata/RHSA-2011-1530.html