Bug 1422

Summary: Dell Latitude C600. Freezes on startup (speedstep_init)
Product: Power Management Reporter: Priit Laes (plaes)
Component: OtherAssignee: Dominik Brodowski (linux)
Status: CLOSED CODE_FIX    
Severity: normal CC: davej, linux
Priority: P2    
Hardware: i386   
OS: Linux   
Kernel Version: 2.6.0-test[6-9] Subsystem:
Regression: --- Bisected commit-id:
Attachments: lspci -v output
How i tested it...
test-patch
2nd test patch specifically for bug reporter
bugfix

Description Priit Laes 2003-10-26 01:01:50 UTC
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)
Comment 1 Andrew Morton 2003-10-26 01:08:04 UTC
That's pretty weird.  Dave, it hung in the
middle of doing nothing...
Comment 2 Priit Laes 2003-10-26 01:49:41 UTC
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).
Comment 3 Priit Laes 2003-10-26 01:50:22 UTC
Created attachment 1190 [details]
lspci -v output

Here is the lspci -v output.
Comment 4 Priit Laes 2003-10-26 01:59:03 UTC
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..
Comment 5 Priit Laes 2003-10-30 00:08:29 UTC
I also tried to this as a module. Dang... it freezed my system.
Comment 6 Dominik Brodowski 2003-11-04 08:20:14 UTC
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?]
Comment 7 Priit Laes 2003-11-05 09:18:15 UTC
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


Comment 8 Dominik Brodowski 2003-11-05 10:32:10 UTC
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
Comment 9 Priit Laes 2003-11-05 11:03:46 UTC
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.
Comment 10 Dominik Brodowski 2003-11-05 22:56:00 UTC
> 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.
Comment 11 Dominik Brodowski 2003-11-11 13:53:10 UTC
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
Comment 12 Priit Laes 2003-11-12 05:54:19 UTC
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
Comment 13 Dominik Brodowski 2003-11-12 09:55:41 UTC
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...
Comment 14 Priit Laes 2003-11-12 12:28:03 UTC
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?
Comment 15 Dominik Brodowski 2003-11-17 00:53:11 UTC
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?