Bug 756085

Same here 
cpufreq-info 
cpufrequtils 008: cpufreq-info (C) Dominik Brodowski 2004-2009
Report errors and bugs to http://bugs.opensuse.org, please.
analyzing CPU 0:
  no or unknown cpufreq driver is active on this CPU
  maximum transition latency: 4294.55 ms.
analyzing CPU 1:
  no or unknown cpufreq driver is active on this CPU
  maximum transition latency: 4294.55 ms.

then 
modprobe -v acpi_cpufreq
insmod /lib/modules/3.3.0-2-desktop/kernel/drivers/cpufreq/mperf.ko 
insmod /lib/modules/3.3.0-2-desktop/kernel/drivers/cpufreq/acpi-cpufreq.ko 
r2d2:~/bin # cpufreq-info 
cpufrequtils 008: cpufreq-info (C) Dominik Brodowski 2004-2009
Report errors and bugs to http://bugs.opensuse.org, please.
analyzing CPU 0:
  driver: acpi-cpufreq
  CPUs which run at the same hardware frequency: 0 1
  CPUs which need to have their frequency coordinated by software: 0
  maximum transition latency: 10.0 us.
  hardware limits: 800 MHz - 2.40 GHz
  available frequency steps: 2.40 GHz, 2.40 GHz, 2.00 GHz, 1.60 GHz, 1.20 GHz, 800 MHz
  available cpufreq governors: ondemand, performance
  current policy: frequency should be within 800 MHz and 2.40 GHz.
                  The governor "ondemand" may decide which speed to use
                  within this range.
  current CPU frequency is 2.40 GHz (asserted by call to hardware).
analyzing CPU 1:
  driver: acpi-cpufreq
  CPUs which run at the same hardware frequency: 0 1
  CPUs which need to have their frequency coordinated by software: 1
  maximum transition latency: 10.0 us.
  hardware limits: 800 MHz - 2.40 GHz
  available frequency steps: 2.40 GHz, 2.40 GHz, 2.00 GHz, 1.60 GHz, 1.20 GHz, 800 MHz
  available cpufreq governors: ondemand, performance
  current policy: frequency should be within 800 MHz and 2.40 GHz.
                  The governor "ondemand" may decide which speed to use
                  within this range.
  current CPU frequency is 2.40 GHz (asserted by call to hardware).

Need to add manually other parts 

r2d2:~/bin # modprobe -v cpufreq_conservative
insmod /lib/modules/3.3.0-2-desktop/kernel/drivers/cpufreq/cpufreq_conservative.ko 
r2d2:~/bin # modprobe -v cpufreq_powersave
insmod /lib/modules/3.3.0-2-desktop/kernel/drivers/cpufreq/cpufreq_powersave.ko 
r2d2:~/bin # modprobe -v cpufreq_userspace
insmod /lib/modules/3.3.0-2-desktop/kernel/drivers/cpufreq/cpufreq_userspace.ko 
r2d2:~/bin # cpufreq-info 
cpufrequtils 008: cpufreq-info (C) Dominik Brodowski 2004-2009
Report errors and bugs to http://bugs.opensuse.org, please.
analyzing CPU 0:
  driver: acpi-cpufreq
  CPUs which run at the same hardware frequency: 0 1
  CPUs which need to have their frequency coordinated by software: 0
  maximum transition latency: 10.0 us.
  hardware limits: 800 MHz - 2.40 GHz
  available frequency steps: 2.40 GHz, 2.40 GHz, 2.00 GHz, 1.60 GHz, 1.20 GHz, 800 MHz
  available cpufreq governors: userspace, powersave, conservative, ondemand, performance
  current policy: frequency should be within 800 MHz and 2.40 GHz.
                  The governor "ondemand" may decide which speed to use
                  within this range.
  current CPU frequency is 800 MHz (asserted by call to hardware).
analyzing CPU 1:
  driver: acpi-cpufreq
  CPUs which run at the same hardware frequency: 0 1
  CPUs which need to have their frequency coordinated by software: 1
  maximum transition latency: 10.0 us.
  hardware limits: 800 MHz - 2.40 GHz
  available frequency steps: 2.40 GHz, 2.40 GHz, 2.00 GHz, 1.60 GHz, 1.20 GHz, 800 MHz
  available cpufreq governors: userspace, powersave, conservative, ondemand, performance
  current policy: frequency should be within 800 MHz and 2.40 GHz.
                  The governor "ondemand" may decide which speed to use
                  within this range.
  current CPU frequency is 800 MHz (asserted by call to hardware).

r2d2:~/bin # lsmod | grep cpu
cpufreq_userspace      13162  0 
cpufreq_powersave      12618  0 
cpufreq_conservative    13821  0 
acpi_cpufreq           18766  1 
mperf                  12667  1 acpi_cpufreq
xt_tcpudp              12924  10 
x_tables               34102  16 ip6t_LOG,xt_tcpudp,xt_pkttype,ipt_LOG,xt_limit,ip6t_REJECT,ip6table_raw,xt_NOTRACK,ipt_REJECT,iptable_raw,iptable_filter,ip6table_mangle,ip_tables,xt_conntrack,ip6table_filter,ip6_tables
processor              45608  3 acpi_cpufreq

But renewing mkinitrd the module are not loaded, and then will be forgotten next reboot. 

 mkinitrd 

Kernel image:   /boot/vmlinuz-3.3.0-2-desktop
Initrd image:   /boot/initrd-3.3.0-2-desktop
KMS drivers:     nouveau
Root device:    LABEL=lvsuse (/dev/dm-1) (mounted on / as btrfs)
enabling LUKS support for /dev/sda2 (cr_sda2)
modprobe: Module kernel not found.
WARNING: no dependencies for kernel module 'kernel' found.
Kernel Modules: thermal_sys thermal processor fan ata_generic dm-mod dm-crypt dm-snapshot scsi_dh scsi_dh_alua scsi_dh_emc scsi_dh_hp_sw scsi_dh_rdac zlib_deflate btrfs button wmi video mxm-wmi drm drm_kms_helper ttm nouveau linear arc4 sha256_generic cbc 
Features:       acpi dm kms plymouth block usb lvm2 luks btrfs resume.userspace resume.kernel

Was working on 12.1

This gets fixed with x86 cpu driver autoloading feature introduced in kernel 3.4.
If you give the latest kernel of the day a try:
http://download.opensuse.org/repositories/Kernel:/HEAD/standard
It's already bumped up to 3.4-rc2.

I close this one fixed for now.
Please reopen if you see the same issue with a 3.4 or newer kernel.

Dear Thomas,

I am very sorry to say, but this bug still exist even with the latest kernel in Kernel:HEAD (which is 3.4.0 rc3). 

Attached you can find a list of the kernel modules that are loaded on my system. It is a standard Lenovo T410 and I am running the 64bit version of Factory. 

Raymond

Created attachment 486921 [details]
Overview of the loaded modules

Can you please attach acpidump and cat /proc/cpuinfo output.

Created attachment 490146 [details]
output of acpidump

Created attachment 490147 [details]
Output of cat /proc/cpuinfo

As request I have attached the two files. I am now running with the latest kernel from Kernel:HEAD (3.4.0-rc6) and I still see no sign that it automatically loads the module acpi_cpufreq.

On your platform it should work like that:
When acpi processor driver is loaded (autoloaded by detecting that a processor object is included in the ACPI tables), it checks whether the processor object has a specific function (_PCT) which is necessary for CPU frequency scaling via acpi-cpufreq driver.

The processor object(s) in your ACPI tables do have the _PCT function, but it's not that easy...:

The _PCT function for CPU[1-7] objects are in SSDT9.
The _PCT function for CPU0 is in SSDT7.

SSDT7 ACPI table is loaded when the OS calls the _PCD (Processor Capabilities) or _OSC function of any of CPU 0-7.

Not sure how SSDT9 is loaded at all.

Anyway, can you attach dmesg output as well, please.
Can you try to unload the processor driver when booted up and try to reload it.
There might be some dependencies to thermal or other drivers.
You could try to enforce unloading via rmmod -f processor   (if it does not work otherwise).
If you reload you should see this message in syslog/dmesg?:
"Requesting acpi_cpufreq"
and the driver (hopefully) loads?

If not, does the acpi-cpufreq driver load at all with the latest kernel on your system?

I mean if done manually: modprobe acpi-cpufreq.

I won't be able to answer all your requests at once, but let's start with what I can already provide:

1)  Manually issuing "modprobe acpi-cpufreq" works without any issues or warnings and the CPU speed directly drops down. So everything works from this perspective. 

2)  When removing the processor module (which worked without the -f), and then reloading it again loads surprisingly the acpi-cpufreq module. 

Looking at the dmesg file, I see that the processor is requesting also at the startup: 


[    2.701809] Write protecting the kernel read-only data: 10240k
[    2.703396] Freeing unused kernel memory: 244k freed
[    2.703746] Freeing unused kernel memory: 44k freed
[    2.746988] ACPI: Requesting acpi_cpufreq
[    2.763372] thermal LNXTHERM:00: registered as thermal_zone0
[    2.763378] ACPI: Thermal Zone [THM0] (48 C)
[    2.771180] usb 1-1.5.5: New USB device found, idVendor=046d, idProduct=c062
[    2.771186] usb 1-1.5.5: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[    2.771191] usb 1-1.5.5: Product: USB Laser Mouse

So it seems that the kernel is doing it's job by requesting the correct modules, but this is happening at the moment while the initrd is still active (or the only filesystem available). Checking the initrd, indicates that certain modules are not present.  The initrd only contains the following modules: 

lib/modules/3.4.0-rc6-1-desktop/kernel/drivers/gpu/drm/i915/i915.ko
lib/modules/3.4.0-rc6-1-desktop/kernel/drivers/gpu/drm/drm_kms_helper.ko
lib/modules/3.4.0-rc6-1-desktop/kernel/drivers/gpu/drm/drm.ko
lib/modules/3.4.0-rc6-1-desktop/kernel/drivers/i2c/algos/i2c-algo-bit.ko
lib/modules/3.4.0-rc6-1-desktop/kernel/drivers/scsi/device_handler/scsi_dh_alua.ko
lib/modules/3.4.0-rc6-1-desktop/kernel/drivers/scsi/device_handler/scsi_dh_hp_sw.ko
lib/modules/3.4.0-rc6-1-desktop/kernel/drivers/scsi/device_handler/scsi_dh_emc.ko
lib/modules/3.4.0-rc6-1-desktop/kernel/drivers/scsi/device_handler/scsi_dh_rdac.ko
lib/modules/3.4.0-rc6-1-desktop/kernel/drivers/scsi/device_handler/scsi_dh.ko
lib/modules/3.4.0-rc6-1-desktop/kernel/drivers/acpi/button.ko
lib/modules/3.4.0-rc6-1-desktop/kernel/drivers/acpi/video.ko
lib/modules/3.4.0-rc6-1-desktop/kernel/drivers/acpi/fan.ko
lib/modules/3.4.0-rc6-1-desktop/kernel/drivers/acpi/processor.ko
lib/modules/3.4.0-rc6-1-desktop/kernel/drivers/acpi/thermal.ko
lib/modules/3.4.0-rc6-1-desktop/kernel/drivers/thermal/thermal_sys.ko

In order to work correctly, the initrd should also contain the modules in the directory lib/modules/3.4.0-rc6-1-desktop/kernel/drivers/cpufreq. 

So this seems to be a mkinitrd bug and not a kernel bug.

Adding the following piece to /etc/modprobe.d/00-system.conf 


# With the newer kernels (> 3,3) the processor module loads acpu-cpufreq 
# automatically if supported.
# SUSE INITRD: processor REQUIRES acpi-cpufreq

resolves the issue. mkinitrd now detects that acpi-cpufreq is required by the processor module and will push it inside the initrd file. 

Rebooting the laptop now shows that the acpi-cpufreq module was loaded automatically and working.

# SUSE INITRD: processor REQUIRES acpi-cpufreq
What kind of modprobe.conf syntax is that?
Is that documented somewhere, man modprobe.conf does not list soemthing like that.

First: Thanks for the details and the testing.

I do not like the whole approach, starting from "calling request_module".
One hack on top of the other...

I have an idea how this possibly could get solved inside the kernel, but it's somewhat more intrusive.
The idea is to introduce another "ACPI fake hid": LNXCPUFQ (or similar).
If the processor object has cpufreq functions, add LNXCPUFQ as CID (Compatible Id) and let the acpi-cpufreq driver autoload as an acpi driver.

Hm, rather complex as well, I wonder whether it should just get autoloaded via X86 cpu autoloading matching for "est" (Enhanced SpeedStep) cpuflag.

I'll bring up the topic on a list, add you to CC and use this bug as reference.

Thomas, 

Whatever solution you are coming up with, the fact remains that if the module is not inside the initrd the kernel will never be able to load it. This is not a kernel error, but clearly an error of mkinitrd. 

The syntax seems to be a hack from mkinitrd as that it was indicated inside the /lib/mkinitrd/scripts/setup-modules.sh.  Checking the /etc/modprobe.d/00-system.conf file then you can see a lot of these entries where certain modules are requiring other modules. I agree with you that this is a clear SUSE thing, but as indicated it is not a hack on top of another hack, but a method to prevent all kernel modules to be copied to the initrd and just take the ones that are required. 

I would not see any possibility how you can solve this in the kernel unless you build cpufreq inside the kernel. As long as this stays a module, then when the kernel boots from the initrd, the required modules needs to be present there. 

Unless you can find a way to instruct the kernel that once the system is fully booted, it has to rescan all dependencies and load the required modules again.

Created attachment 490327 [details]
Use x86 CPU autoloading (est feature) for acpi-cpufreq driver loading

The idea is to use the new X86 CPU autoloading feature and try to load the driver if the est (Enhanced Speed Step) feature is detected.

I try to get you a built kernel uploaded for easier testing.
I started the build, but I won't be able to still finish this today.

Thomas,

I am not going to build this kernel as that it seems you do not understand what the real problem is. How can the kernel autoload a driver, when that driver is not installed ??

Please explain to me what you believe the bug is, that you are so desperate to solve ?? 

Excuse my language and tone, but I have the feeling that you are trying to optimize the auto-loading of the kernel, while the real problem is that the acpi-cpufreq driver is NOT inside the initrd. So how can the kernel load a driver that does not exist ?????

Are you familiar with the openSUSE boot process, which involves an initrd, that should contain all kernel modules that are required during the initial bootphase ? 

The problem needs to be resolved by the mkinitrd maintainers which have to make sure that the acpi-cpufreq driver is captured within the initrd. This way the autoload feature of the kernel is working perfectly, so THIS IS NOT A KERNEL BUG !!!

Raymond, no problem. I am familiar with the Linux boot process.

Install (booted via DVD/network/whereever) and installed kernel (after first installation stage completed) are totally different.

acpi-cpufreq is included in the install initrd and a separate mechanism, on SUSE linuxrc (the init process on first installation stage), probes specific modules.

The installed kernel is what we are talking about I expect. This does not happen at installation time, right?
There you have 2 stages of probing modules. Both done via udev for some time.

The first stage in initrd. The only purpose is to provide and load drivers so that the kernel is able to access the root fs on a block device (disk, network storage, whatever). There have been laptop which need the thermal and fan driver for fan control. The first depends on the processor driver (look at /etc/sysconfig/kernel INITRD_MODULES="", the drivers are all about being able to access the rootfs (probably disk) on your system and fan/thermal/processor.

The second stage is the ordinary udev module loading when the root fs and all kernel modules installed on disk are available.

The acpi-cpufreq driver never has been added to the initrd (only to the installation one, because you do not want to run a whole installation at highest freq, but as said that is a totally other mechanism). Specific services have been tried to find the right cpufreq driver (formerly hal), now things have been cleaned up and there is a X86 CPU feature/driver autoloading mechanism (since 3.4). This one should be used.

Hope that explains some bits.
I won't go into more details, hope you are willing to give this kernel a try:
ftp://ftp.suse.com/pub/people/trenn/acpi-cpufreq_autoload_via_est_feature

Of course it would be possible to add acpi-cpufreq driver to the initrd, but I'd like to get rid of the "request_module()" call which is (obviously) evil and IMO not needed.

Hi Thomas,

I feel stupid now as that your explanation sounds very logical. Of course I am willing to try your kernel to see if this would resolve the issue. 

For me it is just strange that in the whole dmesg I only see once the request for the acpi-cpufreq driver once and that is at the beginning of the boot process. This led me to believe that the issue was with the initrd. 

I just downloaded the indicated kernel and will install and reboot to see if this one would resolve the issue. 

Regards

Raymond

Just booted with your updated kernel and it seems that this is indeed the correct solution. Once completely booted the acpi-cpufreq driver is loaded as expected. 

I double checked the created initrd file that the acpi-cpufreq driver is indeed not present there. 

With this patched kernel I can confirm that the issue has been resolved. 

Thanks.

I've submitted the patch to our repo.
I probably have to resubmit things mainline. It seems to not be important enough to still get included into 3.4.
-> I keep the bug open with lower prio to remind myself to resubmit.

This is an autogenerated message for OBS integration:
This bug (756085) was mentioned in
https://build.opensuse.org/request/show/122079 Factory / kernel-source

Thomas,

Should this bug still be open ? We have now currently the 3.9 kernel and this was back in the 3.4 days.  All kernels from that moment onward have been working correctly, so I guess things were submitted correctly.

Yes, this got finally handled in mainline as well and the workaround for older SUSE kernels is not needed anymore.

Thanks for the ping -> setting resolved fixed.