Bug 10511

Summary: AC Adapter Events on Sony VAIO VGN-FZ31M
Product: ACPI Reporter: fatgerman
Component: BIOSAssignee: ykzhao (yakui.zhao)
Status: CLOSED CODE_FIX    
Severity: normal CC: acpi-bugzilla, mtabolsky
Priority: P1    
Hardware: All   
OS: Linux   
Kernel Version: 2.6.25 Subsystem:
Regression: --- Bisected commit-id:
Attachments: acpidump output
dmesg | grep ACPI (from kernel 2.6.25)
DSDT
kernel .config
try the debug patch
Full dmesg output
full dmesg output
Custom DSDT file
try the debug patch
dmesg output with latest patch
the updated patch

Description fatgerman 2008-04-23 13:06:21 UTC
Latest working kernel version: None
Earliest failing kernel version: tested 2.6.24.4 Mandriva Kernel and 2.6.25 from kernel.org
Distribution: Mandriva
Hardware Environment: Sony VAIO VGN-FZ31M 
Software Environment: Linux/KDE
Problem Description: No AC adapter events are reported by the kernel, meaning I can't change to 'powersvae' mode automatically when I unplug the AC adapter. Other ACPI events (lid close, power button, battery level) are working correctly.
I have sony-latop and sonypi in use (I need the former to get ACPI to work, and the latter for things like display brightness, bluetooth, etc). I was asked to report this here by the linux-ACPI mailing list.

Steps to reproduce:
Unplug the power adapter. Without acpid running I can cat /proc/acpi/event and I get the following:

<unplug power>
battery BAT0 00000080 00000001
processor CPU0 00000081 00000000
processor CPU1 00000081 00000000

<plug power>
battery BAT0 00000080 00000001
processor CPU0 00000081 00000000
processor CPU1 00000081 00000000

So no AC adapter events. I will attach output from dmesg | grep ACPI, acpidump, and the decomplied DSDT.
Comment 1 fatgerman 2008-04-23 13:07:48 UTC
Created attachment 15867 [details]
acpidump output
Comment 2 fatgerman 2008-04-23 13:09:48 UTC
Created attachment 15868 [details]
dmesg | grep ACPI (from kernel 2.6.25)
Comment 3 fatgerman 2008-04-23 13:10:35 UTC
Created attachment 15869 [details]
DSDT
Comment 4 fatgerman 2008-04-23 13:11:32 UTC
Created attachment 15870 [details]
kernel .config
Comment 5 ykzhao 2008-04-23 18:53:04 UTC
Created attachment 15872 [details]
try the debug patch

Will you please boot the system with the option "acpi.debug_layer=0x020004 acpi.debug_level=0x001f" and do the following test? (Note: Please set the CONFIG_ACPI_DEBUG in kernel configuration).
a. kill the acpid and cat /proc/acpi/event
b. plug/unplug the AC adapter.

After the test, please attach the output of dmesg.
Thanks.
Comment 6 fatgerman 2008-04-24 13:25:02 UTC
results of cat /proc/acpi/event
<unplug power>
battery BAT0 00000080 00000001
processor CPU0 00000081 00000000
processor CPU1 00000081 00000000
<plug power>
battery BAT0 00000080 00000001
processor CPU0 00000081 00000000
processor CPU1 00000081 00000000

Some other info I've discovered:
The module 'ac' does not get loaded at boot. I added it to modprobe.preload, but the behaviour didn't change.
If I boot on batteries, kpowersave notices I'm running on battery but does not change to ac power mode when I connect the ac adapter.
Will attach dmesg
Comment 7 fatgerman 2008-04-24 13:26:14 UTC
Created attachment 15899 [details]
Full dmesg output
Comment 8 ykzhao 2008-04-24 19:46:42 UTC
Thanks for the test.
But from the log it seems that there is too little info about the adapter.
Will you please do it again as required in comment #5? (boot the system with the option of "acpi.debug_layer=0x020004 acpi.debug_level=0x001f" and plug/unplug the AC adapter twice).

From the acpidump it seems that the bug may be related with the following error.
 > Method (_Q21, 0, NotSerialized)                {
         >               P8XH (Zero, 0x21)
          >              Store (RPWR, PWRS)
         >               Notify (ADP1, 0x81) //incorrect, it should be 0x80. 
Thanks.
Comment 9 fatgerman 2008-04-26 04:24:16 UTC
Created attachment 15921 [details]
full dmesg output
Comment 10 fatgerman 2008-04-26 04:29:07 UTC
OK I retried, not sure what I did wrong last time so here's what I did this time: I started from a clean kernel-2.6.25 source tree, applied patch, built with CONFIG_ACPI_DEBUG, and rebooted with the debug options on the kernel command line.

Full dmesg is in attachment id 15921, I copied this after doing the ac adapter test.

I unplugged/plugged the AC adapter twice, waiting about 2 seconds each time:

<unplug>
battery BAT0 00000080 00000001
processor CPU0 00000081 00000000
processor CPU1 00000081 00000000
battery BAT0 00000080 00000001
battery BAT0 00000080 00000001
<plug>
battery BAT0 00000080 00000001
processor CPU0 00000081 00000000
processor CPU1 00000081 00000000
battery BAT0 00000080 00000001
<unplug>
processor CPU0 00000081 00000000
processor CPU1 00000081 00000000
<plug>
battery BAT0 00000080 00000001
processor CPU0 00000081 00000000
processor CPU1 00000081 00000000
Comment 11 fatgerman 2008-04-27 06:15:28 UTC
Based on what you said about the problem perhaps being in the acpidump output, I've created a custom DSDT for this machine with that problem fixed. I am now getting AC adapter events and Kpowersave is now switching between AC and battery modes so it al appears to be working. However I'm not very confident about my DSDT, as I had to make a large number of changes to make it compile (it was very buggy to begin with) and I'm not sure this is the best fix for the problem.

I'll attach my new DSDT so you can take a look at it.
Comment 12 fatgerman 2008-04-27 06:19:05 UTC
Created attachment 15935 [details]
Custom DSDT file

This has the 0x81 changed to 0x80 in the two places where it is associated with ADP1. I also had to make several changes, not the least of which was to replace  'External (^CPU0._PPC)' with 'External(CPU0._PPC)' to prevent the compiler reporting errors that it was out of scope. This should be considered a hack because I basically don't understand aml and was just trying to get it to work.
Comment 13 Zhang Rui 2008-04-28 00:08:42 UTC
Hmm, I've checked the ACPI spec.
Notification 0x81 is reserved for power source device.
So this is apparently a BIOS bug.
But I still wondering if we should fix it in BIOS (override the DSDT or upgrade the BIOS) or try to fix it in kernel (handle notify 0x81 in ACPI AC driver).
Comment 14 fatgerman 2008-04-28 11:09:11 UTC
Yes, it's a tricky one that. I guess you could say that an AC adapter is a 'power source device' I suppose. But whether Sony meant to use 0x81 or if it is just a bug we will never know... It's definitely true that this BIOS is buggy - when I decompiled the DSDT I ran it straight back through the compiler and there were over 200 errors reported. Once I'd sorted them all out I now have the AC adapter working, and the fan speed control seems a lot smoother too (I'm no expert but they seemed to be re-using a reserved variable as a temporary variable in that part of it, something the Intel aml compiler forbids). I am going to stick with my DSDT because it seems to be working nicely.
Comment 15 Len Brown 2008-04-28 19:46:16 UTC
if you build with CONFIG_ACPI_DEBUG=y
does this message fire on your console on AC/DC events?

drivers/acpi/ac.c: acpi_ac_notify():

        default:
                ACPI_DEBUG_PRINT((ACPI_DB_INFO,
                                  "Unsupported event [0x%x]\n", event));

seems like we should just send the even 0x81 up to user-space
and hope that it can figure out what to do with it - yakui?
Comment 16 ykzhao 2008-05-03 22:26:39 UTC
Created attachment 16018 [details]
try the debug patch

Will you please try the debug patch and boot the system with the option of "acpi.debug_layer=0x020004 acpi.debug_level=0x1f"?
Please confirm whether the AC adapter event can be received in user space and attach the output of dmesg.
(Note: Please set "CONFIG_ACPI_DEBUG" in kernel configuration).
Thanks.
Comment 17 fatgerman 2008-05-05 06:18:18 UTC
With this patch, AC adapter events are now being picked up in user space (KPowersave switches between Powersave and Performance modes) correctly.

BTW I have found that my adapted DSDT has broken some other features (battery level reporting mainly) so I wouldn't reccomend anybody to use it.

Will attach dmesg. Thanks.
Comment 18 fatgerman 2008-05-05 06:18:58 UTC
Created attachment 16028 [details]
dmesg output with latest patch
Comment 19 ykzhao 2008-05-09 02:21:57 UTC
Created attachment 16079 [details]
the updated patch

The attached is the updated patch based on the patch in comment #16.
Comment 20 fatgerman 2008-05-27 14:50:51 UTC
Sorry for the delay in replying. I have tried the updated patch (id 16079) on kernel 2.6.25.4 and I can confirm that it works - the AC adapter event is reported to userspace and AC adapter insertion/removal is correctly reported by userspace tools.
Comment 21 Michael Tabolsky 2008-07-04 08:28:42 UTC
Same problem was detected here on two vaio models:
- VGN-FZ38M
- VGN-NR21M
Adding 0x81 fixes it.
The thing that made me go crazy looking for clues was that the AC status was updated in the /proc/acpi but not in /sys/class/power_supply. Only after looking into the code I've got the right keywords for googling.
Thanks for the fix!
Comment 22 Len Brown 2008-10-16 22:30:32 UTC

*** This bug has been marked as a duplicate of bug 10695 ***
Comment 23 Michael Tabolsky 2008-10-16 23:22:19 UTC
It is not a dup.
Comment 24 ykzhao 2008-10-27 02:31:19 UTC
Hi, Michael
    Why it is a duplicate of bug 10695? There exists the same issue on the two bugs.(The 0x81 ACPI event is sent instead of 0x80 by BIOS when AC adapter is plugged/unplugged).
    Thanks.
    
Comment 25 Michael Tabolsky 2008-10-27 07:19:10 UTC
yep, more or less the same. sorry all
Comment 26 ykzhao 2008-10-27 19:14:12 UTC
The following commit is already shipped in 2.6.26-rc7.
   >commit f163ff5176a8e9c827d8ebe044710d67d40799c3
Author: Len Brown <len.brown@intel.com>
Date:   Sat Jun 14 01:26:37 2008 -0400

    ACPI: no AC status notification

    So the bug will be marked as resovled.(CODE_FIX).