Bug 12830 - Dell Vostro 1400 needs acpi_osi=!Window2006 option for normal cpufreq operation
Dell Vostro 1400 needs acpi_osi=!Window2006 option for normal cpufreq operation
Status: CLOSED UNREPRODUCIBLE
Product: ACPI
Classification: Unclassified
Component: BIOS
All Linux
: P1 low
Assigned To: Zhang Rui
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2009-03-07 04:50 UTC by Martin
Modified: 2009-04-01 00:44 UTC (History)
2 users (show)

See Also:
Kernel Version: 2.6.29-rc7
Tree: Mainline
Regression: No


Attachments
acpidump output (109.98 KB, text/plain)
2009-03-09 01:29 UTC, Martin
Details
dmidecode output (11.25 KB, text/plain)
2009-03-09 01:31 UTC, Martin
Details
AC in/out/in /sys filesystem (2.64 KB, text/plain)
2009-03-09 05:07 UTC, Martin
Details
dmesg output of stuck scaling_max_freq (50.48 KB, text/plain)
2009-03-12 01:28 UTC, Martin
Details
dmesg of stuck scaling_max_freq in single user mode (43.22 KB, text/plain)
2009-03-12 01:52 UTC, Martin
Details
requested output of acpidump (646 bytes, application/octet-stream)
2009-03-18 02:21 UTC, Martin
Details
requested output of acpidump (196 bytes, application/octet-stream)
2009-03-18 02:24 UTC, Martin
Details

Description Martin 2009-03-07 04:50:08 UTC
Hardware Environment: Dell Vostro 1400
Problem Description: scaling_max_freq stays at 800000 after AC has been disconnected.

Steps to reproduce:
Boot laptop with AC adapter (cpufreq governor: ondemand) scaling_max_freq = 2001000, 
Unplug AC adapter: scaling_max_freq = 800000
Replug AC adapter: scaling_max_freq stays at 800000 and can not be raised anymore.

This is reproducable in single user mode, so no daemon is interfering with the governor or frequencies.
Giving acpi_osi=!Window2006 as boot param solves the problem so this seems related to bug 9919.

I was wondering if this merits a blacklisting of my hardware, so I'm offering ACPI debug info if needed...
Comment 1 ykzhao 2009-03-08 19:48:20 UTC
Hi, Martin
    Will  you please attach the output of acpidump?
    Will you please confirm whether cpufreq is normal if adding the boot option of acpi_osi="!Windows 2006" ?
    Will you please add the boot option of "cpufreq.debug=7" and boot the box with AC adapter?After the box is booted, please unplug the AC adapter and then plug it again. After this, please attach the output of dmesg.(Of course the CONFIG_CPU_FREQ_DEBUG should be enabled in kernel configuration).
    Thanks.
    
Comment 2 Zhang Rui 2009-03-08 19:59:14 UTC
please attach the acpidump output.

please attach the output of "grep . /sys/devices/system/cpu/cpu0/cpufreq/*" after:
1. system boot with AC adapter
2. unplugging AC
3. replugging AC.

please attach the dmidecode as well.
Comment 3 Martin 2009-03-08 23:53:01 UTC
Just to be sure: should I do all these test without acpi_osi=!Window2006, so that I reproduce the problem?
Comment 4 ykzhao 2009-03-09 00:27:15 UTC
The above test had better be done without the boot option of acpi_osi="!Windows 2006".
   Thanks.
Comment 5 Martin 2009-03-09 01:29:41 UTC
Created attachment 20462 [details]
acpidump output
Comment 6 Martin 2009-03-09 01:31:24 UTC
Created attachment 20463 [details]
dmidecode output
Comment 7 Martin 2009-03-09 05:07:44 UTC
Created attachment 20465 [details]
AC in/out/in /sys filesystem

As you can see from the output, I am unable to reproduce the bug since I recompiled the kernel with cpufreq debugging on.
I'll recompile the kernel without cpufreq debugging and see if the bug reappears.
Comment 8 Martin 2009-03-09 08:22:42 UTC
After some testing/debugging and rebooting I am still unable to reproduce at the moment, so I assume flaky hardware issues instead of ACPI/bios problems for the time being.
One thing that has remarkably changed since the last kernel build is that after unplugging AC, scaling_max_freq goes to 800000 and now returns to 2001000 autonomously within 1 minute  (still unplugged), even in single user mode. I have never seen this behavior before, 
Will close the bug and reopen when I can reliably reproduce again, including the debug info.
Comment 9 Martin 2009-03-12 01:28:34 UTC
Created attachment 20499 [details]
dmesg output of stuck scaling_max_freq

I finally managed to reproduce the problem. It seems linked to the charge of the battery (I drained it completely last night).
Attached is dmesg output of a session booted without AC, followed by inserting AC adapter after bootup. Powermanager present and running.
Comment 10 Martin 2009-03-12 01:29:34 UTC
Output of the stuck sys fs:
/sys/devices/system/cpu/cpu0/cpufreq/affected_cpus:0
/sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_cur_freq:800000
/sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_max_freq:2001000
/sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_min_freq:800000
/sys/devices/system/cpu/cpu0/cpufreq/related_cpus:0 1
/sys/devices/system/cpu/cpu0/cpufreq/scaling_available_frequencies:2001000 2000000 1600000 1200000 800000
/sys/devices/system/cpu/cpu0/cpufreq/scaling_available_governors:conservative userspace powersave ondemand performance
/sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq:800000
/sys/devices/system/cpu/cpu0/cpufreq/scaling_driver:acpi-cpufreq
/sys/devices/system/cpu/cpu0/cpufreq/scaling_governor:ondemand
/sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq:800000
/sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq:800000
/sys/devices/system/cpu/cpu0/cpufreq/scaling_setspeed:<unsupported>
Comment 11 Martin 2009-03-12 01:52:56 UTC
Created attachment 20501 [details]
dmesg of stuck scaling_max_freq in single user mode

This is a single user mode session dmesg output.

Another issue that might be related is the fact that my laptop sometimes complains about not being able to determine the type and wattage of the power adapter while AC is plugged in at BIOS boot-time (warning). Could it be that the BIOS is just over-protective in such situations and that cpufreq is correctly doing it's job?
The strange thing now is that after boot, max_freq is ok, but gets stuck after plugging AC adapter in (after a minute or so). If I boot with power adapter, and leave it seated, everything is ok.
Comment 12 Zhang Rui 2009-03-15 20:00:53 UTC
please set CONFIG_ACPI_PROCESSOR=y, and boot with processor.ignore_ppc=1,
does the problem still exists in this case?
Comment 13 ykzhao 2009-03-18 02:11:47 UTC
Hi, Martin
    Will you please also attach the following output?
    a. acpidump --addr 0xDF66E4EE  --length 0x00000286 -o cpu0ist
    b. acpidump --addr 0xdf66e774 --length 0xc4 -o cpu1ist
    Thanks.
            
Comment 14 Martin 2009-03-18 02:21:13 UTC
Created attachment 20582 [details]
requested output of acpidump
Comment 15 Martin 2009-03-18 02:24:19 UTC
Created attachment 20583 [details]
requested output of acpidump
Comment 16 Zhang Rui 2009-03-18 18:18:48 UTC
martin, can you please do the test in comment #12?
Comment 17 ykzhao 2009-03-18 19:14:16 UTC
Hi, Martin
    It seems that this issue is related with BIOS. When the power is switched between AC and DC, the 0x80 notification event will be sent to the processor CPU. In such case the driver will re-evaluate the _PPC object and apply the new processor CPU frequency limit.
    From the acpidump it seems that the _PPC object is defined as the following:
    >Method (_PPC, 0, NotSerialized)
        {
            Store (SMI (0xAD, 0x00), Local0)
            Return (Local0)
        }
     
    At the same time in course of ACPI initialization the MIS3 object will be used in the _INI object and the SMI is triggered.
    > Method (SOST, 0, NotSerialized)
    {
        SX10 ()
        SX30 (0x0A)
        OSID ()
        SX30 (MIS3)
        SX11 ()
        SX12 ()
    }
    And the MIS3 is related with the boot option of "acpi_osi". If the acpi_osi="!Windows 2006" is added, the MIS3 will be 0x10. Otherwise it will be 0x20. Maybe the behaviour will be different when the different MIS3 is passed to BIOS.
    If so, this issue will be different with that in bug 9919. 
    
    And What Rui said is right. The boot option of "processor.ignore_ppc" can workround this issue.

    
Comment 18 Martin 2009-03-19 01:16:31 UTC
In reply to: martin, can you please do the test in comment #12?

I would, if the problem was better reproducible. I'm still in doubt whether this is a BIOS, hardware or kernel bug. I reported the aforementioned (BIOS) adapter problem with Dell and promptly received a new (90W) adapter the other day.
As soon as I see the problem reappear I will do the test and report back. My apologies for any confusion created by this report.
Comment 19 Zhang Rui 2009-03-26 09:12:50 UTC
(In reply to comment #18)
> In reply to: martin, can you please do the test in comment #12?
> As soon as I see the problem reappear I will do the test and report back. My
> apologies for any confusion created by this report.

Hi, martin, are you able to reproduce the problem?
Comment 20 Martin 2009-03-31 12:40:07 UTC
I can't, so for practical reasons I will close the bug for now.
I assume it was due to a flaky power adapter and an overprotective (but correct) BIOS decision. If anything changes I will reopen this bug.

Note You need to log in before you can comment on or make changes to this bug.