Bug 10734 - CPU Frequency scaling gone on CPU1 after resume-from-sleep - Dell Latitude D630, XPS M1330
CPU Frequency scaling gone on CPU1 after resume-from-sleep - Dell Latitude D6...
Status: CLOSED CODE_FIX
Product: ACPI
Classification: Unclassified
Component: BIOS
All Linux
: P1 normal
Assigned To: Robert Moore
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2008-05-17 12:30 UTC by Dennis Noordsij
Modified: 2008-10-24 22:56 UTC (History)
7 users (show)

See Also:
Kernel Version: 2.6.26-rc2
Tree: Mainline
Regression: ---


Attachments
dmesg of a fresh boot, suspend, then resume (66.46 KB, text/plain)
2008-05-19 00:30 UTC, Dennis Noordsij
Details
acpidump output (124.13 KB, application/octet-stream)
2008-05-19 00:34 UTC, Dennis Noordsij
Details
disassembled dsdt (247.54 KB, application/octet-stream)
2008-05-19 00:36 UTC, Dennis Noordsij
Details
acpidump outputs as requested (10.00 KB, application/x-tar)
2008-05-19 01:39 UTC, Dennis Noordsij
Details
Merged CPU*ST and SSDT into the DSDT (286.16 KB, application/octet-stream)
2008-05-22 03:17 UTC, Dennis Noordsij
Details
acpi dump (124.07 KB, text/plain)
2008-05-23 01:41 UTC, Dariush Forouher
Details
Cpu*st tables before and after resume (*Ist become corrupted) (20.00 KB, application/x-tar)
2008-05-23 02:22 UTC, Dennis Noordsij
Details
acpidump, cpu*st, dmesg (55.18 KB, application/x-compressed-tar)
2008-05-23 04:17 UTC, Dariush Forouher
Details
Copy external ACPI tables to our own buffer instead of mapping them (2.70 KB, patch)
2008-05-25 09:01 UTC, Dennis Noordsij
Details | Diff
Cleaned up patch (2.70 KB, patch)
2008-05-26 02:04 UTC, Dennis Noordsij
Details | Diff
ACPICA version of load table patch (3.61 KB, patch)
2008-06-11 12:18 UTC, Robert Moore
Details | Diff
output of sudo lspci -v (8.38 KB, application/octet-stream)
2008-06-30 03:03 UTC, Dennis Noordsij
Details

Description Dennis Noordsij 2008-05-17 12:30:02 UTC
Latest working kernel version: unknown
Earliest failing kernel version: at least 2.6.22
Distribution: Ubuntu Hardy (confirmed bug with mainline 2.6.26-rc2) 
Hardware Environment: Dell Latitude D630
Software Environment: Ubuntu Hardy
Problem Description: 

Normally, cpufreq-info reports:

cpufrequtils 002: cpufreq-info (C) Dominik Brodowski 2004-2006
Report errors and bugs to linux@brodo.de, please.
analyzing CPU 0:
  driver: acpi-cpufreq
  CPUs which need to switch frequency at the same time: 0 1
  hardware limits: 800 MHz - 2.20 GHz
  available frequency steps: 2.20 GHz, 2.20 GHz, 1.60 GHz, 1.20 GHz, 800 MHz
  available cpufreq governors: powersave, ondemand, conservative, userspace, performance
  current policy: frequency should be within 800 MHz and 2.20 GHz.
                  The governor "ondemand" may decide which speed to use
                  within this range.
  current CPU frequency is 800 MHz.
analyzing CPU 1:
  driver: acpi-cpufreq
  CPUs which need to switch frequency at the same time: 0 1
  hardware limits: 800 MHz - 2.20 GHz
  available frequency steps: 2.20 GHz, 2.20 GHz, 1.60 GHz, 1.20 GHz, 800 MHz
  available cpufreq governors: powersave, ondemand, conservative, userspace, performance
  current policy: frequency should be within 800 MHz and 2.20 GHz.
                  The governor "ondemand" may decide which speed to use
                  within this range.
  current CPU frequency is 800 MHz.


However, after resuming from sleep the following is reported in dmesg:

[  296.435243] Back to C!
[  296.435243] Extended CMOS year: 2000
[  296.435243] Enabling non-boot CPUs ...
[  296.435243] CPU0 attaching NULL sched-domain.
[  296.435243] SMP alternatives: switching to SMP code
[  296.441457] Booting processor 1/1 ip 6000
[  296.448433] Initializing CPU#1
[  296.448433] Calibrating delay using timer specific routine.. 4389.13 BogoMIPS (lpj=8778260)
[  296.448433] CPU: L1 I cache: 32K, L1 D cache: 32K
[  296.448433] CPU: L2 cache: 4096K
[  296.448433] CPU: Physical Processor ID: 0
[  296.448433] CPU: Processor Core ID: 1
[  296.529004] CPU1: Intel(R) Core(TM)2 Duo CPU     T7500  @ 2.20GHz stepping 0b
[  296.529035] CPU0 attaching sched-domain:
[  296.529038]  domain 0: span 0-1
[  296.529039]   groups: 0 1
[  296.529042] CPU1 attaching sched-domain:
[  296.529043]  domain 0: span 0-1
[  296.529045]   groups: 1 0
[  296.448433] ACPI Error (psloop-0136): Found unknown opcode FE at AML address f883c7ca offset 3, ignoring [20080321]
[  296.448433] ACPI Error (psloop-0136): Found unknown opcode 1F at AML address f883c7cd offset 6, ignoring [20080321]
[  296.448433] ACPI Error (psloop-0136): Found unknown opcode 2 at AML address f883c7d4 offset D, ignoring [20080321]
[  296.448433] ACPI Error (psloop-0136): Found unknown opcode C2 at AML address f883c7d6 offset F, ignoring [20080321]
[  296.448433] ACPI Error (psargs-0358): [E] Namespace lookup failure, AE_NOT_FOUND
[  296.448433] ACPI Error (psparse-0530): Method parse/execution failed [\_PR_.CPU1._PCT] (Node f4c17930), AE_NOT_FOUND
[  296.448433] ACPI Exception (processor_perflib-0191): AE_NOT_FOUND, Evaluating _PCT [20080321]
[  296.448433] CPU1 is up
[  296.552171] Switched to high resolution mode on CPU 1

and cpufreq-info reports:

cpufrequtils 002: cpufreq-info (C) Dominik Brodowski 2004-2006
Report errors and bugs to linux@brodo.de, please.
analyzing CPU 0:
  driver: acpi-cpufreq
  CPUs which need to switch frequency at the same time: 0
  hardware limits: 800 MHz - 2.20 GHz
  available frequency steps: 2.20 GHz, 2.20 GHz, 1.60 GHz, 1.20 GHz, 800 MHz
  available cpufreq governors: powersave, ondemand, conservative, userspace, performance
  current policy: frequency should be within 800 MHz and 2.20 GHz.
                  The governor "ondemand" may decide which speed to use
                  within this range.
  current CPU frequency is 800 MHz.
analyzing CPU 1:
  no or unknown cpufreq driver is active on this CPU


At this point, CPU scaling is effectively gone, (stuck in either mode, perhaps now movies will stutter at playback, battery life might go down a lot, cpu-frequency applets go crazy, etc)

One "fix" is to
  rmmod -f acpi_cpufreq && modprobe acpi_cpufreq
but this obviously introduces instability (I have experienced sudden hard lockups), and is otherwise not really a workable solution as most distribution kernels do not support forceful module unloading by default.

This has been Ubuntu bug 183033 since January, but it's considered low priority and afaict nobody has made any real effort to find the cause; however it affects many people (everyone with a core 2 duo?), so I decided to report it here. It has been happening with every Ubuntu kernel since at least then, but I just confirmed it with mainline kernel 2.6.26-rc2 without any binary modules or otherwise tainted modules; everything happens exactly the same.

/proc/cpuinfo:

processor       : 0
vendor_id       : GenuineIntel
cpu family      : 6
model           : 15
model name      : Intel(R) Core(TM)2 Duo CPU     T7500  @ 2.20GHz
stepping        : 11
cpu MHz         : 800.000
cache size      : 4096 KB
physical id     : 0
siblings        : 2
core id         : 0
cpu cores       : 2
fdiv_bug        : no
hlt_bug         : no
f00f_bug        : no
coma_bug        : no
fpu             : yes
fpu_exception   : yes
cpuid level     : 10
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe lm constant_tsc arch_perfmon pebs bts pni monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr lahf_lm ida
bogomips        : 4393.93
clflush size    : 64

processor       : 1
vendor_id       : GenuineIntel
cpu family      : 6
model           : 15
model name      : Intel(R) Core(TM)2 Duo CPU     T7500  @ 2.20GHz
stepping        : 11
cpu MHz         : 2194.587
cache size      : 4096 KB
physical id     : 0
siblings        : 2
core id         : 1
cpu cores       : 2
fdiv_bug        : no
hlt_bug         : no
f00f_bug        : no
coma_bug        : no
fpu             : yes
fpu_exception   : yes
cpuid level     : 10
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx lm constant_tsc arch_perfmon pebs bts pni monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr lahf_lm ida
bogomips        : 4387.19
clflush size    : 64

Some additional info can be found at:
https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.22/+bug/183033

Additional ACPI info:

[    0.000000] DMI 2.4 present.
[    0.000000] ACPI: RSDP 000FBB00, 0024 (r2 DELL  )
[    0.000000] ACPI: XSDT 7FE5D200, 0064 (r1 DELL    M08     27D8021C ASL        61)
[    0.000000] ACPI: FACP 7FE5D09C, 00F4 (r4 DELL    M08     27D8021C ASL        61)
[    0.000000] ACPI: DSDT 7FE5D800, 6152 (r2 INT430 SYSFexxx     1001 INTL 20050624)
[    0.000000] ACPI: FACS 7FE6C000, 0040
[    0.000000] ACPI: HPET 7FE5D300, 0038 (r1 DELL    M08            1 ASL        61)
[    0.000000] ACPI: APIC 7FE5D400, 0068 (r1 DELL    M08     27D8021C ASL        47)
[    0.000000] ACPI: ASF! 7FE5D000, 007E (r32 DELL    M08     27D8021C ASL        61)
[    0.000000] ACPI: MCFG 7FE5D3C0, 003E (r16 DELL    M08     27D8021C ASL        61)
[    0.000000] ACPI: TCPA 7FE5D700, 0032 (r1                        0 ASL         0)
[    0.000000] ACPI: SLIC 7FE5D49C, 0176 (r1 DELL    M08     27D8021C ASL        61)
[    0.000000] ACPI: SSDT 7FE5B9C0, 04CC (r1  PmRef    CpuPm     3000 INTL 20050624)
[    0.000000] ACPI: PM-Timer IO Port: 0x1008
[    0.000000] ACPI: Local APIC address 0xfee00000
[    0.000000] ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled)
[    0.000000] BIOS bug, APIC version is 0 for CPU#0! fixing up to 0x10. (tell your hw vendor)
[    0.000000] ACPI: LAPIC (acpi_id[0x01] lapic_id[0x01] enabled)
[    0.000000] BIOS bug, APIC version is 0 for CPU#0! fixing up to 0x10. (tell your hw vendor)
[    0.000000] ACPI: LAPIC_NMI (acpi_id[0x00] high edge lint[0x1])
[    0.000000] ACPI: LAPIC_NMI (acpi_id[0x01] high edge lint[0x1])
[    0.000000] ACPI: IOAPIC (id[0x02] address[0xfec00000] gsi_base[0])
[    0.000000] IOAPIC[0]: apic_id 2, version 32, address 0xfec00000, GSI 0-23
[    0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
[    0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level)
[    0.000000] ACPI: IRQ0 used by override.
[    0.000000] ACPI: IRQ2 used by override.
[    0.000000] ACPI: IRQ9 used by override.
[    0.000000] Enabling APIC mode:  Flat.  Using 1 I/O APICs
...
[    0.864975] Setting up standard PCI resources
[    0.864975] ACPI: EC: Look up EC in DSDT
[    0.864975] ACPI: BIOS _OSI(Linux) query ignored
[    0.864975] ACPI: DMI System Vendor: Dell Inc.
[    0.864975] ACPI: DMI Product Name: Latitude D630
[    0.864975] ACPI: DMI Product Version:
[    0.864975] ACPI: DMI Board Name:
[    0.864975] ACPI: DMI BIOS Vendor: Dell Inc.
[    0.864975] ACPI: DMI BIOS Date: 02/28/2008
[    0.864975] ACPI: Please send DMI info above to linux-acpi@vger.kernel.org
[    0.864975] ACPI: If "acpi_osi=Linux" works better, please notify linux-acpi@vger.kernel.org
[    0.895022] ACPI: SSDT 7FE6C080, 0043 (r1  LMPWR  DELLLOM     1001 INTL 20050624)
[    0.910567] ACPI: Interpreter enabled
[    0.910571] ACPI: (supports S0 S3 S4 S5)
[    0.912626] ACPI: Using IOAPIC for interrupt routing
[    0.985417] ACPI: PCI Root Bridge [PCI0] (0000:00)
[    0.985417] pci 0000:00:1f.0: quirk: region 1000-107f claimed by ICH6 ACPI/GPIO/TCO
[    0.985417] pci 0000:00:1f.0: quirk: region 1080-10bf claimed by ICH6 GPIO
[    0.985417] PCI: Transparent bridge - 0000:00:1e.0
[    0.985417] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT]
[    0.985417] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.PCIE._PRT]
[    0.985575] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.AGP_._PRT]
[    0.985672] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.RP01._PRT]
[    0.985788] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.RP02._PRT]
[    0.985906] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.RP06._PRT]
[    1.005473] ACPI: PCI Interrupt Link [LNKA] (IRQs 9 10 11) *5
[    1.005473] ACPI: PCI Interrupt Link [LNKB] (IRQs 5 7) *10
[    1.005473] ACPI: PCI Interrupt Link [LNKC] (IRQs 9 10 11) *0, disabled.
[    1.005473] ACPI: PCI Interrupt Link [LNKD] (IRQs 5 7 9 10 11) *3
[    1.005473] ACPI: PCI Interrupt Link [LNKE] (IRQs 3 4 5 6 7 9 10 *11 12 14 15)
[    1.005473] ACPI: PCI Interrupt Link [LNKF] (IRQs 3 4 5 6 7 9 *10 11 12 14 15)
[    1.005473] ACPI: PCI Interrupt Link [LNKG] (IRQs 3 4 5 6 7 *9 10 11 12 14 15)
[    1.005473] ACPI: PCI Interrupt Link [LNKH] (IRQs 3 4 5 6 7 9 10 11 12 14 15) *0, disabled.

I should also note that "acpi_osi=Linux" breaks resume altogether, so I have not pursued if it works with that options.



Steps to reproduce:

Suspend-to-RAM. Resume. Observe.


Please free to request any more information or tests I can do.
Comment 1 Dennis Noordsij 2008-05-17 13:32:17 UTC
(btw, this is not a duplicate of either #9181 or #8581 afaict)

Some output with cpufreq.debug=7   (2.6.26-rc2)

Boot:

[   53.689628] acpi-cpufreq: acpi_cpufreq_init
[   53.689628] acpi-cpufreq: acpi_cpufreq_early_init
[   53.689628] cpufreq-core: trying to register driver acpi-cpufreq
[   53.689628] cpufreq-core: adding CPU 0
[   53.689628] acpi-cpufreq: acpi_cpufreq_cpu_init
[   53.689628] acpi-cpufreq: HARDWARE addr space
[   53.689628] freq-table: table entry 0: 2201000 kHz, 0 index
[   53.689628] freq-table: table entry 1: 2200000 kHz, 1 index
[   53.689628] freq-table: table entry 2: 1600000 kHz, 2 index
[   53.689628] freq-table: table entry 3: 1200000 kHz, 3 index
[   53.689628] freq-table: table entry 4: 800000 kHz, 4 index
[   53.689628] acpi-cpufreq: get_cur_freq_on_cpu (0)
[   53.689628] acpi-cpufreq: get_cur_val = 100666153
[   53.689628] acpi-cpufreq: cur freq = 2200000
[   53.689628] acpi-cpufreq: CPU0 - ACPI performance management activated.
[   53.689628] acpi-cpufreq:      *P0: 2201 MHz, 32000 mW, 10 uS
[   53.689628] acpi-cpufreq:       P1: 2200 MHz, 31000 mW, 10 uS
[   53.689628] acpi-cpufreq:       P2: 1600 MHz, 20000 mW, 10 uS
[   53.689628] acpi-cpufreq:       P3: 1200 MHz, 13000 mW, 10 uS
[   53.689628] acpi-cpufreq:       P4: 800 MHz, 10000 mW, 10 uS
[   53.689628] freq-table: setting show_table for cpu 0 to effb7dc0
[   53.689628] cpufreq-core: CPU 1 already managed, adding link
[   53.689628] cpufreq-core: setting new policy for CPU 0: 800000 - 2201000 kHz
[   53.689628] acpi-cpufreq: acpi_cpufreq_verify
[   53.689628] freq-table: request for verification of policy (800000 - 2201000 kHz) for cpu 0
[   53.689628] freq-table: verification lead to (800000 - 2201000 kHz) for cpu 0
[   53.689628] acpi-cpufreq: acpi_cpufreq_verify
[   53.689628] freq-table: request for verification of policy (800000 - 2201000 kHz) for cpu 0
[   53.689628] freq-table: verification lead to (800000 - 2201000 kHz) for cpu 0
[   53.689628] cpufreq-core: new min and max freqs are 800000 - 2201000 kHz
[   53.689628] cpufreq-core: governor switch
[   53.689628] cpufreq-core: __cpufreq_governor for CPU 0, event 1
[   53.689628] cpufreq-core: governor: change or update limits
[   53.689628] cpufreq-core: __cpufreq_governor for CPU 0, event 3
[   53.689628] cpufreq-core: initialization complete
[   53.689628] cpufreq-core: adding CPU 1
[   53.689628] cpufreq-core: driver acpi-cpufreq up and running
[   53.692801] acpi-cpufreq: cpu 0: performance percent 88
[   53.692804] cpufreq-core: target for CPU 0: 0 kHz, relation 0
[   53.692807] acpi-cpufreq: acpi_cpufreq_target 0 (0)
[   53.692809] freq-table: request for target 0 kHz (relation: 0) for cpu 0
[   53.692811] freq-table: target is 4 (800000 kHz, 4)
[   53.692813] cpufreq-core: notification 0 of frequency transition to 800000 kHz
[   53.692816] cpufreq-core: notification 0 of frequency transition to 800000 kHz
[   53.695548] cpufreq-core: notification 1 of frequency transition to 800000 kHz
[   54.045419] toshiba_acpi: Unknown parameter `hotkeys_over_acpi'
[   58.814979] __ratelimit: 61 messages suppressed
[   58.814989] acpi-cpufreq: cpu 0: performance percent 58
[   62.336641] apm: BIOS not found.
[   62.463239] cpufreq-core: setting new policy for CPU 0: 800000 - 2201000 kHz
[   62.463251] acpi-cpufreq: acpi_cpufreq_verify
[   62.463258] freq-table: request for verification of policy (800000 - 2201000 kHz) for cpu 0
[   62.463265] freq-table: verification lead to (800000 - 2201000 kHz) for cpu 0
[   62.463273] acpi-cpufreq: acpi_cpufreq_verify
[   62.463278] freq-table: request for verification of policy (800000 - 2201000 kHz) for cpu 0
[   62.463286] freq-table: verification lead to (800000 - 2201000 kHz) for cpu 0
[   62.463293] cpufreq-core: new min and max freqs are 800000 - 2201000 kHz
[   62.466433] cpufreq-core: governor: change or update limits

etc ..


then, after resuming:

[  165.391132] Back to C!
[  165.391423] Extended CMOS year: 2000
[  165.391550] Enabling non-boot CPUs ...
[  165.391565] cpufreq-core: setting new policy for CPU 0: 800000 - 2201000 kHz
[  165.391566] acpi-cpufreq: acpi_cpufreq_verify
[  165.391568] freq-table: request for verification of policy (800000 - 2201000 kHz) for cpu 0
[  165.391570] freq-table: verification lead to (800000 - 2201000 kHz) for cpu 0
[  165.391573] acpi-cpufreq: acpi_cpufreq_verify
[  165.391575] freq-table: request for verification of policy (800000 - 2201000 kHz) for cpu 0
[  165.391577] freq-table: verification lead to (800000 - 2201000 kHz) for cpu 0
[  165.391579] cpufreq-core: new min and max freqs are 800000 - 2201000 kHz
[  165.391580] cpufreq-core: governor: change or update limits
[  165.391582] cpufreq-core: __cpufreq_governor for CPU 0, event 3
[  165.391647] CPU0 attaching NULL sched-domain.
[  165.391762] SMP alternatives: switching to SMP code
[  165.399962] Booting processor 1/1 ip 6000
[  165.408392] Initializing CPU#1
[  165.408392] Calibrating delay using timer specific routine.. 4391.46 BogoMIPS (lpj=8782923)
[  165.408392] CPU: L1 I cache: 32K, L1 D cache: 32K
[  165.408392] CPU: L2 cache: 4096K
[  165.408392] CPU: Physical Processor ID: 0
[  165.408392] CPU: Processor Core ID: 1
[  165.489023] CPU1: Intel(R) Core(TM)2 Duo CPU     T7500  @ 2.20GHz stepping 0b
[  165.489056] CPU0 attaching sched-domain:
[  165.489059]  domain 0: span 0-1
[  165.489060]   groups: 0 1
[  165.489063] CPU1 attaching sched-domain:
[  165.489065]  domain 0: span 0-1
[  165.489066]   groups: 1 0
[  165.408392] cpufreq-core: adding CPU 1
[  165.408392] acpi-cpufreq: acpi_cpufreq_cpu_init
[  165.408392] ACPI Error (psloop-0136): Found unknown opcode FE at AML address f883c7ca offset 3, ignoring [20080321]
[  165.408392] ACPI Error (psloop-0136): Found unknown opcode 1F at AML address f883c7cd offset 6, ignoring [20080321]
[  165.408392] ACPI Error (psloop-0136): Found unknown opcode 2 at AML address f883c7d4 offset D, ignoring [20080321]
[  165.408392] ACPI Error (psloop-0136): Found unknown opcode C2 at AML address f883c7d6 offset F, ignoring [20080321]
[  165.408392] ACPI Error (psargs-0358): [E] Namespace lookup failure, AE_NOT_FOUND
[  165.408392] ACPI Error (psparse-0530): Method parse/execution failed [\_PR_.CPU1._PCT] (Node f4c17930), AE_NOT_FOUND
[  165.408392] ACPI Exception (processor_perflib-0191): AE_NOT_FOUND, Evaluating _PCT [20080321]
[  165.408392] cpufreq-core: initialization failed
[  165.408392] CPU1 is up
[  165.512254] Switched to high resolution mode on CPU 1


Changed governor to performance:

[  247.730430] cpufreq-core: setting new policy for CPU 0: 800000 - 2201000 kHz
[  247.730430] acpi-cpufreq: acpi_cpufreq_verify
[  247.730430] freq-table: request for verification of policy (800000 - 2201000 kHz) for cpu 0
[  247.730430] freq-table: verification lead to (800000 - 2201000 kHz) for cpu 0
[  247.730430] acpi-cpufreq: acpi_cpufreq_verify
[  247.730430] freq-table: request for verification of policy (800000 - 2201000 kHz) for cpu 0
[  247.730430] freq-table: verification lead to (800000 - 2201000 kHz) for cpu 0
[  247.730430] cpufreq-core: new min and max freqs are 800000 - 2201000 kHz
[  247.730430] cpufreq-core: governor switch
[  247.730430] cpufreq-core: __cpufreq_governor for CPU 0, event 2
[  247.730430] cpufreq-core: __cpufreq_governor for CPU 0, event 1
[  247.730430] performance: setting to 2201000 kHz because of event 1
[  247.730430] cpufreq-core: target for CPU 0: 2201000 kHz, relation 1
[  247.730430] acpi-cpufreq: acpi_cpufreq_target 2201000 (0)
[  247.730430] freq-table: request for target 2201000 kHz (relation: 1) for cpu 0
[  247.730430] freq-table: target is 0 (2201000 kHz, 0)
[  247.730430] cpufreq-core: notification 0 of frequency transition to 2201000 kHz
[  247.730430] cpufreq-core: notification 1 of frequency transition to 2201000 kHz
[  247.730430] cpufreq-core: governor: change or update limits
[  247.730430] cpufreq-core: __cpufreq_governor for CPU 0, event 3
[  247.730430] performance: setting to 2201000 kHz because of event 3
[  247.730430] cpufreq-core: target for CPU 0: 2201000 kHz, relation 1
[  247.730430] acpi-cpufreq: acpi_cpufreq_target 2201000 (0)
[  247.730430] freq-table: request for target 2201000 kHz (relation: 1) for cpu 0
[  247.730430] freq-table: target is 0 (2201000 kHz, 0)
[  247.730430] acpi-cpufreq: Called after resume, resetting to P0
[  247.730430] cpufreq-core: notification 0 of frequency transition to 2201000 kHz
[  247.730430] cpufreq-core: notification 1 of frequency transition to 2201000 kHz



Changing governor to ondemand:

[  264.608272] cpufreq-core: setting new policy for CPU 0: 800000 - 2201000 kHz
[  264.608272] acpi-cpufreq: acpi_cpufreq_verify
[  264.608272] freq-table: request for verification of policy (800000 - 2201000 kHz) for cpu 0
[  264.608272] freq-table: verification lead to (800000 - 2201000 kHz) for cpu 0
[  264.608272] acpi-cpufreq: acpi_cpufreq_verify
[  264.608272] freq-table: request for verification of policy (800000 - 2201000 kHz) for cpu 0
[  264.608272] freq-table: verification lead to (800000 - 2201000 kHz) for cpu 0
[  264.608272] cpufreq-core: new min and max freqs are 800000 - 2201000 kHz
[  264.608272] cpufreq-core: governor switch
[  264.608272] cpufreq-core: __cpufreq_governor for CPU 0, event 2
[  264.608272] cpufreq-core: __cpufreq_governor for CPU 0, event 1
[  264.608272] cpufreq-core: governor: change or update limits
[  264.608272] cpufreq-core: __cpufreq_governor for CPU 0, event 3
[  264.630611] __ratelimit: 20 messages suppressed
[  264.630618] acpi-cpufreq: cpu 0: performance percent 77


Comment 2 Zhang Rui 2008-05-18 17:56:34 UTC
Please attach the output of dmesg after boot and the acpidump here.
Comment 3 Dennis Noordsij 2008-05-19 00:30:49 UTC
Created attachment 16187 [details]
dmesg of a fresh boot, suspend, then resume

As requested: fresh boot dmesg. At 165.39 the system is suspended to RAM and woken up.
Comment 4 Dennis Noordsij 2008-05-19 00:34:54 UTC
Created attachment 16188 [details]
acpidump output

As requested: acpidump output. Note that I have tried a "fixed" DSDT which fixes some of the errors/warnings, but this has no different effect.
Comment 5 Dennis Noordsij 2008-05-19 00:36:11 UTC
Created attachment 16189 [details]
disassembled dsdt
Comment 6 Zhang Rui 2008-05-19 01:28:59 UTC
Please run:
acpidump --addr 0x7FE5C4F6 --length 0x286 > cpu0ist
acpidump --addr 0x7FE5C77C --length 0xC4 > cpu1ist
acpidump --addr 0x7FE5BE8C --length 0x5E5 > cpu0cst
acpidump --addr 0x7FE5C471 --length 0x85 > cpu1cst

The _PCT method should be in these dynamic tables.
Comment 7 Dennis Noordsij 2008-05-19 01:39:52 UTC
Created attachment 16190 [details]
acpidump outputs as requested

Hope it is OK I tar'd them (didn't want to spam)
Comment 8 Khashayar Naderehvandi 2008-05-20 03:08:40 UTC
Need to follow this bug.
Comment 9 Dennis Noordsij 2008-05-22 03:17:22 UTC
Created attachment 16244 [details]
Merged CPU*ST and SSDT into the DSDT

I have extracted the relevant parts of the SSDT, CPU0IST, CPU1IST, CPU0CST and CPU0IST tables and embedded them directly into the DSDT, and booted with that as well as the option "acpi_no_auto_ssdt".

(Had to also fix a few minor errors to compile it)

This gives me the following new acpi errors:

[   15.569530] ACPI Exception (exoparg2-0442): AE_AML_PACKAGE_LIMIT, Index (000000001) is beyond end of object [20070126]
[   15.569536] ACPI Error (psparse-0537): Method parse/execution failed [\_PR_.CPU0._OSC] (Node f7c47d80), AE_AML_PACKAGE_LIMIT
[   15.569572] ACPI Error (psparse-0537): Method parse/execution failed [\_PR_.CPU0._PDC] (Node f7c47d68), AE_AML_PACKAGE_LIMIT
[   15.570156] ACPI Exception (exoparg2-0442): AE_AML_PACKAGE_LIMIT, Index (000000004) is beyond end of object [20070126]
[   15.570162] ACPI Error (psparse-0537): Method parse/execution failed [\_PR_.CPU1._OSC] (Node f7c47e70), AE_AML_PACKAGE_LIMIT
[   15.570193] ACPI Error (psparse-0537): Method parse/execution failed [\_PR_.CPU1._PDC] (Node f7c47e58), AE_AML_PACKAGE_LIMIT

but frequency scaling (still) works, AND now also works when resuming from standby.

Since originally the search for \_CPU1._PCT runs into unknown opcodes, can there be some corruption going on ? _PCT seems to be there, and seems to generally work. The problem is in trying to locate it after resume ?

Please advise if you have any suggestions where I should continue to look for the cause.
Comment 10 Dariush Forouher 2008-05-23 00:24:28 UTC
Confirmed this bug.

Hardware Environment: Dell Latitude D630 (BIOS rev. A10)
Software Environment: Ubuntu Hardy
Kernel: 2.6.25 (mainline)

dmesg output after resume from S3: 

[ 3038.576849] Back to C!
[ 3038.577288] Enabling non-boot CPUs ...
[ 3038.577352] CPU0 attaching NULL sched-domain.
[ 3038.577494] SMP alternatives: switching to SMP code
[ 3038.578559] Booting processor 1/1 ip 4000
[ 3155.527155] Initializing CPU#1
[ 3155.527155] Calibrating delay using timer specific routine.. 4389.08 BogoMIPS (lpj=8778165)
[ 3155.527155] CPU: L1 I cache: 32K, L1 D cache: 32K
[ 3155.527155] CPU: L2 cache: 4096K
[ 3155.527155] CPU: Physical Processor ID: 0
[ 3155.527155] CPU: Processor Core ID: 1
[ 3155.527155] Intel machine check architecture supported.
[ 3155.527155] Intel machine check reporting enabled on CPU#1.
[ 3038.667153] CPU1: Intel(R) Core(TM)2 Duo CPU     T7500  @ 2.20GHz stepping 0b
[ 3038.667173] kvm: enabling virtualization on CPU1
[ 3038.667193] CPU0 attaching sched-domain:
[ 3038.667195]  domain 0: span 3
[ 3038.667196]   groups: 1 2
[ 3038.667198]   domain 1: span 3
[ 3038.667200]    groups: 3
[ 3038.667202] CPU1 attaching sched-domain:
[ 3038.667203]  domain 0: span 3
[ 3038.667204]   groups: 2 1
[ 3038.667206]   domain 1: span 3
[ 3038.667207]    groups: 3
[ 3155.527155] ACPI Error (psloop-0136): Found unknown opcode FE at AML address f8cf67ca offset 3, ignoring [20070126]
[ 3155.527155] nssearch-0336 [00] ns_search_and_enter   : Found bad character(s) in name, repaired: [C***]
[ 3155.527155] ACPI Error (psargs-0355): [C���.D��] Namespace lookup failure, AE_NOT_FOUND
[ 3155.527155] ACPI Error (psparse-0537): Method parse/execution failed [\_PR_.CPU1._PCT] (Node f7818888), AE_NOT_FOUND
[ 3155.527155] ACPI Exception (processor_perflib-0191): AE_NOT_FOUND, Evaluating _PCT [20070126]
[ 3155.527155] CPU1 is up
[ 3155.527170] Switched to high resolution mode on CPU 1
[ 3155.618445] PM: Writing back config space on device 0000:00:02.0 at offset f (was 100, writing 10b)
[...]

After that cpufreq doesn't recognise the 2nd CPU anymore (as Dennis described).

I could also provide more information, if needed.

Dariush
Comment 11 ykzhao 2008-05-23 00:56:55 UTC
Will you please attach the following outputs after the system is resumed from the suspend state? (Note: please do this after the system is resumed.)
acpidump --addr 0x7FE5C4F6 --length 0x286 > cpu0ist
acpidump --addr 0x7FE5C77C --length 0xC4 > cpu1ist
acpidump --addr 0x7FE5BE8C --length 0x5E5 > cpu0cst
acpidump --addr 0x7FE5C471 --length 0x85 > cpu1cst

Thanks.
Comment 12 Dariush Forouher 2008-05-23 01:12:39 UTC
> acpidump --addr 0x7FE5C4F6 --length 0x286 > cpu0ist
> acpidump --addr 0x7FE5C77C --length 0xC4 > cpu1ist
> acpidump --addr 0x7FE5BE8C --length 0x5E5 > cpu0cst
> acpidump --addr 0x7FE5C471 --length 0x85 > cpu1cst

Done that. They are all filled completely with 0xFF.

Dariush
Comment 13 Dariush Forouher 2008-05-23 01:41:39 UTC
Created attachment 16253 [details]
acpi dump

Note: The acpidump of the addresses you've given are 0xFF even before suspending.

Also attached the acpidump output (it differs slightly from Dennis' one).

Dariush
Comment 14 Dennis Noordsij 2008-05-23 02:17:46 UTC
Dariush: note that those addresses were based on my system.
What you are looking for is:

dmesg | grep Cpu | grep st

[   14.437438] ACPI: SSDT 7FE5C4F6, 0286 (r1  PmRef  Cpu0Ist     3000 INTL 20050624)
[   14.437597] ACPI: SSDT 7FE5BE8C, 05E5 (r1  PmRef  Cpu0Cst     3001 INTL 20050624)
[   14.438352] ACPI: SSDT 7FE5C77C, 00C4 (r1  PmRef  Cpu1Ist     3000 INTL 20050624)
[   14.438497] ACPI: SSDT 7FE5C471, 0085 (r1  PmRef  Cpu1Cst     3000 INTL 20050624)

The value after SSDT is the address, the next is the length, both in hex so prefix with 0x.

Comment 15 Dennis Noordsij 2008-05-23 02:22:39 UTC
Created attachment 16254 [details]
Cpu*st tables before and after resume (*Ist become corrupted)

Attached the CPU tables before and after resume.

The Cst tables remain the same, the Ist tables seem to have gotten corrupted (partially similar, partially garbage, can not be disassembled by iasl anymore). This seems to make sense with the observed bug.

Please advise on further testing or suggestions. Many thanks for the help so far!
Comment 16 Dariush Forouher 2008-05-23 04:17:55 UTC
Created attachment 16255 [details]
acpidump, cpu*st, dmesg

Ah yes, thanks Dennis.

Attached the cpu*st dumps before and after.

Dariush
Comment 17 Dennis Noordsij 2008-05-23 10:45:55 UTC
FWIW, the same corruption happens when resuming under Windows XP, ruling out any Linux bug causing it. 

(confirmed using RW Read & Write utility http://jacky5488.myweb.hinet.net/index.htm)

I don't know if and how this affects the CPU frequency scaling under Windows XP (note that the laptop was intended for Vista).

<acpi_noob>
Should the Linux ACPI stack make a private copy of the external tables ? 
</acpi_noob>
Comment 18 ykzhao 2008-05-25 01:22:39 UTC
Thanks for the info.
The ACPI tables(for example: CPU0IST, CPU1IST) reside in the following address range. After the system is resumed, the content can't be resumed correctly.
>BIOS-e820: 000000007fe5b800 - 0000000080000000 (reserved)
Because the ACPI tables become incorrect (For example: Cpu0IST, CPU1IST)and the objects in the ACPI tables are required, the ACPI cpufreq driver can't work well. Of course maybe there will be some potential issues.
IMO this is a bios bug and it had better be fixed by upgrading bios.
Comment 19 Dennis Noordsij 2008-05-25 01:45:35 UTC
True, however the latest BIOS does not seem to fix this (Dariush: which version are you using? A10?), and working around broken BIOS's is part of the fun isn't it? :-)

As an alternative solution, since apparantly other OS's manage to work around this, and there are many users with this problem, what needs to be done to make acpi_cpufreq unloadable ?

Currently once it is loaded it is always "in use". This issue would be managable by blacklisting acpi_cpufreq on suspend, and loading it again on resume. The _PCT is never actually followed in the initialization, only when resuming. However the only way currently is to remove it by force, which is not good.

Comment 20 Dariush Forouher 2008-05-25 02:31:54 UTC
Yes, I use BIOS rev. A10 (upgraded during testing this bug.). 

I suspect that we will have to make Dell aware of this Bug to actually get it fixed.

BTW: Dennis, I tried your modified DSDT and it works fine! Up to now I didn't notice any regressions, so thank you very much!

Have a nice sunday!
Dariush
Comment 21 Dennis Noordsij 2008-05-25 09:01:33 UTC
Created attachment 16275 [details]
Copy external ACPI tables to our own buffer instead of mapping them

Copying the tables rather than mapping them (this only applies to the external tables, not the standard ones, so it is at most a few KB) works around the issue completely. After my first tests, this seems to resume correctly without any issue.

A solution which does not require explicit workarounds (blacklisting certain modules) but which just works is of course preferred.

Now, I don't know nearly enough to tell if this would break (other) things horribly, or if this goes against some policy, so please comment on wether something like this should or should not be done, as well as suggest on how this issue can be worked around permanently (such as a specific blacklist which enables this on known bad BIOS's? etc).

Patch is against latest ACPI tree git, should apply against both test and release branches.

Dariush: is it possible for you to test this ? It should apply against a vanilla kernel with at most small modifications.
Comment 22 Dariush Forouher 2008-05-25 13:51:32 UTC
Dennis: Yes, it works! I tried it against the current linux-2.6 git tree. With this patch the laptop behaves exactly like with your modified DSDT (no strange ACPI messages or similar).

To me this also seems like a good workaround. But as I am an even bigger ACPI noob than you, I'll better leave this assessment to the experts. :-)

Dariush
Comment 23 ykzhao 2008-05-25 17:45:35 UTC
Hi, Dennis
    Thanks for your great work. What you have done is very terrific.
    In current kernel when one ACPI table is loaded, thememory region is only mapped instead of copying them to the buffer. If the memory region is crashed in the course of suspend/resume, the objects can't be accessed. Maybe it will be better that OS copies the ACPI tables instead of mapping them.
    
    Thanks for your great work again.
Comment 24 Shaohua 2008-05-25 19:59:42 UTC
Did we confirm windows work in the system?
Comment 25 Dennis Noordsij 2008-05-26 02:04:40 UTC
Created attachment 16280 [details]
Cleaned up patch

- Added ACPI_FREE in the case acpi_os_map_memory fails.
- Made patch compliant with submission requirements.

What is now the next step ? Will it be considered for inclusion in the acpi test tree automatically or do I need to send it somewhere?
Comment 26 Mario Limonciello 2008-05-27 08:44:37 UTC
Hi Dennis:

I verified that your patch worked correctly for me on my XPS M1330.  
Thanks!
Comment 27 Robert Moore 2008-06-04 15:31:53 UTC
Does Unload() automatically work with this patch?
Comment 28 Dennis Noordsij 2008-06-04 15:54:32 UTC
Robert: Yes, it should, there should be no side-effects from changing the table type from mapped to allocated.

If you have some specific test (to confirm) in mind I would be happy to try it.
Comment 29 Robert Moore 2008-06-11 10:53:29 UTC
Do we have permission from the author to port this patch and include it into ACPICA?
Comment 30 Dennis Noordsij 2008-06-11 11:01:45 UTC
Robert: Yes, please feel free to do so.
Comment 31 Robert Moore 2008-06-11 12:18:05 UTC
Created attachment 16460 [details]
ACPICA version of load table patch

Attached is the ported version of the code. A few changes, notably that we simply always use the table length, since it must be correct if the table is valid.
Comment 32 Robert Moore 2008-06-11 13:46:07 UTC
I doesn't look like the table checksum gets validated in the load from region case.
Comment 33 Zhang Rui 2008-06-30 01:57:03 UTC
Dennis, could you please attach the lspci output?
Comment 34 Dennis Noordsij 2008-06-30 03:03:29 UTC
Created attachment 16663 [details]
output of sudo lspci -v

Added on request
Comment 35 Robert Moore 2008-07-30 14:31:00 UTC
Change was integrated and released in ACPICA version 20080701
Comment 36 Len Brown 2008-09-22 14:37:38 UTC
workaround patch is now in acpi test tree, thanks guys!
Comment 37 Len Brown 2008-10-16 22:21:42 UTC
specifically, the patch in the tree is this one:
Author: Dennis Noordsij <dennis.noordsij@helsinki.fi>  2008-08-14 21:37:58
Committer: Len Brown <len.brown@intel.com>  2008-09-22 17:39:13
Parent: d3ff268a0149fce8835f6d48ab481d5e3321e0f7 (ACPICA: Fix possible memory leak in Unload() operator)
Child:  76a509bb8fabcfe111be65b67cfdc03d4768b654 (ACPICA: Fix warning for 64-bit build)
Branches: acpica, acpica-fixes, test
Follows: v2.6.27-rc7
Precedes: 

    ACPICA: Copy dynamically loaded tables to local buffer
Comment 38 Len Brown 2008-10-24 22:56:12 UTC
shipped in linux-2.6.28-rc1
closed

commit f0e0da8a6cca44396c7a711e308d58084e881617
Author: Dennis Noordsij <dennis.noordsij@helsinki.fi>
Date:   Fri Aug 15 09:37:58 2008 +0800

    ACPICA: Copy dynamically loaded tables to local buffer

    Previously, dynamically loaded tables were simply mapped, but on some machines
    this memory is corrupted after suspend. Now copy the table to a local buffer.
    For OpRegion case, added checksum verify. Use the table length from the table header,
    not the region length. For Buffer case, use the table length also.

Note You need to log in before you can comment on or make changes to this bug.