Bug 12830

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.
    

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.

Just to be sure: should I do all these test without acpi_osi=!Window2006, so that I reproduce the problem?

The above test had better be done without the boot option of acpi_osi="!Windows 2006".
   Thanks.

Created attachment 20462 [details]
acpidump output

Created attachment 20463 [details]
dmidecode output

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.

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.

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.

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>

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.

please set CONFIG_ACPI_PROCESSOR=y, and boot with processor.ignore_ppc=1,
does the problem still exists in this case?

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.
            

Created attachment 20582 [details]
requested output of acpidump

Created attachment 20583 [details]
requested output of acpidump

martin, can you please do the test in comment #12?

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.

    

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.

(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?

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.