Bug 16357

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