Description of problem: Using kernel-2.6.17-1.2293_FC6, not much overhead was loaded: video button battery ac lp parport_pc parport. But things changed using kernel-2.6.18-1.2798.fc6: button battery asus_acpi ac scb2_flash mtdcore cfi_probe chipreg map_funcs pcspkr sbs i2c_ec parport_pc lp parport i2c_piix4 i2c_core gen_probe serio_raw video Why do you believe I need this whole mess automatically loaded? I'm accepting video as there is a graphics controller and maybe the ACPI stuff even it doesn't make sense at a server, but the rest seems more than nonsens to me. And the box has neither parport nor for Linux usable i2c/SMBus or any Asus components. There even isn't a sound card or a beeper which could be used for pcspkr. Ha and ever seen a 1U rack server supporting any type of CFI-compliant flash chips? Version-Release number of selected component (if applicable): kernel-2.6.18-1.2798.fc6 How reproducible: Buy a HP ProLiant DL360 G3, G4, G4p or G5 and install Fedora Core 6. You'll get the same mess installing Red Hat Enterprise Linux 5 when ready and not fixed... Actual results: Many unneeded kernel modules are loaded. Expected results: Only kernel modules loaded which are really needed and not just every module standing or lying around and looking a bit pretty... ;-) Additional info: The following also looks strange to me (ehci, ohci and uhci at the same time?): ehci_hcd 35533 0 ohci_hcd 25181 0 uhci_hcd 27725 0
whilst it's not the only culprit, mtd is pulling in quite a few of those modules. Why it's getting loaded is a mystery though. dwmw2?
It's allowing access to the BIOS flash chip, since a supported southbridge is detected on the PCI bus. There is a case to be made for not loading the module by default, since we don't _necessarily_ want to make it so easy for people to access their BIOS flash. So maybe we should remove the MODULE_DEVICE_TABLE() from those map drivers.
Personally, I don't see the "bug" here. Those modules are getting loaded because the default policy is to load support for detected hardware, and modules required by those supporting apparently detected hardware. Maybe it's a liberal policy, but that doesn't make it wrong :-) Can we get some more useful information about the specific box in question? I can dig out datasheets, but output from lspci -vvv and similar would be useful. Jon.
Created attachment 153740 [details] lspci -vvv
Based on the date this bug was created, it appears to have been reported against rawhide during the development of a Fedora release that is no longer maintained. In order to refocus our efforts as a project we are flagging all of the open bugs for releases which are no longer maintained. If this bug remains in NEEDINFO thirty (30) days from now, we will automatically close it. If you can reproduce this bug in a maintained Fedora version (7, 8, or rawhide), please change this bug to the respective version and change the status to ASSIGNED. (If you're unable to change the bug's version or status, add a comment to the bug and someone will change it for you.) Thanks for your help, and we apologize again that we haven't handled these issues to this point. The process we're following is outlined here: http://fedoraproject.org/wiki/BugZappers/F9CleanUp We will be following the process here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping to ensure this doesn't happen again.