Kernel Modules

haxit · 2009-03-01 01:03:37

I get this output when I run a script finding all my modules:

agpgart.ko 
amd74xx.ko 
ata_generic.ko 
button.ko 
cdrom.ko 
ehci-hcd.ko 
evdev.ko 
fan.ko 
fb_ddc.ko 
forcedeth.ko 
hid.ko 
i2c-algo-bit.ko 
i2c-core.ko 
i2c-nforce2.ko 
ide-core.ko 
ide-pci-generic.ko 
ieee1394.ko 
k8temp.ko 
libata.ko 
nvidia.ko 
nvidiafb.ko 
ohci-hcd.ko 
ohci1394.ko 
pata_acpi.ko 
pata_amd.ko 
pci_hotplug.ko 
pcspkr.ko 
processor.ko 
sata_nv.ko 
scsi_mod.ko 
sd_mod.ko 
serio_raw.ko 
shpchp.ko 
snd-hda-intel.ko 
snd-hwdep.ko 
snd-page-alloc.ko 
snd-pcm.ko 
snd-pcsp.ko 
snd-timer.ko 
snd.ko 
soundcore.ko 
sr_mod.ko 
thermal.ko 
usb-storage.ko 
usbcore.ko 
usbhid.ko 
vgastate.ko

So now what do I do? I am trying to compile a custom, slim, bloatless kernel.

Last edited by haxit (2009-03-01 01:15:01)

stefanwilkens · 2009-03-01 01:08:58

I don't quite understand what you want from us here.

"now what should I do? > eat pizza?

haxit · 2009-03-01 01:15:17

Edited. I am trying to make a custom, slim, bloatless kernel.

B-Con · 2009-03-01 04:54:00

Those aren't all your modules, it looks like those are all the modules currently in use. If they're in use, they're in use for a reason and using them is likely not much of an option. I didn't really look through the list thoroughly, but it's possible you could do without a couple of them, but the performance benefit is likely negligible.

I'm haven't done much kernel customization, but it sounds like for what you want, your best bet is likely to recompile the kernel with those modules compiled into the kernel, instead of loaded as modules. Then look through your kernel for modules that are NOT on that list and exclude them from the kernel, either not building them at all or building them as external modules.

haxit · 2009-03-01 20:00:49

B-Con wrote:

Those aren't all your modules, it looks like those are all the modules currently in use. If they're in use, they're in use for a reason and using them is likely not much of an option. I didn't really look through the list thoroughly, but it's possible you could do without a couple of them, but the performance benefit is likely negligible.
I'm haven't done much kernel customization, but it sounds like for what you want, your best bet is likely to recompile the kernel with those modules compiled into the kernel, instead of loaded as modules. Then look through your kernel for modules that are NOT on that list and exclude them from the kernel, either not building them at all or building them as external modules.

Yes, but how can I look through the kernel efficiently.

cerbie · 2009-03-01 22:05:23

haxit wrote:

B-Con wrote:
Those aren't all your modules, it looks like those are all the modules currently in use. If they're in use, they're in use for a reason and using them is likely not much of an option. I didn't really look through the list thoroughly, but it's possible you could do without a couple of them, but the performance benefit is likely negligible.
I'm haven't done much kernel customization, but it sounds like for what you want, your best bet is likely to recompile the kernel with those modules compiled into the kernel, instead of loaded as modules. Then look through your kernel for modules that are NOT on that list and exclude them from the kernel, either not building them at all or building them as external modules.
Yes, but how can I look through the kernel efficiently.

Just make a note of all your hardware, including sensor chips and such. Include those, and most everything else you want in a kernel, and try to use it. If it doesn't work, go back to the Arch kernel. If you set your [S]ATA to built-in (if your drives are all sd*, it should be safe to do), along with filesystems you use, then you usually won't need an initrd (initramfs) image. Then, to have less bloat, make everything else you can think of (networking, sound, etc.) as modules, with automatic loading turned on.

While it doesn't always tell you modules, menuconfig isn't half bad. For checking out modules in use, use lsmod, as it alo gives you dependency info. The other thing is that if it was compiled in, but not as a module...you don't see it.

agpgart.ko -- AGP support
amd74xx.ko -- AMD IDE support
ata_generic.ko -- generic ATA driver
button.ko -- power button?
cdrom.ko -- erm...
ehci-hcd.ko -- USB
evdev.ko -- input devices through the kernel
fan.ko -- fan control/readings via ACPI???
fb_ddc.ko -- framebuffer support/info reading module?
forcedeth.ko -- you have an nVidia chipset with an ethernet port, I guess
hid.ko -- human interface device support (mouse, FI)
i2c-algo-bit.ko
i2c-core.ko
i2c-nforce2.ko -- I2C is a serial bus, and has been used for ages. Apparently your chipset needs it.
ide-core.ko
ide-pci-generic.ko -- ??? Not using libata or something?
ieee1394.ko -- got Firewire?
k8temp.ko -- Athlon64?
libata.ko -- the good stuff
nvidia.ko -- you evil sheep, you! (OK, so I use the binary driver, too...)
nvidiafb.ko -- new framebuffer.
ohci-hcd.ko -- USB again?
ohci1394.ko -- Firewire again?
pata_acpi.ko
pata_amd.ko -- drive controller stuff again
pci_hotplug.ko -- for all of the three people with big-iron servers that use it? Or is it good for suspend/resume, or something? I dunno, but I don't put it in
pcspkr.ko -- I disable this one. Only my BIOS should be beeping at me.
processor.ko
sata_nv.ko -- again, nVidia drive controller
scsi_mod.ko -- you need this for all the SATA stuff to work right, I'm pretty sure
sd_mod.ko -- ditto
serio_raw.ko -- *shrug* raw serial I/O
shpchp.ko -- some kind of hotplug thingie?
snd-hda-intel.ko -- you have HDA sound onboard.
snd-hwdep.ko
snd-page-alloc.ko
snd-pcm.ko
snd-pcsp.ko -- same as the main kernel one, I leave it out. Sometimes ALSA likes to make it the default, too, for no good reason.
snd-timer.ko
snd.ko
soundcore.ko
sr_mod.ko -- I *think* this is needed for burners these days. In general, don't skimp in the SCSI support in the config (you don't need tape or media changer support, of course)
thermal.ko
usb-storage.ko
usbcore.ko
usbhid.ko -- HID again
vgastate.ko -- usually a dependency for framebuffer stuff, but I'm not sure beyond that

Last edited by cerbie (2009-03-02 00:25:25)

haxit · 2009-03-01 23:30:47

Thanks a lot cerbie, get help!

iphitus · 2009-03-02 11:50:25

you already have one, the arch kernel is pretty bare.

Posting your kernel mods on here won't do much, it's lazy. Go through menuconfig yourself, page by page (it doesnt take that long). Read the descriptions for options you dont know about, often there's a recommended setting.

Identify your hardware using lspci and basic knowledge about your system. Sometimes kernel configuration options match kernel modules which can also help. Again this info is in the description.

If the kernel doesn't work, tweak your config in menuconfig and run make again. It should only take a few moments to rebuild if there's not too many changes. Rinse and repeat. It doesnt take long.

Last edited by iphitus (2009-03-02 11:54:03)

klixon · 2009-03-02 11:56:58

Lovely "make menuconfig" tip:
press '/' to search through [i]all/[i] config options... Nice for finding stuff that auto-enables, requires, is required by, etc... other stuff

broch · 2009-03-02 15:08:33

just few pointers regarding this:

agpgart.ko -- AGP support
amd74xx.ko -- AMD IDE support
ata_generic.ko -- generic ATA driver
button.ko -- power button?
cdrom.ko -- erm...
ehci-hcd.ko -- USB
evdev.ko -- input devices through the kernel
fan.ko -- fan control/readings via ACPI???
fb_ddc.ko -- framebuffer support/info reading module?
forcedeth.ko -- you have an nVidia chipset with an ethernet port, I guess
hid.ko -- human interface device support (mouse, FI)
i2c-algo-bit.ko
i2c-core.ko
i2c-nforce2.ko -- I2C is a serial bus, and has been used for ages. Apparently your chipset needs it.
ide-core.ko
ide-pci-generic.ko -- ??? Not using libata or something?
ieee1394.ko -- got Firewire?
k8temp.ko -- Athlon64?
libata.ko -- the good stuff
nvidia.ko -- you evil sheep, you! (OK, so I use the binary driver, too...)
nvidiafb.ko -- new framebuffer.
ohci-hcd.ko -- USB again?
ohci1394.ko -- Firewire again?
pata_acpi.ko
pata_amd.ko -- drive controller stuff again
pci_hotplug.ko -- for all of the three people with big-iron servers that use it? Or is it good for suspend/resume, or something? I dunno, but I don't put it in
pcspkr.ko -- I disable this one. Only my BIOS should be beeping at me.
processor.ko
sata_nv.ko -- again, nVidia drive controller
scsi_mod.ko -- you need this for all the SATA stuff to work right, I'm pretty sure
sd_mod.ko -- ditto
serio_raw.ko -- *shrug* raw serial I/O
shpchp.ko -- some kind of hotplug thingie?
snd-hda-intel.ko -- you have HDA sound onboard.
snd-hwdep.ko
snd-page-alloc.ko
snd-pcm.ko
snd-pcsp.ko -- same as the main kernel one, I leave it out. Sometimes ALSA likes to make it the default, too, for no good reason.
snd-timer.ko
snd.ko
soundcore.ko
sr_mod.ko -- I *think* this is needed for burners these days. In general, don't skimp in the SCSI support in the config (you don't need tape or media changer support, of course)
thermal.ko
usb-storage.ko
usbcore.ko
usbhid.ko -- HID again
vgastate.ko -- usually a dependency for framebuffer stuff, but I'm not sure beyond that

agpgart.ko -- AGP support
actually this one is potentially a performance culprit when using nvidia drivers. kernel agp is really bad. If you have installed nvidia binary driver, you don't need this one even with AGP card. If you have PCI/PCIE card, this is a waste.

nvidiafb.ko -- new framebuffer.

nope this one is for nVidia Riva128 (pretty old video card)

ohci-hcd.ko -- USB again?

there are three different USB controllers: OHCI, UHCi, EHCI
you can't simply disable one of these. all depends on hardware setup: if you have OHCI and UHCI then you need both. So "again" is not again, but system requirement.
run
lspci -v | grep HCI
to see which controllers do you have

scsi_mod.ko -- you need this for all the SATA stuff to work right, I'm pretty sure

no, you don't. But you need to check your hardware dependencies. I have SATA, and the only SCSI stuff loaded is SG and SD

sometimes you will see several modules which have partially the same name. e.g. firewire or usb or snd. all of these might be required for firewire (Assuming that you are using firewire at all) or sound to work. Sometimes the overlap.

my modules take only 2.6MB:
du -sh /lib/modules/2.6.28.7-slim
2.6M /lib/modules/2.6.28.7-slim

without nvidia driver (this one alone is 7.6MB)
does this speed up kernel? Only to some extend and in fact only particular modules will slow down boot time. In my case PCMCIA is slowing down kernel.
O.k. so what about disk space?
Are you kidding? default Arch kernel modules take 69MB and current disks are what? several (tenths, hundreds) GB? So this is no argument really.
So what about RAM?
You will be much better off trimming down your DM (KDE or Gnome) than kernel assuming that you are using one of these, however even small WM can be trimmed down. These two (KDE and Gnome) are pigs, but you can easily cut some fat without loosing usability.
So why I did this? not to gain anything. Out of curiosity really

there is a lot of tools that may help:
lspci
lsusb
cpuinfo
for example that may help.

Last edited by broch (2009-03-02 15:11:07)

haxit · 2009-03-02 20:07:30

Thanks a lot guys!

Inxsible · 2009-03-02 20:15:32

cerbie and broch.... interesting posts.

I might just go home today and check out my machine in detail -- not to tweak anything, but just to see what its made of

Got meself something nice to do instead of watching the boring reruns.

Convergence · 2009-03-06 00:37:24

I thought that it was weird when I came to arch from gentoo that the default config loaded so many modules. In gentoo, i manually configured my kernel, and included only what I knew that I needed. It took forever to get the damn thing to work, but when I was done, it only loaded like 10 modules, and I barely built anything into the kernel itself. Boot time was amazing (partly because I didn't use any auto config udev type stuff, or initramfs) Every once in a while, I'd realize that a task (like plugging in a camera, or using a gamepad) needed a module that I didn't have, so I'd have to actually rebuild all of the modules and load it ... but for the most part it worked, and didn't give me problems. Now days I look at my kernel modules and scratch my head.

I'm sure that my custom had a tiny footprint, but I don't think that there are any other advantages. (well some would say that more modules loaded, and more options built into the computer increases the chances for bugs and security risks)

Lately, I've decided to build my own kernels again. Don't think I'm going to use the hardcore minimalist approach that I did before, but i'll make it smaller to cut down on compile times at least.

In fact, the best argument for trimming down your kernel is a massive reduction in compile times.

Last edited by Convergence (2009-03-06 01:20:26)

haxit · 2009-03-06 03:28:45

Convergence wrote:

In fact, the best argument for trimming down your kernel is a massive reduction in compile times.

That is one of the main reasons I want to do it. Plus, it looks cool

somedrew · 2009-03-06 04:11:46

Here's a great script I came across that automagically trims unused modules from a kernel config: http://lkml.org/lkml/2005/3/11/39
It's a good way to set the stage and then manually fine-tune the .config.

cheers,

koch · 2009-03-06 13:22:07

your link doesn't work here.

Last edited by koch (2009-03-06 13:22:21)

haxit · 2009-03-06 20:51:48

koch wrote:

your link doesn't work here.

Only if it did, it would be perfect!

tomk · 2009-03-06 21:25:20

It says "temporarily down", and it gives you an alternative. What more do you want?

Please don't say "100% uptime"...

koch · 2009-03-07 00:54:23

tomk wrote:

It says "temporarily down", and it gives you an alternative. What more do you want?

not here. it just tries to load but nothing happens after a few minutes.

somedrew · 2009-03-08 09:03:34

lkml was down for a while but everything seems to be back to normal

Last edited by somedrew (2009-03-08 09:03:57)

haxit · 2009-03-08 23:21:20

I tried the script. Messed my PC up. I will do it the old fashioned way

Convergence · 2009-03-10 06:58:19

I just built my own kernel, but got impatient, so built EVERYTHING as modules. It works at least. One problem is that I can't seem to get rid of agpgart. I tried blacklisting it with "!agpgart" in rc.conf, I tried putting "Option "NvAGP" "1" # Tries internal nVidia AGP drivers first" in xorg.conf, and finally I tried to rebuild the kernel w/o it, and I can't even do that! Menuconfig won't let me. I only have the option of 'm' or '*'. What's the deal? Does something else depend on it? I could manually edit .config, but I get a bad feeling about that.

broch · 2009-03-10 12:42:42

I do not have agp in my kernel.
however there are some evident dependencies so whatever you selected requires kernel agp:

...............
# Graphics support
#
# CONFIG_AGP is not set
# CONFIG_DRM is not set
# CONFIG_VGASTATE is not set
# CONFIG_VIDEO_OUTPUT_CONTROL is not set
CONFIG_FB=y
# CONFIG_FIRMWARE_EDID is not set
# CONFIG_FB_DDC is not set
CONFIG_FB_BOOT_VESA_SUPPORT=y
CONFIG_FB_CFB_FILLRECT=y
CONFIG_FB_CFB_COPYAREA=y
CONFIG_FB_CFB_IMAGEBLIT=y
# CONFIG_FB_CFB_REV_PIXELS_IN_BYTE is not set
# CONFIG_FB_SYS_FILLRECT is not set
# CONFIG_FB_SYS_COPYAREA is not set
# CONFIG_FB_SYS_IMAGEBLIT is not set
# CONFIG_FB_FOREIGN_ENDIAN is not set
# CONFIG_FB_SYS_FOPS is not set
# CONFIG_FB_SVGALIB is not set
# CONFIG_FB_MACMODES is not set
# CONFIG_FB_BACKLIGHT is not set
# CONFIG_FB_MODE_HELPERS is not set
# CONFIG_FB_TILEBLITTING is not set

#
# Frame buffer hardware drivers
#
# CONFIG_FB_CIRRUS is not set
# CONFIG_FB_PM2 is not set
# CONFIG_FB_CYBER2000 is not set
# CONFIG_FB_ARC is not set
# CONFIG_FB_ASILIANT is not set
# CONFIG_FB_IMSTT is not set
# CONFIG_FB_VGA16 is not set
CONFIG_FB_VESA=y
# CONFIG_FB_N411 is not set
# CONFIG_FB_HGA is not set
# CONFIG_FB_S1D13XXX is not set
# CONFIG_FB_NVIDIA is not set
# CONFIG_FB_RIVA is not set
# CONFIG_FB_I810 is not set
# CONFIG_FB_LE80578 is not set
# CONFIG_FB_INTEL is not set
# CONFIG_FB_MATROX is not set
# CONFIG_FB_RADEON is not set
# CONFIG_FB_ATY128 is not set
# CONFIG_FB_ATY is not set
# CONFIG_FB_S3 is not set
# CONFIG_FB_SAVAGE is not set
# CONFIG_FB_SIS is not set
# CONFIG_FB_VIA is not set
# CONFIG_FB_NEOMAGIC is not set
# CONFIG_FB_KYRO is not set
# CONFIG_FB_3DFX is not set
# CONFIG_FB_VOODOO1 is not set
# CONFIG_FB_VT8623 is not set
# CONFIG_FB_CYBLA is not set
# CONFIG_FB_TRIDENT is not set
# CONFIG_FB_ARK is not set
# CONFIG_FB_PM3 is not set
# CONFIG_FB_CARMINE is not set
# CONFIG_FB_GEODE is not set
# CONFIG_FB_VIRTUAL is not set
# CONFIG_FB_METRONOME is not set
# CONFIG_FB_MB862XX is not set
# CONFIG_BACKLIGHT_LCD_SUPPORT is not set

..........................
Manual edition of .config will not help (nor this is dangerous either). As soon as you start compiling kernel existing agp dependencies will force building default agp, unless you also manually deselect whatever requires agp.

I hope this will help a little.

EVRAMP · 2009-03-10 21:04:10

Convergence wrote:

I just built my own kernel, but got impatient, so built EVERYTHING as modules. It works at least. One problem is that I can't seem to get rid of agpgart. I tried blacklisting it with "!agpgart" in rc.conf, I tried putting "Option "NvAGP" "1" # Tries internal nVidia AGP drivers first" in xorg.conf, and finally I tried to rebuild the kernel w/o it, and I can't even do that! Menuconfig won't let me. I only have the option of 'm' or '*'. What's the deal? Does something else depend on it? I could manually edit .config, but I get a bad feeling about that.

Try using make xconfig - it handles modules dependency much better. xconfig needs qt3 installed btw.

Convergence · 2009-03-11 07:20:40

Ok, I disabled a bunch of stuff including fb_nvidia, and I can now disable agpgart. Compiling now, will test it out soon.

By the way, I used xconfig, and decided that I do actually like it better than menuconfig. I turned on reverse dependencies, and it gave me some more info, even though I wasn't completely sure how to read it.

Last edited by Convergence (2009-03-11 07:22:16)

Arch Linux

#1 2009-03-01 01:03:37

Kernel Modules

#2 2009-03-01 01:08:58

Re: Kernel Modules

#3 2009-03-01 01:15:17

Re: Kernel Modules

#4 2009-03-01 04:54:00

Re: Kernel Modules

#5 2009-03-01 20:00:49

Re: Kernel Modules

#6 2009-03-01 22:05:23

Re: Kernel Modules

#7 2009-03-01 23:30:47

Re: Kernel Modules

#8 2009-03-02 11:50:25

Re: Kernel Modules

#9 2009-03-02 11:56:58

Re: Kernel Modules

#10 2009-03-02 15:08:33

Re: Kernel Modules

#11 2009-03-02 20:07:30

Re: Kernel Modules

#12 2009-03-02 20:15:32

Re: Kernel Modules

#13 2009-03-06 00:37:24

Re: Kernel Modules

#14 2009-03-06 03:28:45

Re: Kernel Modules

#15 2009-03-06 04:11:46

Re: Kernel Modules

#16 2009-03-06 13:22:07

Re: Kernel Modules

#17 2009-03-06 20:51:48

Re: Kernel Modules

#18 2009-03-06 21:25:20

Re: Kernel Modules

#19 2009-03-07 00:54:23

Re: Kernel Modules

#20 2009-03-08 09:03:34

Re: Kernel Modules

#21 2009-03-08 23:21:20

Re: Kernel Modules

#22 2009-03-10 06:58:19

Re: Kernel Modules

#23 2009-03-10 12:42:42

Re: Kernel Modules

#24 2009-03-10 21:04:10

Re: Kernel Modules

#25 2009-03-11 07:20:40

Re: Kernel Modules

Board footer