[gentoo-amd64] Re: cpu frequncy scaling module fail to load

[Duncan]

Nadav Horesh posted on Wed, 16 Dec 2009 20:34:22 +0200 as excerpted:

>  I recently upgraded from 2.6.23 to 2.6.31-r6 following the udev upgrade
>  (the latest version - 146-r1 needs kernel version >= 2.6.25). Since the
>  upgrade the frequency scaling modules fails to load at startup, but I
>  can load it manually later

I don't have that hardware, but have you tried compiling the required
drivers /into/ the kernel instead of as modules?

FWIW, while I realize this won't fit everyone's situation, I recently 
decided it was less hassle here to simply compile everything into the 
kernel, and turn off module loading entirely.  What triggered that 
decision here, was that I have separate /boot and / partitions, with a 
separate backup / partition as well.  As I updated my kernel, the new 
kernels would show up in /boot and the new modules in the usual place on 
my working / at /lib/modules/<kern_ver>/, but they'd not get added to the 
backup / partition, which after all remains unmounted most of the time.  

When I need to boot from the backup for whatever reason, a simple change 
to grub's kernel line, adding or changing the root= to point to the 
backup instead of the usual working /, boots the backup.  The problem is 
that then, I had to remember which kernels I had bothered to copy the 
modules dirs over to the backup, and which I hadn't.

Since I already had the main system all builtin, thus avoiding the hassle 
of an initramfs/initrd, and it was only "extra" modules like loopback and 
floppy that were actually built as modules, for some time, I just ignored 
the problem (while making sure I copied at least the modules from the 
first release kernel in a series over, the 2.6.x kernel modules), since I 
wasn't normally after extras when booting to backup anyway.  But I got 
tired of doing even the one set manually, and rather than create a script 
to automate the process, I decided it was simpler to just build the few 
remaining modules in.  Yes, it takes a few more KB of "locked" kernel 
memory that can't swap, but the floppy module, for instance, was being 
loaded automatically anyway, and I never unloaded it, and with multiple 
gigs of RAM, I decided the few KB extra wasn't going to kill me, 
especially since that meant everything I needed was now in just ONE file, 
the kernel itself!

Now, some people load the modules so they can feed in special module 
parameters when the do so.  However, for at least some kernel modules, 
it's possible to feed those in on grub's kernel command line as well -- 
or, if they don't change, from 2.6.30 or 2.6.31 (IDR which), it's now 
possible to build-in a portion of the kernel command line at compile 
time, as well, thus significantly shortening the grub commandline to only 
the kernel filename and any dynamic parameters, such as the root= 
parameter I use to point to my backup when mounting it (and even those 
can have defaults built-in, so you only need to add it to the kernel 
command line if you're changing from the default for some reason).

For instance, the radeon module has the modeset= option (in kernels with 
radeon kms enabled, 2.6.31 for radeons r500 and earlier, 2.6.32 thru the 
r700 series).  When it's builtin, you can feed that option to the kernel 
as radeon.modeset= , either from grub, or built-in.  (Of course, since 
that's a binary 0/1 option with a definite default and a kernel option to 
change that default already, there'd be little reason to build that 
particular one into the kernel at compile time, but it's possible.  More 
practical would be to always have it in grub.conf, and just edit the 
kernel command line from grub at boot and change the single digit, from a 
0 to a 1 or 1 to 0, as appropriate.)

Just something I'm throwing out there in case someone finds it useful. 
YMMV, etc...

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman