Bug 21322 - no detection whether power cord is unplugged or not
no detection whether power cord is unplugged or not
Product: ACPI
Classification: Unclassified
Component: BIOS
All Linux
: P1 normal
Assigned To: acpi_bios
Depends on:
  Show dependency treegraph
Reported: 2010-10-27 22:20 UTC by Chris
Modified: 2011-07-30 04:51 UTC (History)
3 users (show)

See Also:
Kernel Version: 2.6.35
Tree: Mainline
Regression: No

acpidump (179.83 KB, application/octet-stream)
2010-10-27 22:20 UTC, Chris
lspci -vxxx (31.74 KB, application/octet-stream)
2010-10-27 22:21 UTC, Chris
dmesg with ACPI_DEBUG enabled (24.89 KB, text/x-log)
2010-10-29 15:00 UTC, Chris
dmesg output when screen is NOT dimming (6.28 KB, text/x-log)
2010-10-29 16:01 UTC, Chris
dmesg output when screen IS dimming (10.29 KB, text/x-log)
2010-10-29 16:02 UTC, Chris
custom _Q20 method (193 bytes, application/octet-stream)
2010-11-01 01:51 UTC, Zhang Rui
refreshed custom _Q20 method (193 bytes, application/octet-stream)
2010-11-02 02:16 UTC, Zhang Rui
dmesg, screen not dimming, _Q20 method (9.75 KB, text/x-log)
2010-11-02 20:52 UTC, Chris
dmesg, screen dimming, _Q20 method (8.12 KB, text/x-log)
2010-11-02 20:53 UTC, Chris
iasl -tc dsdt.dsl > errors.dsl (1.40 KB, text/x-dsl)
2010-11-02 20:57 UTC, Chris
dmesg, plug & unplug AC, screen not dimming (19.82 KB, text/x-log)
2010-11-03 12:28 UTC, Chris
dmesg, plug & unplug AC, screen dimming (27.96 KB, text/x-log)
2010-11-03 12:29 UTC, Chris
custom _Q20 method (212 bytes, application/octet-stream)
2010-11-04 00:59 UTC, Zhang Rui

Description Chris 2010-10-27 22:20:04 UTC
Created attachment 35302 [details]

Using Arch linux with KDE 4.5.2, most of the time unplugging the power cord to my laptop is undetected: HP Pavilion dv9790ed. Only after cat /proc/acpi/ac_adapter/ACAD/state the screen is dimming. This state, by the way, is always correct.

A lot of information regarding this bug can be found here:  
https://bugs.kde.org/show_bug.cgi?id=233854,  with comments #8 and #11 coming from me. To summarize: this happens on both Ubuntu (without Hal) with gnome, and Arch (with Hal) with KDE, on the same hardware. Which leads me to conclude it is a kernel-related issue. 

Linux laptop 2.6.35-ARCH #1 SMP PREEMPT Wed Sep 29 08:45:18 CEST 2010 x86_64 Intel(R) Core(TM)2 Duo CPU T7500 @ 2.20GHz GenuineIntel GNU/Linux

attached: acpidump
Comment 1 Chris 2010-10-27 22:21:03 UTC
Created attachment 35312 [details]
lspci -vxxx
Comment 2 Zhang Rui 2010-10-29 07:03:47 UTC
please uncomment the "/* #define DEBUG */" line in drivers/acpi/ec.c. set CONFIG_ACPI_DEBUG, rebuild your kernel and then
1. reboot with boot option "ignore_loglvel acpi.debug_layer=0x04 acpi.debug_levle=0x04"
2. dmesg -c
3. plug/unplug the power cord
4. dmesg > dmesg.log
attach the dmesg output.
Comment 3 Chris 2010-10-29 14:59:10 UTC
Building a kernel was new for me, so i hope all went well. 
dmesg.log attached. Kernel version is (which is the one currently used by Arch core, and also the one i'm using). 
I did it in the exact order you described:

(1. Unplug power cord)
2. dmesg -c
3. Plug power cord
4. Unplug power cord
5. dmesg > dmesg.log
Comment 4 Chris 2010-10-29 15:00:07 UTC
Created attachment 35462 [details]
dmesg with ACPI_DEBUG enabled
Comment 5 Chris 2010-10-29 16:01:23 UTC
Created attachment 35472 [details]
dmesg output when screen is NOT dimming

Here's something interesting. As described, removing power cord seems to have random behavior: sometimes screen dims, sometimes it doesn't.  So here's what I did to generate dmesg output, to compare the two states:

1. Boot with power cord plugged in.
2. dmesg -c, and inmediately after, unplug power cord. Screen not dimming. Output: dmesg_screen_not_dimming.log

3. plug in power cord. 
4. dmesg -c, and inmediately after, unplug power cord. Screen dimming. Output: dmesg_screen_dimming.log

(as expected, I had to try 3 and 4 quite a few times to generate the 'screen dimming' result).
Comment 6 Chris 2010-10-29 16:02:09 UTC
Created attachment 35482 [details]
dmesg output when screen IS dimming
Comment 7 Zhang Rui 2010-11-01 01:33:40 UTC
well, the AML runs different code path in these two case, one with AC notification and one without.
I'll send you a custom EC control method later to get more debug information and see why the AML code runs different code path.
Comment 8 Zhang Rui 2010-11-01 01:51:25 UTC
Created attachment 35672 [details]
custom _Q20 method

1. mount the debugfs file system
2. apply the custom _Q20 method by running "cat _Q20.aml > /sys/kernel/debug/acpi/custom_method"
3. enable the debug options by "echo 0x02 > /sys/module/acpi/parameters/debug_level" and "echo 0x80 > /sys/module/acpi/parameters/debug_layer".
4. dmesg -c
5. unplug the AC
6. get the dmesg output.

please do the test twice, one when backlight is dimming and one when backlight is not dimming.
Comment 9 Chris 2010-11-01 08:09:27 UTC
I think a lot of debug-info was missing anyway, because I copied/pasted your "reboot with boot option "ignore_loglvel acpi.debug_layer=0x04
acpi.debug_levle=0x04" line.. which had a few typing errors that i hadn't noticed. :-)

I'll get back to you ASAP.
Comment 10 Zhang Rui 2010-11-01 08:16:25 UTC
oops, my fault. :(
Comment 11 Chris 2010-11-01 09:43:53 UTC
getting an 'invalid argument' error when running the "cat _Q20.aml >
/sys/kernel/debug/acpi/custom_method"... ?

By the way, this is now my kernel line:
linux /boot/vmlinuz26-ARCH root=/dev/sdb1 acpi.debug_layer=0x04 acpi.debug_level=0x04

Looks like i'm getting more dmesg output now. I left out the "ignore_loglevel" because that sends the output to console, which interferes with typing commands.
Comment 12 Zhang Rui 2010-11-02 02:16:53 UTC
Created attachment 35822 [details]
refreshed custom _Q20 method

could you please try this one instead?
Comment 13 Chris 2010-11-02 20:52:28 UTC
Created attachment 35942 [details]
dmesg, screen not dimming, _Q20 method

Attached.  I can see very little difference, but I'll leave the comparing up to you. :-)

I also attached my dsdt table errors (on Arch) after running these commands:
cat /proc/acpi/dsdt > dsdt.dat
iasl -d dsdt.dat
iasl -tc dsdt.dsl > errors.dsl

Just 2 errors, which is really good I guess.. probably not the cause of this problem. (In ubuntu on the same hardware, I get hundreds of errors).
Comment 14 Chris 2010-11-02 20:53:11 UTC
Created attachment 35952 [details]
dmesg, screen dimming, _Q20 method
Comment 15 Chris 2010-11-02 20:57:28 UTC
Created attachment 35962 [details]
iasl -tc dsdt.dsl > errors.dsl

I got this info from this bug report, which seemed to be a similar problem:

The workaround described here is probably going to work for me too, but I hate workarounds.
Comment 16 Zhang Rui 2010-11-03 02:55:41 UTC
the dmesg in comment #13 and #14 are got in the same boot, right?

in comment #13:
[ACPI Debug]  String [0x11] "Local0 and Local1"
[ACPI Debug]  Integer 0x00000001
[ACPI Debug]  Integer 0x00000000
[ACPI Debug]  String [0x04] "BATO"
[ACPI Debug]  Integer 0x00000000

in comment #14:
[ACPI Debug]  String [0x11] "Local0 and Local1"
[ACPI Debug]  Integer 0x00000001
[ACPI Debug]  Integer 0x00000000
[ACPI Debug]  String [0x04] "BATO"
[ACPI Debug]  Integer 0x00000002

Only when BAT0 equals 0x02, there is an AC notification when power cord is plugged, thus user space detects this event.

I suspect this is because EC report bogus AC status when AC is plugged. which means this is actually an EC bug, and it's not a duplicate of 

could you please redo the test, but change step 5 to "plug and unplug the AC", i.e. run "dmesg -c" before the AC is plugged this time?
Comment 17 Chris 2010-11-03 12:28:45 UTC
Created attachment 36002 [details]
dmesg, plug & unplug AC, screen not dimming

I can confirm that this was all done during the same boot.

As to your latest instructions: here's what i did:

1. Unplug AC:	no dimming
2. dmesg -c
3. Plug AC
4. Unplug AC:	no dimming
5. dmesg > dmesg_nodim_plug_unplug.log

This sequence generates three [BAT0] events (I would expect two, but oh well).
The sequence of Integers is:

[BAT0] event 1:  1, 1, 40
[BAT0] event 2:  1, 1, 2
[BAT0] event 3:  1, 0, 40

Now on to where the screen is actually dimming as it should:

1. Unplug AC:	dimming
2. dmesg -c
3. Plug AC:	brightens
4. Unplug AC:	dimming

The sequence of Integers in this case is:

[BAT0] event 1:	1, 1, 2
[BAT0] event 2:	1, 1, 40
[BAT0] event 3: 1, 0, 2

I never noticed anything going wrong with plugging in the AC: it always causes the screen to un-dim (become brighter) as it should. So the bug is only happening when AC is unplugged.

dmesg output attached.
Comment 18 Chris 2010-11-03 12:29:55 UTC
Created attachment 36012 [details]
dmesg, plug & unplug AC, screen dimming
Comment 19 Chris 2010-11-03 16:30:44 UTC
btw, I noticed this error in dmesg.. which may or may not have something to do with this bug. I should have noticed this earlier.. :-S

ACPI: EC: Look up EC in DSDT
ACPI Error (psargs-0359): [CDW1] Namespace lookup failure, AE_NOT_FOUND
ACPI Error (psparse-0537): Method parse/execution failed [\_SB_._OSC] (Node ffff88013fc11ba0), AE_NOT_FOUND
ACPI: BIOS _OSI(Linux) query ignored
Comment 20 Zhang Rui 2010-11-04 00:59:28 UTC
Created attachment 36062 [details]
custom _Q20 method

please try this one instead and see if the problem still exists.
Comment 21 Zhang Rui 2010-11-04 01:15:05 UTC
you can just run "cat _Q20.aml > /sys/kernel/debug/acpi/custom_method" without rebooting your kernel.
Comment 22 Chris 2010-11-04 12:04:46 UTC
Zhang Rui,

The latest _Q20 method seems to solve the problem! I tried about 10 times at different moments, and the screen always dimmed. Good stuff.. well done! :-)

Is this potentially a bug which could hit more people than just me? (like the ones in https://bugs.kde.org/show_bug.cgi?id=233854)

What's going to happen next? I should note that i'm not particularly hit by this bug.. I usually have the AC-adapter plugged in. But if any more help is needed, I'm here. 

This has been a great learning experience. :-) Although.. can i order a new AC-adapter from the Linux foundation? the plug is getting worn out. ;-) Just joking. :)

Comment 23 Zhang Rui 2010-12-16 06:26:05 UTC
This is the ASL code of the custom GBAS control method.

                    Method (\_SB.PCI0.LPCB.EC0.GBAS, 0, NotSerialized)
                        Store (Zero, BATF)
                        Store (MBTS, Local0)
                        Store (SW2S, Local1)
			Store ("Local0 and Local1", Debug)
			Store (Local0, Debug)
			Store (Local1, Debug)
                        ShiftLeft (Local0, 0x06, Local0)
                        ShiftLeft (Local1, One, Local1)
			Store ("BATO", Debug)
			Store (BATO, Debug)
                        If (LNotEqual (And (BATO, 0x40), Local0))
                            Or (BATF, 0x40, BATF)

                        If (LNotEqual (And (BATO, 0x02), Local1))
                            Or (BATF, 0x02, BATF)

			If (Lequal (SW2S, Zero))
                            Or (BATF, 0x02, BATF)

                        Store (BATF, BATO)
Comment 24 Zhang Rui 2010-12-16 06:29:04 UTC
I'd say this smells like a BIOS problem to me.
And updating the BIOS may be the only way to get the problem resolved.

Please re-open this bug if the problem doesn't exist in Windows.

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