Latest working kernel version: Unknown Earliest failing kernel version: Unknown Distribution: Mandriva Hardware Environment: Toshiba Satellite L355 Software Environment: Mandriva Cooker Problem Description: /proc/acpi/ac_adapter/.../state always show the correct state, but acpi_listen and lshal --monitor dont see any un/plug events. Steps to reproduce: Un/plug ac adapter while running acpi_listen
Created attachment 20132 [details] output of lspci -vxxx
Created attachment 20133 [details] output of grep . /sys/firmware/acpi/interrupts/* before unplug No point adding the one for after as it is identical
Created attachment 20134 [details] Output from dmidecode
Created attachment 20135 [details] Outout from acpidump
hmmm, you mean /sys/firmware/acpi/interrupts/* don't change after un/plugging the AC adapter? so "cat /proc/interrupts | grep acpi" also doesn't change, right? if there is no ACPI interrupt when un/plugging the ACPI adapter, I'm afraid there is nothing we can do here. maybe this is related to the BIOS settings?
HI, Adam The AC notification event is sent in the acpi _Q13/_Q19 object by ACPI EC device. Maybe this is related with the EC. Will you please attach the output of dmesg? Thanks.
From the info in http://marc.info/?l=linux-acpi&m=123394625804038&w=2 it seems that there exists the following message: >ACPI: EC: GPE storm detected, transactions will use polling mode >ACPI: EC: missing confirmations, switch off interrupt mode. And the ac notification event is sent in the ACPI _Q13/_Q19 object of ACPI EC device. Maybe it is related with EC. Hi, Rui How about assign this bug to EC category? thanks.
Inbetween these there was an unplug, a plug, and again. [piggz@localhost ~]$ cat /proc/interrupts | grep acpi 9: 99 100 IO-APIC-fasteoi acpi [piggz@localhost ~]$ cat /proc/interrupts | grep acpi 9: 99 100 IO-APIC-fasteoi acpi [piggz@localhost ~]$ cat /proc/interrupts | grep acpi 9: 99 100 IO-APIC-fasteoi acpi [piggz@localhost ~]$ cat /proc/interrupts | grep acpi 9: 99 100 IO-APIC-fasteoi acpi
Created attachment 20171 [details] dmesg
hi, adam, please attach the output of "grep . /sys/firmware/acpi/interrupts/*" when you do the test in comment #8. I need to make sure that ec GPE is disabled at that time.
Created attachment 20328 [details] contents of /sys/firmware/acpi/interrupts/* with power plugged in
Created attachment 20329 [details] contents of /sys/firmware/acpi/interrupts/* with power not plugged in its the same as the plugged in version
well. there is no ACPI interrupt when un/plugging the AC adapter, so surely we can not get an ACPI event. and it seems that this is what it's designed to be. I guess you can not get this ACPI event on any distribution/kernel version, right? It would be interesting to know how it works in windows, or else I have to close this because it doesn't look like a software "bug".
I'd swear that i actually saw it working once (and only once) i remember seeing the battery monitor in kde change state as i un/plugged the ac. I remember thinking 'oh, a kernel update must have fixed it' but when i rebooted it didnt work. So, i dont know. How does /proc/acpi/ac_adapter.../state get the correct state? Is there anything i could do in windows maybe to help...surely it works there.
I found this thread suggesting a buggy dsdt. http://bbs.archlinux.org/viewtopic.php?id=65004
I dont know if it means anything bad, but i get these error compiling the dsdt /home/piggz/dsdt.dsl 2888: Method (_OSC, 5, NotSerialized) Warning 1075 - ^ Reserved method has too many arguments (_OSC requires 4) /home/piggz/dsdt.dsl 2904: And (CAPB, 0xFFFFFFFC) Warning 1104 - Result is not used, operator has no effect ^ Are these messages anything to worry about? ACPI: EC: Look up EC in DSDT ACPI: BIOS _OSI(Linux) query ignored ACPI: EC: non-query interrupt received, switching to interrupt mode ACPI: EC: GPE storm detected, transactions will use polling mode ACPI: EC: missing confirmations, switch off interrupt mode. ACPI: Interpreter enabled
Created attachment 20354 [details] dsdt file
(In reply to comment #14) > How does /proc/acpi/ac_adapter.../state get > the correct state? > because an ACPI method (_PSR) is always reflecting the actual ac status. when you read it, ACPI ac driver invokes this ACPI method, and get the correct AC status. But un/plugging AC adapter is another story, when you un/plug the AC adapter, OS doesn't receive a notification, which is usually an ACPI interrupt. So the HAL doesn't know this change, and it won't invoke the _PSR to get the new AC status.
have you ever tried any earlier kernel releases? there are a lot of ec changes recently. please try kernel 2.6.25/26/27/28 to see if any of these kernels work for you.
Ive tried .28 and .22, neither worked. I can try some others tonight. What do you think about rebuilding the dsdt? pointless?
it doesn't help the most important is to see if there is any kernel which can export an ACPI interrupt when un/plugging the AC adapter.
Ive managed to install windows xp on a usb external hard disk to see if it works ok there, and it does. Using all standard drivers from windows, nothing from toshiba required. The battery icon in the systray appears/disappears when plugged/unplugged.
Created attachment 20450 [details] acpi devices as windows sees them
is there anything i could do in windows to help debug?
I found a working kernel!! kernel-linus-2.6.27-0.rc8.3.1mdv from mandriva 2009.0. I assume the final 2.6.27 is ok, but i dont have any packages for that. Both lshal --monitor and acpi_listen show the ac adapter being un/plugged.
Ive just observed it working in a 2.6.29rc kernel aswell. Not on startup though. It started to work after being put to sleep/woken up. That must help!! :)
so the ACPI interrupts/GPE0x17 increase when you re-do the test in comment #8/#10, right? (In reply to comment #26) > Ive just observed it working in a 2.6.29rc kernel as well. Not on startup > though. It started to work after being put to sleep/woken up. That must > help!! :) > Great work! Adam. it starts to work after a suspend-to-memory cycle, right? this is only true for 2.6.29-rc kernel, or for all the kernel you've tested, say 2.6.28? In 2.6.29-rc, please attach the output of "lspci -vvxxx -s 00:1f.0" both before and after the s3..
Created attachment 20547 [details] interrupts before sleep with no ac plugged in
Created attachment 20548 [details] interrupts before sleep with ac plugged in
Created attachment 20549 [details] lspci before sleep
Created attachment 20550 [details] interrupts after sleep with ac plugged in
Created attachment 20551 [details] interrupts after sleep with no ac plugged in
Created attachment 20552 [details] lspci after sleep
sorry, you need to use "lspci -vvxxx -s 00:1f.0" instead of "lspci -vvxx -s 00:1f.0"
Created attachment 20563 [details] correct lspci before sleep
Created attachment 20564 [details] correct lscpi after sleep....yes theres a difference now!
what if you run "setpci -s 00:1f.0 0xa0.w=0x0a00" before suspend and un/plug the AC? the problem doesn't exist after a suspend-to-memory cycle, right? is this only true for 2.6.29-rc kernel, or for all the kernel you've tested, say 2.6.28?
Reply-To: piggz1@gmail.com Do you mean to run that command to see if it fixes it without having to do a suspend/resume? After a suspend-to-mem cycle, all battery monitoring works fine, lshal --monitor, and the kde4 battery applet both detect and react to the ac being un/plugged. Im having trouble finding a binary 2.6.28....i'll probably have to build from src to test it. I'll be able to try it later, im away from the machine atm. On Tue, Mar 17, 2009 at 9:21 AM, <bugme-daemon@bugzilla.kernel.org> wrote: > http://bugzilla.kernel.org/show_bug.cgi?id=12641 > > > > > > ------- Comment #37 from rui.zhang@intel.com 2009-03-17 02:21 ------- > what if you run "setpci -s 00:1f.0 0xa0.w=0x0a00" before suspend and > un/plug > the AC? > > the problem doesn't exist after a suspend-to-memory cycle, right? > is this only true for 2.6.29-rc kernel, or for all the kernel you've > tested, > say 2.6.28? > > > -- > Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email > ------- You are receiving this mail because: ------- > You reported the bug, or are watching the reporter. > Do you mean to run that command to see if it fixes it without having to do a suspend/resume?<br><br>After a suspend-to-mem cycle, all battery monitoring works fine, lshal --monitor, and the kde4 battery applet both detect and react to the ac being un/plugged.<br> <br>Im having trouble finding a binary 2.6.28....i'll probably have to build from src to test it.<br><br>I'll be able to try it later, im away from the machine atm.<br><br><div class="gmail_quote">On Tue, Mar 17, 2009 at 9:21 AM, <span dir="ltr"><<a href="mailto:bugme-daemon@bugzilla.kernel.org">bugme-daemon@bugzilla.kernel.org</a>></span> wrote:<br> <blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="im"><a href="http://bugzilla.kernel.org/show_bug.cgi?id=12641" target="_blank">http://bugzilla.kernel.org/show_bug.cgi?id=12641</a><br> <br> <br> <br> <br> <br> </div>------- Comment #37 from <a href="mailto:rui.zhang@intel.com">rui.zhang@intel.com</a>
I tried that command on a fresh boot and nothing seems to have happened, gpe17 remains constant
Hi, This bug has been reported in ubuntu: https://bugs.launchpad.net/ubuntu/+source/hal/+bug/213128 more information is available there, but here's a summary: versions acpi 1.2 kernel 2.6.28-11.42 hal properly reports battery charging/discharging state but incorrectly reports whether the AC adapter is unplugged. lshal output when unplugged or plugged in both indicates: ac_adapter.present = true (bool) in Jaunty: acpi -V (plugged in) Battery 0: Charging, 81%, 04:06:26 until charged Battery 0: design capacity 53280 mAh, last full capacity 50890 mAh = 95% AC Adapter 0: on-line Thermal 0: ok, 47.0 degrees C Cooling 0: LCD 0 of 8 Cooling 1: Processor 0 of 10 Cooling 2: Processor 0 of 10 acpi -V (unplugged) Battery 0: Discharging, 81%, 02:16:47 remaining Battery 0: design capacity 53280 mAh, last full capacity 50890 mAh = 95% AC Adapter 0: on-line Thermal 0: ok, 47.0 degrees C Cooling 0: LCD 0 of 8 Cooling 1: Processor 0 of 10 Cooling 2: Processor 0 of 10
Any more ideas as to how to fix this as we know it works after a sleep? What else can i do (after getting my laptop back from repair as the ac socket snapped off the main board :/ !) Cheers
Ping :) no idea?
adam, do you have a system to test on? is this still a problem with the latest stable kernel?
Hi Len, yes i still have the laptop and still have problems (currently using 2.6.31-desktop-0.rc5)
hmmm, ive just observed it working, using kernel 2.6.31-desktop-2mnb [root@localhost piggz]# lshal --monitor Start monitoring devicelist: ------------------------------------------------- 19:41:07.268: computer_power_supply_battery_BAT0 property battery.remaining_time = 2795 (0xaeb) 19:41:07.269: computer_power_supply_battery_BAT0 property battery.charge_level.percentage = 31 (0x1f) 19:41:07.271: computer_power_supply_battery_BAT0 property battery.charge_level.rate = 68756 (0x10c94) 19:41:07.271: computer_power_supply_battery_BAT0 property battery.charge_level.current = 23998 (0x5dbe) 19:41:07.272: computer_power_supply_battery_BAT0 property battery.reporting.current = 1015 (0x3f7) 19:41:07.273: computer_power_supply_battery_BAT0 property battery.reporting.rate = 2908 (0xb5c) 19:41:07.273: computer_power_supply_ac_adapter_ADP0 property ac_adapter.present = false 19:41:07.550: computer property power_management.is_powersave_set = true 19:41:11.739: computer_power_supply_ac_adapter_ADP0 property ac_adapter.present = true 19:41:11.742: computer_power_supply_battery_BAT0 property battery.remaining_time = 2859 (0xb2b) 19:41:11.744: computer_power_supply_battery_BAT0 property battery.charge_level.rate = 67219 (0x10693) 19:41:11.745: computer_power_supply_battery_BAT0 property battery.reporting.rate = 2843 (0xb1b) 19:41:12.037: computer property power_management.is_powersave_set = false ^C [root@localhost piggz]# ac ac accept accton aclocal-1.11 aclocal-1.9 acpi acpidump acpitool activation-client ac3dec accept-cups aclocal aclocal-1.8 aconnect acpid acpi_listen acpixtract acyclic [root@localhost piggz]# acp acpi acpid acpidump acpi_listen acpitool acpixtract [root@localhost piggz]# acpi_listen --help Usage: acpi_listen [OPTIONS] -c, --count Set the maximum number of events. -s, --socketfile Use the specified socket file. -t, --time Listen for the specified time (in seconds). -v, --version Print version information. -h, --help Print this message. [root@localhost piggz]# acpi_listen ac_adapter ADP0 00000000 00000000 battery BAT0 00000080 00000001 battery BAT0 00000081 00000001 ac_adapter ADP0 00000000 00000001 battery BAT0 00000080 00000001 battery BAT0 00000081 00000001 q^C
hmm, i take it back, i rebooted and now it doesnt work, and i dont know why!!!!!!!!!
First time, did you reboot from windows into linux?
no, i dont have windows.....i did reboot from a different kernel, kernel-tmb-2.3.31-2 which is a mandriva kernel based on 2.6.31, but with some experimental patches. When it was working, i remember the following from the end of dmesg: ACPI: EC: missing confirmations, switch off interrupt mode. I dont have that line anymore in dmesg
Well, we could try to emulate effect of this warning... Please comment out whole if() statement at drivers/acpi/ec.c:595
My ec.c seems different to yours, line 595 is the return from acpi_ec_gpe_handler. Do you mean to comment out lines in acpi_ec_wait? If you're on irc, im piggz.
Created attachment 23102 [details] comment out switch to interrupt mode Here is the patch, please check if it helps
bah, ran out if disk space building kernel....working around..... in the mean time i rebooted into kernel-tmb, and acpi is working again, dmesg attached.
Created attachment 23104 [details] dmesg dmesg output
Ive built a vanilla kernel with the patch applied (using the .config from tmb and doing make oldconfig). I dont get the message above, and it doesnt work. I also cant get any other kernel to work anymore. Ive seen it work with both mnb and tmb kernels, but not all the time, and dont know what to do to make it work.
if patch does not help, then message was irrelevant to the problem. please try to remove all the power from notebook (e.g. power off, _disconnect_ ac power plug and remove battery), this might help with stuck EC.
\o/ Ive rebooted about 10 times now and can regularly make it work/not work. Its quite simple really (which is even more frustrating!:) I checked back through the comments, and read posts on the ubuntu and archlinux threads, and got pointed to the gentoo wiki on dsdt. I know ive looked at this in the past but figured i'd look again. Then i read about linux ignoring _OSI(Linux), and learned of acpi_osi="". I disassembled by dsdt, and found the what is at the end of the post. i set acpi_osi="Linux" on the cmdline, and it now works perfectly. With this set i get this message from the kernel: [ 0.000000] ACPI: Added _OSI(Linux) [ 0.104794] ACPI: BIOS _OSI(Linux) query honored via cmdline as opposed to ACPI: BIOS _OSI(Linux) query ignored. Ive also tried other values such as "Windows 2001 SP2" and "Windows 2006 SP2", but these dont work, all i see in the kernel log is that the query for Linux was ignored. Anyway, atm im happy, power events are now working. ======================================================= Snipping from dsdt: If (CondRefOf (_OSI, Local0)) { If (_OSI ("Linux")) { Store (0x03E8, OSYS) } Else { Store (0x07D0, OSYS) If (_OSI ("Windows 2001")) { Store (0x07D1, OSYS) } If (_OSI ("Windows 2001 SP1")) { Store (0x07D1, OSYS) } If (_OSI ("Windows 2001 SP2")) { Store (0x07D2, OSYS) } If (_OSI ("Windows 2006")) { Store (0x07D6, OSYS) } If (LNotEqual (OSYS, 0x07D6)) { If (_OSI ("Windows 2006 SP1")) { Store (0x07D6, OSYS) } Else { If (_OSI ("Windows 2006 SP2")) { Store (0x07D6, OSYS) } } } } } Else { Store (0x07D0, OSYS) }
Created attachment 23273 [details] Quirk to enable OSI(Linux) on Satellite L355 Please check if this patch is sufficient without cmdline osi=... string.
does the laptop also work if you boot with acpi_osi="!Windows 2006" AND acpi_osi="!Windows 2006 SP1"?
No, ive tried with both of them and it doesnt work. Any idea which kernel the above patch will be in? Anything else you'd like me to try?
Did you mean to have both acpi_osi lines on the cmdline at the same time?
Interesting...it DOES work if both are on the cmdline :) ......... so what doe that mean, it likes to mimic a Windows 2001 SP2? I will see if this makes sleep/resume work (and re-open that bug)
this is a piece of code in EC _REG method. If (LGreater (OSYS, 0x07D5)) { WREC (0xDB, One, Zero, One) FLNK (0x14, One) Store (One, HKEM) WREC (0xDB, 0x10, 0x04, One) Store (One, HSEM) WREC (0xDB, 0x20, 0x05, One) If (LNotEqual (EVCT, Zero)) { FLNK (0x11, EVCT) Store (And (KYB0, 0xFF), HSWK) Store (Zero, KYB0) } FLNK (0x10, One) FLNK (0x15, 0xFF) } Else { WREC (0xDB, One, Zero, Zero) FLNK (0x15, 0xFF) } Not sure if this causes the problem.
is this summary correct? acpi_osi="Linux" WORKS acpi_osi="!Windows 2006" FAILS acpi_osi="!Windows 2006" acpi_osi="!Windows 2006 SP1" WORKS Note that ACPICA in Linux does not claim compatibility with "Windows 2006 SP2" -- so that check in the AML is a no-op.
Created attachment 31772 [details] Quirk to disable OSI Vista compatiblity please test this patch. It deletes Vista OSI compatibility directly rather than indirectly as was done with the previous patch that used OSI(Linux).
commit 7a1d602f5fc35d14907b7da98d5627acb69589d1 Author: Len Brown <len.brown@intel.com> Date: Tue Sep 28 17:51:51 2010 -0400 ACPI: EC: add Vista incompatibility DMI entry for Toshiba Satellite L355 shipped in Linux-2.6.36-rc6-git2 closed
You happy even though i didnt test from comment 63 yet?
Never too late to supply test results, however, in the absence of test results, sometimes we have to guess...