I also tried with AC-power and battery power. This debug message: signature:0x47534943x, command:0x008200b2x, event:0x00000000x, perf_level:0x00000001. was same both times. (The processor speed is 500mhz when i boot up on battery and 650 with AC)
That's pretty weird. Dave, it hung in the middle of doing nothing...
Distribution: Gentoo ~x86 Hardware Environment: Dell Latitude C600 Laptop, latest BIOS Software Environment: N/A Problem Description: Kernel freezes after function speedstep_init which is defined in arch/i386/kernel/cpu/cpufreq/speedstep-smi.c The config option what installs it is: CONFIG_X86_SPEEDSTEP_SMI. I know that speedstep works (tested it on win2k machine).
Created attachment 1190 [details] lspci -v output Here is the lspci -v output.
Created attachment 1191 [details] How i tested it... I added these SPEEDSTEB_DEBUG #x debug messages. And i get the following output: SPEEDSTEP_DEBUG: #1 signature:0x47534943x, command:0x008200b2x, event:0x00000000x, perf_level:0x00000001. SPEEDSTEP_DEBUG: #2 SPEEDSTEP_DEBUG: #3 SPEEDSTEP_DEBUG: #3b SPEEDSTEP_DEBUG: #4 SPEEDSTEP_DEBUG: #4b SPEEDSTEP_DEBUG: #5 SPEEDSTEP_DEBUG: #5b SPEEDSTEP_DEBUG: #6 and after that it just hangs..
I also tried to this as a module. Dang... it freezed my system.
Created attachment 1342 [details] test-patch I doubt the hang actually occurs between debug #6 and #7... probably the hang is later, but doesn't properly get printed out... can you please try the attached patch [against plain 2.6.0-test9?]
I added test-patch and still no luck: Messages generated: passed first checks passed second checks, will now tru to register reached speedstep_cpu_init passed check for ownership
Created attachment 1362 [details] 2nd test patch specifically for bug reporter OK, the hang appears to be in speedstep_smi_get_freqs(). Can you try this patch, please? If this doesn't work, please try again with the following module options: smi_cmd=0x82 smi_port=0xb2
Doesn't hang anymore... but still not working... amd@Decoder amd $ dmesg | grep -i cpufreq cpufreq: change to 0 MHz succeded cpufreq: change to 500 MHz succeded cpufreq: currently at low speed setting - 500 MHz cpufreq: change to 650 MHz succeded cpufreq: No CPUs supporting ACPI performance management found. amd@Decoder amd $ dmesg |grep -i smi speedstep-smi: signature:0x47534943, command:0x008200b2, event:0x00000000, perf_level:0x00000101. speedstep-smi: could not detect low and high frequencies by SMI call. speedstep-smi: workaround worked.
> Doesn't hang anymore... but still not working... Actually, I _think_ it's working now: > amd@Decoder amd $ dmesg | grep -i cpufreq > cpufreq: change to 0 MHz succeded > cpufreq: change to 500 MHz succeded > cpufreq: currently at low speed setting - 500 MHz > cpufreq: change to 650 MHz succeded > cpufreq: No CPUs supporting ACPI performance management found. You can ignore the last line -- it was provided by a different cpufreq module. Is a /sys/devices/system/cpu/cpu0/cpufreq directory generated? If so, cpufreq works now. During the next few days, I'll try to post a different patch which disables the speedstep_smi_get_freqs call for systems like yours which do not support it.
Created attachment 1412 [details] bugfix This patch should automatically disable the call to speedstep_smi_get_freqs which caused the hang on the Dell Latitude C600. Please verify that 1) the hang doesn't occur any more 2) there is a /sys/devices/system/cpu/cpu0/cpufreq subdirectory with "sensefull" content. Thanks, Dominik
1) No hang occurs. 2) there is a senseful content in "/sys/devices/system/cpu/cpu0/cpufreq" but cat /proc/cpuinfo returns: cpu MHz : 179.461 I'm running it on 650MHz. And there's a minor typo in cpufreq debug messages (arch/i386/kernel/cpu/cpufreq/speedstep-smi.c:174): instead of "succeded" should be "succeeded" Anyway, everything else seems fine. Thanks, Dominik :D
The /proc/cpuinfo MHz information seems to be wrong, but that is a different issue - and it should be purely cosmetical. However, if "sleep 5" doesn't sleep for five but for 20 seconds, then please submit another BUG...
So.. if "echo x >/proc/acpi/sleep" fails then submit a bug? Currently S0, S2, S4 and S5 don't do anything. Should i add a new bug?
No, I meant if the command "sleep 5" (man 1 sleep) doesn't wait for five, but for any other amount of seconds, then you should open another bug. ACPI "sleep states", "Suspend" etc. are a different area, probably not affected by speedstep-smi. Also, is /proc/cpuinfo correct _before_ you load speedstep-smi?