Bug 10511

Created attachment 15867 [details]
acpidump output

Created attachment 15868 [details]
dmesg | grep ACPI (from kernel 2.6.25)

Created attachment 15869 [details]
DSDT

Created attachment 15870 [details]
kernel .config

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.

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

Created attachment 15899 [details]
Full dmesg output

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.

Created attachment 15921 [details]
full dmesg output

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

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.

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.

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).

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.

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?

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.

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.

Created attachment 16028 [details]
dmesg output with latest patch

Created attachment 16079 [details]
the updated patch

The attached is the updated patch based on the patch in comment #16.

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.

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!

*** This bug has been marked as a duplicate of bug 10695 ***

It is not a dup.

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.
    

yep, more or less the same. sorry all

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).