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).
Created attachment 27054 [details] config for 2.6.34.1
Created attachment 27055 [details] dmesg for 2.6.33.6
Created attachment 27056 [details] dmesg for 2.6.34.1
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...
This is an ACPI and not a cpufreq bug -> reassigning components.
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.
Can someone email out the patch please?
Handled-By : Thomas Renninger <trenn@suse.de>
resolved by: https://patchwork.kernel.org/patch/106696/ which is now in the acpi test tree.
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
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
Got a kernel crash caused by this commit: https://bugzilla.kernel.org/show_bug.cgi?id=16548
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.
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.
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.
Created attachment 57512 [details] config for 2.6.35.12
Created attachment 57522 [details] dmesg for 2.6.35.12
Created attachment 57532 [details] dmesg for 2.6.35.12 with patch, cpufreq broken
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
Created attachment 57642 [details] acpidump
Created attachment 57652 [details] dmesg for 2.6.35.12 with both patches
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.
Yes, this patch works.
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