Bug 16357

Summary: acpi-cpufreq fails to load (No such device) if CONFIG_SMP=n
Product: ACPI Reporter: Ambroz Bizjak (ambrop7)
Component: Power-ProcessorAssignee: acpi_power-processor
Severity: normal CC: achiang, acpi-bugzilla, akpm, deng, embeter, florian, lenb, maciej.rutecki, ming.m.lin, rjw, trenn
Priority: P1    
Hardware: All   
OS: Linux   
Kernel Version: Subsystem:
Regression: Yes Bisected commit-id:
Bug Depends on:    
Bug Blocks: 15310    
Attachments: config for
config for
dmesg for
dmesg for
config for
dmesg for
dmesg for with patch, cpufreq broken
dmesg for with both patches

Description Ambroz Bizjak 2010-07-09 09:40:21 UTC
Created attachment 27053 [details]
config for

After updating from to, acpi-cpufreq no longer works.
"modprobe acpi-cpufreq" gives "FATAL: Error inserting acpi_cpufreq (...): No such device". I don't get any errors in dmesg after modprobe.
Also if acpi-cpufreq is linked statically, it doesn't work (cpufreq-info reports no driver).
Motherboard is Intel D945GSEJT (with Atom N270 CPU).
Comment 1 Ambroz Bizjak 2010-07-09 09:40:46 UTC
Created attachment 27054 [details]
config for
Comment 2 Ambroz Bizjak 2010-07-09 09:41:08 UTC
Created attachment 27055 [details]
dmesg for
Comment 3 Ambroz Bizjak 2010-07-09 09:41:24 UTC
Created attachment 27056 [details]
dmesg for
Comment 4 Thomas Renninger 2010-07-09 10:23:03 UTC
In these additional lines are present:
ACPI: SSDT 3f5dac90 00239 (v02 INTEL  D945JT   00003000 INTL 20051117)
ACPI: SSDT 3f5d9710 006B7 (v02 INTEL  D945JT   00003001 INTL 20051117)
Monitor-Mwait will be used to enter C-1 state
Monitor-Mwait will be used to enter C-2 state
Monitor-Mwait will be used to enter C-3 state
Marking TSC unstable due to TSC halts in idle

The SSDTs probably contain the cpufreq tables loaded at late at runtime when the processor driver gets loaded.
I expect you also do not get C2/C3 with the new kernel?
cat /proc/acpi/processor/*/power

Ah, I remember this one, I expect this comes from:
# CONFIG_SMP is not set

and the fact that a the processor id in drivers/acpi/processor*.c is -1 in case of UP kernels.
AFAIK this got introduced with commit 5d554a7bb0643a6151a84319bfeba8270bf5269e and got discussed/addressed on a mail thread on linux-acpi:
Date: 2010-06-17

Alex should know more and whether this already is queued for stable 2.6.34...
Comment 5 Thomas Renninger 2010-07-09 10:27:36 UTC
This is an ACPI and not a cpufreq bug -> reassigning components.
Comment 6 Ambroz Bizjak 2010-07-09 18:49:02 UTC
Yes, /proc/acpi/processor/*/power only has C1.
I confirm that changing the line
"if (cpuid == -1)"
"if (cpuid == -1 && num_possible_cpus() > 1)"
in drivers/acpi/processor_core.c solves this issue.
Comment 7 Andrew Morton 2010-07-09 23:18:56 UTC
Can someone email out the patch please?
Comment 8 Rafael J. Wysocki 2010-07-09 23:58:16 UTC
Handled-By : Thomas Renninger <trenn@suse.de>
Comment 9 Len Brown 2010-07-12 17:29:51 UTC
resolved by:

which is now in the acpi test tree.
Comment 10 Len Brown 2010-07-26 23:59:48 UTC
commit 856b185dd23da39e562983fbf28860f54e661b41
Author: Alex Chiang <achiang@canonical.com>
Date:   Thu Jun 17 09:08:54 2010 -0600

    ACPI: processor: fix processor_physically_present on UP

shipped in linux-2.6.35-rc6 post git1

Comment 11 David Engster 2010-08-08 11:40:18 UTC
I'm afraid this patch makes my machine crash upon boot. It's an Acer Extensa 5235 with an Intel Celeron M900 (single core, no cpufreq, newest BIOS installed). Kernel used is the Archlinux stock kernel, its config can be found here:


The crash is as follows:

WARNING: at mm/page_alloc.c:1828 __alloc_pages_nodemask+0x47e/0x580()
Hardware name: Extensa 5235     
Modules linked in:
Pid: 1, comm: swapper Not tainted 2.6.34-ARCH #1
Call Trace:
[<c10430fd>] warn_slowpath_common+0x6d/0xa0
[<c10c214e>] ? __alloc_pages_nodemask+0x47e/0x580
[<c10c214e>] ? __alloc_pages_nodemask+0x47e/0x580
[<c1043145>] warn_slowpath_null+0x15/0x20
[<c10c214e>] __alloc_pages_nodemask+0x47e/0x580
[<c12cac1c>] ? acpi_os_map_memory+0x11/0x25
[<c11d748b>] ? acpi_ex_system_memory_space_handler+0x10b/0x1fd
[<c10c2267>] __get_free_pages+0x17/0x30
[<c10e9ac5>] __kmalloc+0xf5/0x1a0
[<c11d31fd>] ? acpi_ex_region_read+0x25/0x41
[<c11d3464>] acpi_ex_load_op+0x14b/0x287
[<c11d5298>] acpi_ex_opcode_1A_1T_0R+0x20/0x44
[<c11cde1d>] acpi_ds_exec_end_op+0xd2/0x371
[<c11de506>] acpi_ps_parse_loop+0x6d3/0x831
[<c11dda33>] acpi_ps_parse_aml+0x82/0x25f
[<c11dec33>] acpi_ps_execute_method+0x18b/0x220
[<c11da89c>] acpi_ns_evaluate+0xc0/0x176
[<c11da3b8>] acpi_evaluate_object+0x167/0x256
[<c11c77fc>] acpi_processor_set_pdc+0x25b/0x27e
[<c11c7a58>] early_init_pdc+0xaa/0xae
[<c11dbfa6>] acpi_ns_walk_namespace+0xb0/0x17a
[<c11c79ae>] ? early_init_pdc+0x0/0xae
[<c11da227>] acpi_walk_namespace+0x65/0x8f
[<c11c79ae>] ? early_init_pdc+0x0/0xae
[<c142ea28>] acpi_early_processor_set_pdc+0x28/0x2d
[<c11c79ae>] ? early_init_pdc+0x0/0xae
[<c142e663>] acpi_init+0xfb/0x2c1
[<c100120d>] do_one_initcall+0x2d/0x190
[<c142e568>] ? acpi_init+0x0/0x2c1
[<c140b960>] kernel_init+0x132/0x1cd
[<c140b82e>] ? kernel_init+0x0/0x1cd
[<c1003d3e>] kernel_thread_helper+0x6/0x18

I think I could bisect this crash to this commit:


I also verified that reverting the above patch in makes the kernel boot again. The acpidump from the Extensa 5235 can be found here:

Comment 12 Roman 2010-08-09 12:40:16 UTC
Got a kernel crash caused by this commit: https://bugzilla.kernel.org/show_bug.cgi?id=16548
Comment 13 Alex Chiang 2010-08-19 12:29:16 UTC
The crashes in comment #11 and comment #12 are not caused by this patch.

They only seem to bisect here because this patch changes the return value. The real bugs are elsewhere.

Please open a new bug for comment #11.
Comment 14 Lin Ming 2011-05-12 08:35:56 UTC

Could you have a try the patch at https://bugzilla.kernel.org/show_bug.cgi?id=16548#c42 to see if it still works for you?

Note that you don't need the "memmap=" option I mentioned there.

Comment 15 Ambroz Bizjak 2011-05-12 09:32:40 UTC
the patch breaks cpufreq on my system (kernel, UP system, UP kernel). I'm attaching the config and dmesg's.
Comment 16 Ambroz Bizjak 2011-05-12 09:33:28 UTC
Created attachment 57512 [details]
config for
Comment 17 Ambroz Bizjak 2011-05-12 09:33:51 UTC
Created attachment 57522 [details]
dmesg for
Comment 18 Ambroz Bizjak 2011-05-12 09:34:20 UTC
Created attachment 57532 [details]
dmesg for with patch, cpufreq broken
Comment 19 Lin Ming 2011-05-12 13:13:18 UTC
Please attach the acpidump output.
And add below code to print the acpi_id. Let's see what it is.

diff --git a/drivers/acpi/processor_core.c b/drivers/acpi/processor_core.c
index 51348d4..e612a7f 100644
--- a/drivers/acpi/processor_core.c
+++ b/drivers/acpi/processor_core.c
@@ -224,6 +224,7 @@ static bool __init processor_physically_present(acpi_handle handle)
                 * Ingore cpuid and return true for processor 0,
                 * return false for other processors
+               printk("DEBUG: acpi_id = %d\n", acpi_id);
                if (acpi_id == 0)
                        return true;
Comment 20 Ambroz Bizjak 2011-05-12 19:08:02 UTC
Created attachment 57642 [details]
Comment 21 Ambroz Bizjak 2011-05-12 19:08:47 UTC
Created attachment 57652 [details]
dmesg for with both patches
Comment 22 Lin Ming 2011-05-13 05:55:34 UTC
Could you have a try the updated patch at

I bet it will works for you.
Comment 23 Ambroz Bizjak 2011-05-13 08:48:44 UTC
Yes, this patch works.
Comment 24 Florian Mickler 2011-05-30 08:01:30 UTC
A patch referencing this bug report has been merged in v3.0-rc1:

commit 932df7414336a00f45e5aec62724cf736b0bcfd4
Author: Lin Ming <ming.m.lin@intel.com>
Date:   Mon May 16 09:11:00 2011 +0800

    ACPI: processor: fix processor_physically_present in UP kernel