Bug 587764

Created attachment 410597 [details]
dmidecode output

Doru, please provide the contents of /proc/cpuinfo and a dmesg dump from a fresh boot with cpufreq.debug=7 added as a kernel boot parameter.

Created attachment 411587 [details]
Contents of /proc/cpuinfo

Created attachment 411591 [details]
dmesg output from a fresh boot

Interesting sequences in terms of cpu frequency scaling debug are at line 363, where speedstep takes a first look at the processor, and after line 730, when the p4_clockmod governor is chosen and the frequency ranges are established.

Doru, could you check the following things:
1. your current BIOS version; Update it to the latest one;
   = check if it works;
   = there was known issue with Amilo hardware.
2. check if there are an option in the BIOS that forbids/allows frequency scaling;
   = must be enabled;
3. attach your /proc/acpi/dsdt to bugzilla;

p4_clockmod is the fallback driver, and works bad for your case. acpi_cpufreq must be working on your hardware.

and we already hit your problem in the past, you can read the bug comments here:
https://bugzilla.kernel.org/show_bug.cgi?id=8228, it might be helpful to you.

you can workaround the issue by preventing the p4_clockmod of loading.

Let me know the results. Cheers!

Created attachment 412923 [details]
/proc/acpi/dsdt

I checked the bios version, and it's the latest as posted on the fujitsu support website (version 1.10C).
There are no cpu frequency related options in the bios, except maybe for a "Enable power saving mode" option which doesn't appear to change anything while running fedora.
IIRC, enabling this option while using Windows forced the cpu to the lowest possible frequency, but I don't remember for sure.

I checked out the messages on bug 8228, but I wasn't able to stop p4_clockmod from loading. I tried adding it to the /etc/modprobe.d/blacklist.conf file, but it is still loaded. Removing it at runtime works, but acpi_cpufreq still isn't loaded, instead it returns this:
FATAL: Error inserting acpi_cpufreq (/lib/modules/2.6.33.3-85.fc13.i686.PAE/kernel/arch/x86/kernel/cpu/cpufreq/acpi-cpufreq.ko): Device or resource busy

I will try to find other ways to stop modules from loading at boot, and eventually I will try to go over the custom patches that the ubuntu team adds to their kernel.

In the mean time, I attached the /proc/acpi/dsdt file, I hope it will shed some more light on why this is happening. Thanks!

I went as far as actually moving p4_clockmod from /lib/modules, and acpi_cpufreq still doesn't load, but now I get a slightly different error:

FATAL: Error inserting acpi_cpufreq (/lib/modules/2.6.33.3-85.fc13.i686.PAE/kernel/arch/x86/kernel/cpu/cpufreq/acpi-cpufreq.ko): No such device

I guess p4_clockmod wasn't the culprit for acpi_cpufreq's failure to load after all. Any more ideas about what I should try?

Cheers!

Doru, "modprobe acpi_cpufreq" fails because your dsdt has:
  OperationRegion (SSDT, SystemMemory, 0xFFFF0000, 0xFFFF)
  // you can see it by iasl -d %your_dsdt_file%
that means freq scaling disabled in the BIOS. Ubuntu has patched sources where they workaround this issue.
and as per comment:
  https://bugzilla.kernel.org/show_bug.cgi?id=8228&mark=46#c46
the issue was fixed by the BIOS from 2004.

  We are not going to do workaround bits in kernel, it's not the right way to solve the issue and thus have no chances to get into mainline kernel.

  I also believe Fujitsu won't be pay attention since the laptop is old and unsupported this days.

  I would recommend to re-open the bug 8228 at kernel.org's bugzilla and mention that you have exactly the same situation as Daniel Swarbrick had and BIOS updated didn't work it out for you.

  hence I'm closing the bug for now, as WONTFIX, it's BIOS issue.

Cheers!

Thank you for the link to the kernel.org bug report. Following the original poster's idea, I reflashed bios 1.10C and then I resetted to optimal defaults.
Magically, it works. The weird part is that I can't see any bios options to be different than they way they were set up before.

I suspect that, when flashing a new bios, the old options are preserved and they somehow impair newly implemented features. I'm saying that because, after flashing, I didn't get any "CMOS checksum bad" kind of error.

Anyhow, thanks again!

Doru, thanks for the feedback.

And please, attach your /proc/acpi/dsdt to this bug again. I'd like to look into, what has changed.

thanks,

Created attachment 414764 [details]
/proc/acpi/dsdt file after bios flash & reset to optimized defaults

Apparently, there aren't many changes to speak of. OperationRegion did change, and the Method (USXD, [...]) statements became Method (_S3D, [...]).

I'll just paste below a diff between the iasl output for the old and new dsdt, and I will attach the new dsdt file.

===========================================

-DefinitionBlock ("dsdt.aml", "DSDT", 1, "UW____", "F19_____", 0x00000001)
+DefinitionBlock ("dsdt_after.aml", "DSDT", 1, "UW____", "F19_____", 0x00000001)
 {
     Scope (\_PR)
     {
         Processor (CPU1, 0x01, 0x00000810, 0x06)
         {
-            OperationRegion (SSDT, SystemMemory, 0xFFFF0000, 0xFFFF)
-            Name (NCPU, 0x00)
+            OperationRegion (SSDT, SystemMemory, 0x2FFD4EC0, 0x03F6)
+            Name (NCPU, 0x01)
             Name (TYPE, 0x80000000)
             Name (HNDL, 0x80000000)
             Method (_PDC, 1, NotSerialized)
@@ -890,7 +890,7 @@ DefinitionBlock ("dsdt.aml", "DSDT", 1, 
                 Return (PR00)
             }
 
-            Method (USXD, 0, NotSerialized)
+            Method (_S3D, 0, NotSerialized)
             {
                 If (LOr (LEqual (OSFL (), 0x01), LEqual (OSFL (), 0x02)))
                 {
@@ -2907,7 +2907,7 @@ DefinitionBlock ("dsdt.aml", "DSDT", 1, 
                             Offset (0x01)
                 }
 
-                Method (USXD, 0, NotSerialized)
+                Method (_S3D, 0, NotSerialized)
                 {
                     If (LOr (LEqual (OSFL (), 0x01), LEqual (OSFL (), 0x02)))
                     {
@@ -2942,7 +2942,7 @@ DefinitionBlock ("dsdt.aml", "DSDT", 1, 
                             Offset (0x01)
                 }
 
-                Method (USXD, 0, NotSerialized)
+                Method (_S3D, 0, NotSerialized)
                 {
                     If (LOr (LEqual (OSFL (), 0x01), LEqual (OSFL (), 0x02)))
                     {
@@ -2977,7 +2977,7 @@ DefinitionBlock ("dsdt.aml", "DSDT", 1, 
                             Offset (0x01)
                 }
 
-                Method (USXD, 0, NotSerialized)
+                Method (_S3D, 0, NotSerialized)
                 {
                     If (LOr (LEqual (OSFL (), 0x01), LEqual (OSFL (), 0x02)))
                     {
@@ -3012,7 +3012,7 @@ DefinitionBlock ("dsdt.aml", "DSDT", 1, 
                             Offset (0x01)
                 }
 
-                Method (USXD, 0, NotSerialized)
+                Method (_S3D, 0, NotSerialized)
                 {
                     If (LOr (LEqual (OSFL (), 0x01), LEqual (OSFL (), 0x02)))
                     {

perfect, that's what I looked for. :) thanks!