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

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

[Nadav Horesh]

System: AMD Athlon(tm) 64 X2 Dual Core Processor 5600+


 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 by:

modprobe powernow-k8

More information:

$ rc-update -s
.
.
.
powernowd |      default

$ grep -i powernow /var/log/messages

Dec 14 08:31:24 nadav_home kernel: ACPI: SSDT 00000000dfff75c0 002CC (v01 PTLTD  POWERNOW 00000001  LTP 00000001)
Dec 14 08:31:24 nadav_home rc-scripts: ERROR:  powernowd failed to start


Relevant lines from /usr/src/linux/.config

#
# Power management and ACPI options
#
CONFIG_ARCH_HIBERNATION_HEADER=y
CONFIG_PM=y
# CONFIG_PM_DEBUG is not set
CONFIG_PM_SLEEP_SMP=y
CONFIG_PM_SLEEP=y
CONFIG_SUSPEND=y
CONFIG_SUSPEND_FREEZER=y
CONFIG_HIBERNATION_NVS=y
CONFIG_HIBERNATION=y
CONFIG_PM_STD_PARTITION=""
CONFIG_ACPI=y
CONFIG_ACPI_SLEEP=y
CONFIG_ACPI_PROCFS=y
CONFIG_ACPI_PROCFS_POWER=y
CONFIG_ACPI_SYSFS_POWER=y
# CONFIG_ACPI_PROC_EVENT is not set
# CONFIG_ACPI_AC is not set
# CONFIG_ACPI_BATTERY is not set
CONFIG_ACPI_BUTTON=m
CONFIG_ACPI_VIDEO=m
CONFIG_ACPI_FAN=y
CONFIG_ACPI_DOCK=y
CONFIG_ACPI_PROCESSOR=y
CONFIG_ACPI_HOTPLUG_CPU=y
CONFIG_ACPI_THERMAL=m
# CONFIG_ACPI_CUSTOM_DSDT is not set
CONFIG_ACPI_BLACKLIST_YEAR=0
# CONFIG_ACPI_DEBUG is not set
# CONFIG_ACPI_PCI_SLOT is not set
CONFIG_X86_PM_TIMER=y
CONFIG_ACPI_CONTAINER=y
# CONFIG_ACPI_SBS is not set

#
# CPU Frequency scaling
#
CONFIG_CPU_FREQ=y
CONFIG_CPU_FREQ_TABLE=y
# CONFIG_CPU_FREQ_DEBUG is not set
# CONFIG_CPU_FREQ_STAT is not set
# CONFIG_CPU_FREQ_DEFAULT_GOV_PERFORMANCE is not set
# CONFIG_CPU_FREQ_DEFAULT_GOV_POWERSAVE is not set
CONFIG_CPU_FREQ_DEFAULT_GOV_USERSPACE=y
# CONFIG_CPU_FREQ_DEFAULT_GOV_ONDEMAND is not set
# CONFIG_CPU_FREQ_DEFAULT_GOV_CONSERVATIVE is not set
CONFIG_CPU_FREQ_GOV_PERFORMANCE=y
CONFIG_CPU_FREQ_GOV_POWERSAVE=y
CONFIG_CPU_FREQ_GOV_USERSPACE=y
CONFIG_CPU_FREQ_GOV_ONDEMAND=y
CONFIG_CPU_FREQ_GOV_CONSERVATIVE=y

#
# CPUFreq processor drivers
#
CONFIG_X86_ACPI_CPUFREQ=m
CONFIG_X86_POWERNOW_K8=m
# CONFIG_X86_SPEEDSTEP_CENTRINO is not set
# CONFIG_X86_P4_CLOCKMOD is not set

#
# shared options
#
# CONFIG_X86_SPEEDSTEP_LIB is not set
CONFIG_CPU_IDLE=y
CONFIG_CPU_IDLE_GOV_LADDER=y
CONFIG_CPU_IDLE_GOV_MENU=y

 Any idea how can I fix it?

   Nadav

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

[Nikos Chantziaras]

On 12/16/2009 08:34 PM, Nadav Horesh wrote:
>
> System: AMD Athlon(tm) 64 X2 Dual Core Processor 5600+
>
>
>   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 by:
>
> modprobe powernow-k8
>
> More information:
>
> $ rc-update -s
> .
> .
> .
> powernowd |      default
>
> $ grep -i powernow /var/log/messages
>
> Dec 14 08:31:24 nadav_home kernel: ACPI: SSDT 00000000dfff75c0 002CC (v01 PTLTD  POWERNOW 00000001  LTP 00000001)
> Dec 14 08:31:24 nadav_home rc-scripts: ERROR:  powernowd failed to start

Install and set up sys-power/powernowd.

[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

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

[Nadav Horesh]

[-- Attachment #1: Type: text/plain, Size: 4569 bytes --]

Well, it is a good linux lesson, I'll may try, just for the sake of improved boot speed. Does it goes well with the binary nvidia driver?

However, I solved my problem by adding the line powernow-k8 to /etc/modules.autoload.d/kernel-2.6

I wonder why the module stopped loading automatically.

  Nadav.

-----Original Message-----
From: news on behalf of Duncan
Sent: Thu 17-Dec-09 01:35
To: gentoo-amd64@lists.gentoo.org
Subject: [gentoo-amd64]  Re: cpu frequncy scaling module fail to load
 
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




[-- Attachment #2: winmail.dat --]
[-- Type: application/ms-tnef, Size: 5053 bytes --]

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

[Duncan]

Nadav Horesh posted on Thu, 17 Dec 2009 19:20:07 +0200 as excerpted:

> Well, it is a good linux lesson, I'll may try, just for the sake of
> improved boot speed. Does it goes well with the binary nvidia driver?

It should indeed improve boot speed.  I don't do proprietary drivers (tho 
FWIW I don't worry so much about firmware, everybody draws the line 
somewhere, that's just where I draw mine) so don't know for sure on the 
nVidia driver, but AFAIK, as long as you don't disable module loading 
entirely, you're probably good.  

Note also that the GPL will let a user do what they want too, including 
compiling the nVidia drivers into the kernel itself, if you can figure 
out how (I believe it's doable, but I wouldn't know how...), as long as 
you don't distribute the resulting product.  Of course, it's possible 
that wouldn't be legal from nVidia's side, I honestly don't know, but the 
GPL lets you do it from its side as a user as long as the nVidia side 
allows it as well -- you just can't legally distribute the result.  If 
you were to do something like that, you could again turn off module 
loading entirely, if desired, and run with the nVidia driver compiled 
directly into the kernel.

-- 
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