Most recent kernel where this bug did not occur: 2.6.15 Distribution: Debian testing/unstable Hardware Environment: IBM Thinkpad T43 Problem Description: I reported in bug #6474 that acpi-cpufreq did not work anymore since 2.6.15-mm2 and 2.6.16. The bug has been closed on June 5th with the reason "All ACPI related things have been removed from the speedstep-centrino driver and added to the acpi-cpiufreq one. acpi-cpufreq now combines MSR and SystemIO capabilities." With 2.6.18-rc1, acpi-cpufreq was able to load again, but it did not work. It seemed to acquire the device but no cpufreq capability seemed to be exported. speedstep-centrino still worked fine. I reported this on #6474 and was told to open a new bug. Here we are. Now, with -rc4-gkh1, acpi-cpufreq fails to load with EINVAL. I tracked down the EINVAL to the following code in acpi_processor_preregister_performance() in drivers/acpi/processor_perflib.c:636: pr->performance = performance[i]; cpu_set(i, pr->performance->shared_cpu_map); if (acpi_processor_get_psd(pr)) { retval = -EINVAL; continue; } acpi_processor_get_psd() seems to fail at: status = acpi_evaluate_object(pr->handle, "_PSD", NULL, &buffer); if (ACPI_FAILURE(status)) { return -ENODEV; } Debugging ACPI further more looks hard to me, so I'd rather get some feedback first since there might be an obvious reason. According to x86info, my processor is: Family: 6 Model: 13 Stepping: 8 Type: 0 Brand: 6 CPU Model: (Dothan) [C-0] /proc/cpuinfo says: processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 13 model name : Intel(R) Pentium(R) M processor 1.86GHz stepping : 8 cpu MHz : 1862.104 cache size : 2048 KB fdiv_bug : no hlt_bug : no f00f_bug : no coma_bug : no fpu : yes fpu_exception : yes cpuid level : 2 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat clflush dts acpi mmx fxsr sse sse2 ss tm pbe nx est tm2 bogomips : 3727.70 My BIOS is supposed to be uptodate. I will attach dmesg. Thank you in advance
Created attachment 8802 [details] dmesg
OK. As speedstep-centrino is still working in 2.6.18-rc4. The reason for acpi-cpufreq to be returning EINVAL, as you correctly identified, is get_psd() call and someone else reported this problem last week and it was fixed with this patch http://www.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.18- rc4/2.6.18-rc4-mm2/broken-out/cpufreq-acpi-cpufreq-ignore-failure-from- acpi_cpufreq_early_init_acpi.patch Patch should get into mainline soon. And combining of speedstep-centrino and acpi-cpufreq into one acpi-cpufreq, that is still pending and that may happen in 2.6.19 timeframe. Until then you can use speedstep-centrino.
I just tried the patch. It makes acpi-cpufreq load. But then nothing happens, nothing appears in /sys/devices/system/cpu/cpu0/cpufreq/. The only noticeable effect is that the device is busy, making speedstep-centrino fail to load with EBUSY until I unload acpi-cpufreq. Basically, the situation is as it was in 2.6.18-rc1 (I don't know about rc2 and rc3). I would be happy to help debugging. But I don't know where to look now. And I don't see any module parameter to enable debug in acpi-cpufreq. I can't test a -mm kernel on this computer. But, a ACPI git tree would be ok if you think I should give a try. I am totally OK with using speedstep-centrino, I have been doing so since 2.6.16 anyway. But I guess acpi-cpufreq should work on my processor. I let you decide whether the bug should be reopen or not. Thank you.
i don't see mention of a resolution that works here -- moving from resolved to open. does 2.6.18-rc7 work w/o any patches?
2.6.18-rc7 does not have acpi-cpufreq working either. acpi-cpufreq loads but does nothing except preventing speedstep-centrino from working since the device is busy. Fortunately, speedstep-centrino alone still works fine in 2.6.18-rc7.
This bad behavior of acpi-cpufreq loading and doing nothing was removed in 2.6.19-rc1. Can you please check and make sure whether the problem has gone away for you. Also, as speedstep-centrino is working for you, I will go ahead and close this bug. Reopen if you have any related issues. Thanks.
Yes, the problem of "acpi-cpufreq loading and doing nothing (except prevent speestep-centrino from loading)" is gone in 2.6.19-rc2 (I don't have rc1 anymore). Now, acpi-cpufreq does not load, it fails with ENODEV. Since it does not prevent speedstep-centrino from loading anymore, I think it is fine, we can just consider that acpi-cpufreq is not the right driver for my laptop. I will go on using speedstep-centrino. Thanks.