Bug 21322
Summary: | no detection whether power cord is unplugged or not | ||
---|---|---|---|
Product: | ACPI | Reporter: | Disabled Account (disabled_20190211) |
Component: | BIOS | Assignee: | acpi_bios |
Status: | CLOSED DOCUMENTED | ||
Severity: | normal | CC: | acpi-bugzilla, lenb, rui.zhang |
Priority: | P1 | ||
Hardware: | All | ||
OS: | Linux | ||
Kernel Version: | 2.6.35 | Subsystem: | |
Regression: | No | Bisected commit-id: | |
Attachments: |
acpidump
lspci -vxxx dmesg with ACPI_DEBUG enabled dmesg output when screen is NOT dimming dmesg output when screen IS dimming custom _Q20 method refreshed custom _Q20 method dmesg, screen not dimming, _Q20 method dmesg, screen dimming, _Q20 method iasl -tc dsdt.dsl > errors.dsl dmesg, plug & unplug AC, screen not dimming dmesg, plug & unplug AC, screen dimming custom _Q20 method |
Description
Disabled Account
2010-10-27 22:20:04 UTC
Created attachment 35312 [details]
lspci -vxxx
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. Building a kernel was new for me, so i hope all went well. dmesg.log attached. Kernel version is 2.6.35.7 (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 Created attachment 35462 [details]
dmesg with ACPI_DEBUG enabled
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).
Created attachment 35482 [details]
dmesg output when screen IS dimming
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. Created attachment 35672 [details]
custom _Q20 method
please
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.
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. oops, my fault. :( 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. Created attachment 35822 [details]
refreshed custom _Q20 method
could you please try this one instead?
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).
Created attachment 35952 [details]
dmesg, screen dimming, _Q20 method
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: http://forum.sabayon.org/viewtopic.php?f=56&t=15873 The workaround described here is probably going to work for me too, but I hate workarounds. 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 http://forum.sabayon.org/viewtopic.php?f=56&t=15873 Chris, 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? 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.
Created attachment 36012 [details]
dmesg, plug & unplug AC, screen dimming
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 Created attachment 36062 [details]
custom _Q20 method
please try this one instead and see if the problem still exists.
you can just run "cat _Q20.aml > /sys/kernel/debug/acpi/custom_method" without rebooting your kernel. 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. :) Regards, Chris 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) } 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. |