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.
(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
Please attach the output of dmesg after boot and the acpidump here.
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.
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.
Created attachment 16189 [details] disassembled dsdt
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.
Created attachment 16190 [details] acpidump outputs as requested Hope it is OK I tar'd them (didn't want to spam)
Need to follow this bug.
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.
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
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.
> 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
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
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.
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!
Created attachment 16255 [details] acpidump, cpu*st, dmesg Ah yes, thanks Dennis. Attached the cpu*st dumps before and after. Dariush
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>
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.
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.
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
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.
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
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.
Did we confirm windows work in the system?
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?
Hi Dennis: I verified that your patch worked correctly for me on my XPS M1330. Thanks!
Does Unload() automatically work with this patch?
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.
Do we have permission from the author to port this patch and include it into ACPICA?
Robert: Yes, please feel free to do so.
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.
I doesn't look like the table checksum gets validated in the load from region case.
Dennis, could you please attach the lspci output?
Created attachment 16663 [details] output of sudo lspci -v Added on request
Change was integrated and released in ACPICA version 20080701
workaround patch is now in acpi test tree, thanks guys!
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
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.