Bug 1422

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?