Bug 16357 - acpi-cpufreq fails to load (No such device) if CONFIG_SMP=n
Summary: acpi-cpufreq fails to load (No such device) if CONFIG_SMP=n
Status: CLOSED CODE_FIX
Alias: None
Product: ACPI
Classification: Unclassified
Component: Power-Processor (show other bugs)
Hardware: All Linux
: P1 normal
Assignee: acpi_power-processor
URL:
Keywords:
Depends on:
Blocks: 15310
  Show dependency tree
 
Reported: 2010-07-09 09:40 UTC by Ambroz Bizjak
Modified: 2011-05-30 08:20 UTC (History)
11 users (show)

See Also:
Kernel Version: 2.6.34.1
Subsystem:
Regression: Yes
Bisected commit-id:


Attachments
config for 2.6.33.6 (106.21 KB, text/plain)
2010-07-09 09:40 UTC, Ambroz Bizjak
Details
config for 2.6.34.1 (108.01 KB, text/plain)
2010-07-09 09:40 UTC, Ambroz Bizjak
Details
dmesg for 2.6.33.6 (27.27 KB, text/plain)
2010-07-09 09:41 UTC, Ambroz Bizjak
Details
dmesg for 2.6.34.1 (30.54 KB, text/plain)
2010-07-09 09:41 UTC, Ambroz Bizjak
Details
config for 2.6.35.12 (114.28 KB, application/octet-stream)
2011-05-12 09:33 UTC, Ambroz Bizjak
Details
dmesg for 2.6.35.12 (31.41 KB, application/octet-stream)
2011-05-12 09:33 UTC, Ambroz Bizjak
Details
dmesg for 2.6.35.12 with patch, cpufreq broken (30.54 KB, application/octet-stream)
2011-05-12 09:34 UTC, Ambroz Bizjak
Details
acpidump (88.76 KB, application/octet-stream)
2011-05-12 19:08 UTC, Ambroz Bizjak
Details
dmesg for 2.6.35.12 with both patches (30.57 KB, application/octet-stream)
2011-05-12 19:08 UTC, Ambroz Bizjak
Details

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

After updating from 2.6.33.6 to 2.6.34.1, 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 2.6.34.1
Comment 2 Ambroz Bizjak 2010-07-09 09:41:08 UTC
Created attachment 27055 [details]
dmesg for 2.6.33.6
Comment 3 Ambroz Bizjak 2010-07-09 09:41:24 UTC
Created attachment 27056 [details]
dmesg for 2.6.34.1
Comment 4 Thomas Renninger 2010-07-09 10:23:03 UTC
In 2.6.33.6 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:
Subject: [BUG, REGRESSION] ACPI: Set _PDC
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)"
to
"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:
https://patchwork.kernel.org/patch/106696/

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

closed
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 2.4.32.2 Archlinux stock kernel, its config can be found here:

http://repos.archlinux.org/wsvn/packages/kernel26/repos/core-i686/config

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:

http://git.kernel.org/?p=linux/kernel/git/stable/linux-2.6.34.y.git;a=commit;h=3fd02a351fc8aa8602fe2b39d6a098ea2538db2e

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

http://www.randomsample.de/acpidump.txt
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
Ambroz,

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.

Thanks.
Comment 15 Ambroz Bizjak 2011-05-12 09:32:40 UTC
Lin,
the patch breaks cpufreq on my system (kernel 2.6.35.12, 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 2.6.35.12
Comment 17 Ambroz Bizjak 2011-05-12 09:33:51 UTC
Created attachment 57522 [details]
dmesg for 2.6.35.12
Comment 18 Ambroz Bizjak 2011-05-12 09:34:20 UTC
Created attachment 57532 [details]
dmesg for 2.6.35.12 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;
 #endif
Comment 20 Ambroz Bizjak 2011-05-12 19:08:02 UTC
Created attachment 57642 [details]
acpidump
Comment 21 Ambroz Bizjak 2011-05-12 19:08:47 UTC
Created attachment 57652 [details]
dmesg for 2.6.35.12 with both patches
Comment 22 Lin Ming 2011-05-13 05:55:34 UTC
Could you have a try the updated patch at
https://bugzilla.kernel.org/show_bug.cgi?id=16548#c47?

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

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