Description Stefan Nagy 2013-03-01 20:58:28 UTC
No matter if I'm on battery (discharging) or have the ac adapter plugged in (charging), if I'm plugging the ac adapter in or out – I don't see any power related uevents from the kernel with 'udevadm monitor' or 'udevadm monitor --kernel'. I also tried to change the logging priority of udevadm with 'udevadm control --log-priority=debug' – without any luck. Since the kernel sends no power related uevents, UPower doesn't update the status of the ac adapter (un/plugged). The value 'Updated' for device /org/freedesktop/UPower/devices/line_power_ACAD reported by UPower will always be similar to uptime, no matter how long that is and how often I un/plugged the ac adapter in the meantime. When I booted with the ac adapter plugged in and at some point I plug it out and decided to work on battery my notebook will never be sent into hibernation because UPower thinks the ac adapter is still plugged in. I guess UPower expects an uevent from the kernel. However, UPower seems to force an update of the battery status every 30 seconds (UPowerd tells me: 'No updates on supply /org/freedesktop/UPower/devices/battery_BAT1 for 30 seconds; forcing update'), so the charging level reported by the battery status applet in GNOME corresponds to the reported value in /sys/class/power_supply/BAT1/uevent (POWER_SUPPLY_CAPACITY). I'm sorry for opening this bug report while #54241 is still open, but it seems to me that these are two separate issues. Feel free to close one of those two bugs, if you think that this symptoms are caused by the same bug. You'll find relevant log files at #54241, please tell me if you need more information.
Comment 1 Aaron Lu 2013-03-04 02:08:35 UTC
Hi Stefan, Please attach the your outpuf of acpidump: # acpidump > acpidump.out Thanks.
Comment 3 Lan Tianyu 2013-03-05 12:23:47 UTC
Hi: Please attach the output of "grep . /sys/firmware/acpi/interrupts/*".
Comment 4 Stefan Nagy 2013-03-05 12:43:46 UTC
Created attachment 94551 [details] output of 'grep . /sys/firmware/acpi/interrupts/*'
Comment 5 Lan Tianyu 2013-03-05 12:55:16 UTC
Have you plugged the ac adapter in or out? From this output, gpe25, 37, 38 which are related with battery and AC have not been triggered.
Comment 6 Stefan Nagy 2013-03-05 13:04:01 UTC
Created attachment 94561 [details] output of 'grep . /sys/firmware/acpi/interrupts/*' (on battery) When I provided the first output of 'grep . /sys/firmware/acpi/interrupts/*', the ac adapter was plugged in. Now I'll attach the output when I'm on battery. Maybe they are the same – I'm in work right now, so I can't take a closer look.
Comment 7 Stefan Nagy 2013-03-06 17:50:05 UTC
It makes no difference if I boot with the ac adapter plugged in or out – the output of 'grep . /sys/firmware/acpi/interrupts/*' always looks the same (see attachment 94551 [details]). Please tell me if you need more information.
Comment 8 Lan Tianyu 2013-03-21 13:15:22 UTC
Created attachment 95921 [details] debug.patch Please attach the output of dmesg with debug.patch and kernel param "log_buf_len=1M" after plugging or unplugging AC.
Comment 9 Stefan Nagy 2013-03-21 18:00:09 UTC
Created attachment 95941 [details] dmesg log: kernel 3.8.4, debug-patch applied, kernel parameter log_buf_len=1M
Comment 10 Stefan Nagy 2013-03-21 18:07:17 UTC
Before I saved the dmesg log I provided in comment #9 I started the notebook with the ac adapter plugged in, unplugged it and then plugged it in again. It seems there's no trace of the un/plugging of the ac adapter in the log file…
Comment 11 Lan Tianyu 2013-03-25 02:03:34 UTC
From the log, there is some AML error log which is related with EC. These log show the _REG failed to be executed. This will make EC driver fail to be loaded. Without EC driver, acpi event will not be triggered. Hi Bob & Lv: Could you have a look? [ 0.131325] ACPI: EC: Look up EC in DSDT [ 0.134114] ACPI: Executed 1 blocks of module-level executable AML code [ 0.138764] [Firmware Bug]: ACPI: BIOS _OSI(Linux) query ignored [ 0.139395] ACPI: SSDT 00000000ace70798 00727 (v01 PmRef Cpu0Cst 00003001 INTL 20100121) [ 0.139862] ACPI: Dynamic OEM Table Load: [ 0.139865] ACPI: SSDT (null) 00727 (v01 PmRef Cpu0Cst 00003001 INTL 20100121) [ 0.140890] ACPI: SSDT 00000000ace71a98 00303 (v01 PmRef ApIst 00003000 INTL 20100121) [ 0.141405] ACPI: Dynamic OEM Table Load: [ 0.141407] ACPI: SSDT (null) 00303 (v01 PmRef ApIst 00003000 INTL 20100121) [ 0.141600] ACPI: SSDT 00000000ace6fd98 00119 (v01 PmRef ApCst 00003000 INTL 20100121) [ 0.142056] ACPI: Dynamic OEM Table Load: [ 0.142058] ACPI: SSDT (null) 00119 (v01 PmRef ApCst 00003000 INTL 20100121) [ 0.143173] ACPI Error: No handler for Region [RCM0] (ffff880149e78b28) [SystemCMOS] (20121018/evregion-376) [ 0.143178] ACPI Error: Region SystemCMOS (ID=5) has no handler (20121018/exfldio-305) [ 0.143182] ACPI Error: Method parse/execution failed [\_SB_.WMID.ESDT] (Node ffff880149e7ba88), AE_NOT_EXIST (20121018/psparse-537) [ 0.143188] ACPI Error: Method parse/execution failed [\_SB_.PCI0.LPCB.EC0_._REG] (Node ffff880149e896a0), AE_NOT_EXIST (20121018/psparse-537) [ 0.143200] ACPI: Interpreter enabled [ 0.143205] ACPI: (supports S0 S3 S4 S5)
Comment 12 Aaron Lu 2013-03-25 02:14:11 UTC
Looks like we don't have operation region handler for SystemCMOS - EC's _REG control method calls WMID.ESDT, and ESDT reference RTC.RTCW, which is defined in a SystemCMOS region.
Comment 13 Lan Tianyu 2013-03-25 03:51:44 UTC
Created attachment 96091 [details] debug.patch Please try this patch with the previous patch and attach the output of dmesg. This patch is to add CMOS operation region into default_address_spaces list. CA should hook CMOS region handler defaultly.
Comment 14 Lan Tianyu 2013-03-25 07:14:02 UTC
Hi Bob: I find acpi_ex_cmos_space_handler is almost empty function. This mean the handler does nothing. This seems a gab. Should we implement it? At last, This machine needs it?
Comment 15 Stefan Nagy 2013-03-25 16:00:37 UTC
Created attachment 96141 [details] dmesg log: kernel 3.9-rc4, debug-patches applied, kernel parameter log_buf_len=1M This is just great, I can't believe it… This patch not only solves the AC adapter issue – it also fixes bug #43097. All special keys are working now. I just applied the patch and I'll test this some more but this is just… awesome!! :)
Comment 16 Robert Moore 2013-03-27 20:24:36 UTC
The default SystemCMOS space handler does nothing. It is not installed by default. And it probably should not be -- otherwise we have a handler that takes a request, does nothing, but reports back that not only did it do it, it did it with no error (it lies). It makes little sense to me to attempt to duplicate the code of three different device drivers (for the 3 different RTC chips) in the ACPICA core code. The OS should detect the PNP ID and load the correct device driver. The only real problem that I see here is the ordering of the loading of the device drivers -- in this case, the RTC/CMOS driver should be loaded before the EC driver.
Comment 17 Stefan Nagy 2013-03-28 08:35:57 UTC
After testing this some more I wanted to confirm that the patch provided in comment #13 fixes this bug: the kernel produces uevents for the AC adapter. Without this patch the status of the AC adapter in upower will never change. When I boot with the AC adapter plugged in and later disconnect the AC adapter the computer won't be send into hibernation since according to upower the adapter is still plugged in. With this patch applied the status of the AC adapter in upower is updated immediately. As already mentioned in comment #15 this patch also fixes bug #43097: With the patch applied the two special keys for brightness +/- as well as the wireless adapter toggle work as expected. Please tell me if you need more information.
Comment 18 Francescodario Cuzzocrea 2013-04-01 19:53:13 UTC
Hello, I'm afflicted by this bug too. I'm using a Samsung NP535U3C laptop, AMD A6-4455 APU, radeon 7500HD graphics. I've tried to compile 3.9.0rc4 kernel with patch provided in comment 13 but this fixed only the backlight issue mentioned by Stefan, but not the bug about uevents.
Comment 19 Lan Tianyu 2013-04-07 12:48:52 UTC
Created attachment 97641 [details] debug patch Hi Stefan: Could you test this patch and attach the output of dmesg? Thanks in advance.
Comment 20 Stefan Nagy 2013-04-09 12:48:52 UTC
Created attachment 97821 [details] dmesg log: kernel 3.9-rc6, debug-patches applied, kernel parameter log_buf_len=1M I applied both patches from comment #8 and comment #19, booted with kernel parameter "log_buf_len=1M" and plugged the AC adapter out and in again. The new patch (from comment #19) doesn't fix the bug. No matter how often I plug the AC adapter in or out, Upower always tells me that the adapter is plugged in (the status never gets updated). BTW, the keys which were fixed by the patch from comment #13 won't work with the latest patch applied.
Comment 21 Lan Tianyu 2013-04-09 13:24:08 UTC
Hi: Thanks for test. Please apply the following patch with comment #19. Thanks in advance. diff --git a/drivers/acpi/ec.c b/drivers/acpi/ec.c index 57c676a..3fff9c9 100644 --- a/drivers/acpi/ec.c +++ b/drivers/acpi/ec.c @@ -126,7 +126,7 @@ EXPORT_SYMBOL(first_ec); static int EC_FLAGS_MSI; /* Out-of-spec MSI controller */ static int EC_FLAGS_VALIDATE_ECDT; /* ASUStec ECDTs need to be validated */ -static int EC_FLAGS_SKIP_DSDT_SCAN; /* Not all BIOS survive early DSDT scan */ +static int EC_FLAGS_SKIP_DSDT_SCAN = 1; /* Not all BIOS survive early DSDT scan */ /* -------------------------------------------------------------------------- Transaction Management
Comment 22 Stefan Nagy 2013-04-09 16:44:29 UTC
Created attachment 97881 [details] dmesg log: kernel 3.9-rc6, debug-patches from comments 19 and 21 applied Hi, this time I applied both patches from comment #19 and comment #21 and then plugged the AC adapter out and in again. These patches fix the bug for me. I get messages about the AC adapter with acpi_listen and UPower updates its status immediately when I plug the adapter in/out. These patches also fix bug #43097.
Comment 23 Lan Tianyu 2013-04-10 02:47:50 UTC
*** Bug 43097 has been marked as a duplicate of this bug. ***
Comment 24 Lan Tianyu 2013-04-10 03:00:36 UTC
Thanks for test. I will prepare formal patchset to upstream. I think this bug will be fixed in the v3.10. Otherwise, please feel free to reopen this bug after one month if the patchset hasn't been merged by upstream kernel.
Comment 25 Stefan Nagy 2013-04-10 13:48:07 UTC
It would be great if you could post a link to the patchset (commit) here when it's ready. Thanks!
Comment 26 Daniel van Vugt 2013-04-12 02:39:57 UTC
I'm not sure a fix has been committed anywhere yet. That's OK, but it means the status is incorrect and misleading: Status: RESOLVED CODE_FIX
Comment 27 Lan Tianyu 2013-04-12 03:01:36 UTC
Hi Daniel: Sorry to confuse you. From my understand, code_fix should be there is a available code can fix the bug. They are in the Comment #19 and Comment #21. This seems confuse others. Now, I reopen it.
Comment 28 Lan Tianyu 2013-04-12 15:59:25 UTC
Created attachment 98441 [details] patch Please try this new patchset again. Thanks. I merge two patches as one.
Comment 29 Stefan Nagy 2013-04-14 16:47:24 UTC
Created attachment 98611 [details] dmesg log: kernel 3.9-rc6, debug-patch from comment 28 applied Hi, I applied the patch from comment #28 and plugged the AC adapter out and in again. The patch fixes the bug for me. I get messages about the AC adapter with acpi_listen and UPower updates its status immediately when I plug the adapter in/out. The patch also fixes bug #43097.
Comment 30 Stefan Nagy 2013-04-21 20:44:47 UTC
Hi Lan, do you need any more information? Will this patch make it into v.3.10? Thanks, Stefan.
Comment 31 Lan Tianyu 2013-04-22 14:01:29 UTC
HI Stefan: Currently, no other info needs. I have sent my patch to internal review in our group. I think there will be a conclusion soon. This is a fix patch. So it's easy to be merged into v3.10.
Comment 32 Stefan Nagy 2013-05-03 14:51:17 UTC
I don't know if this info changes anything for the proposed fix, but the boot parameter acpi_osi= seems to solve this problem aswell… I tested this with kernel v.3.8.5 after I got a hint from an Ubuntu user, see comments #18 and #19 here: https://bugs.launchpad.net/ubuntu/+source/upower/+bug/994745 Cheers, Stefan.
Comment 33 Lan Tianyu 2013-05-08 02:34:43 UTC
Thanks for your info. "acpi_osi= " will change the BIOS behavior. No ACPI handler for RTC CMOS is fuction lack. So I perfer the previous solution. I have some discussions internal and get some feedbacks. I will update the patch soon.
Comment 35 Lan Tianyu 2013-05-29 06:03:18 UTC
Created attachment 102801 [details] patch2 Hi: Sorry for later response. After several internal reviews, I finish the formal patches and please test it. If it's ok, I will send them to acpi maillist for v3.10. Thanks in advance.
Comment 36 Lan Tianyu 2013-05-29 06:04:48 UTC
BTW, please these patches are based on v3.10-rc3. So please base on it.
Comment 37 Stefan Nagy 2013-05-29 09:46:33 UTC
Created attachment 102821 [details] dmesg log: kernel 3.10-rc3, patches from comments 34 and 35 applied Hi Lan, I applied the patches from comment #34 and comment #35 on top of kernel v.3.10-rc3 – the patches work fine. Please tell me if you need more information. Cheers, Stefan.
Comment 38 Lan Tianyu 2013-05-30 02:15:11 UTC
Two patches have been sent to ACPI maillist. https://patchwork.kernel.org/patch/2629531/ https://patchwork.kernel.org/patch/2629541/
Comment 39 Lan Tianyu 2013-06-17 08:53:27 UTC
These patches has been merged into linux-pm tree. commit 12909edd154fec4ff69fb97904c9c9c4847781ec Author: Lan Tianyu <firstname.lastname@example.org> Date: Wed May 29 12:04:00 2013 +0000 ACPI / EC: Add HP Folio 13 to ec_dmi_table in order to skip DSDT scan HP Folio 13's BIOS defines CMOS RTC Operation Region and the EC's _REG method will access that region. To allow the CMOS RTC region handler to be installed before the EC _REG method is first invoked, add ec_skip_dsdt_scan() as HP Folio 13's callback to ec_dmi_table. [rjw: Changelog] References: https://bugzilla.kernel.org/show_bug.cgi?id=54621 Reported-and-tested-by: Stefan Nagy <email@example.com> Signed-off-by: Lan Tianyu <firstname.lastname@example.org> Cc: 3.9+ <email@example.com> Signed-off-by: Rafael J. Wysocki <firstname.lastname@example.org> commit 2242e7b8b264431379b4efec04287220eca769e5 Author: Lan Tianyu <email@example.com> Date: Wed May 29 12:03:59 2013 +0000 ACPI: Add CMOS RTC Operation Region handler support On HP Folio 13-2000, the BIOS defines a CMOS RTC Operation Region and the EC's _REG methord accesses that region. Thus an appropriate address space handler must be registered for that region before the EC driver is loaded. Introduce a mechanism for adding CMOS RTC address space handlers. Register an ACPI scan handler for CMOS RTC devices such that, when a device of that kind is detected during an ACPI namespace scan, a common CMOS RTC operation region address space handler will be installed for it. [rjw: Changelog] References: https://bugzilla.kernel.org/show_bug.cgi?id=54621 Reported-and-tested-by: Stefan Nagy <firstname.lastname@example.org> Signed-off-by: Lan Tianyu <email@example.com>
Comment 40 Stefan Nagy 2013-06-17 10:55:10 UTC
Great, thanks for the info!
Comment 41 Oleg Strelnikov 2013-12-20 00:03:00 UTC
Is fix added to the 3.11 kernel? The bug is still exists on my Sony VPCEH: uname -a Linux globe 3.11-0.bpo.2-amd64 #1 SMP Debian 3.11.8-1~bpo70+1 (2013-11-21) x86_64 GNU/Linux
Comment 42 Lan Tianyu 2013-12-20 02:14:25 UTC
(In reply to Oleg Strelnikov from comment #41) > Is fix added to the 3.11 kernel? Yes. > The bug is still exists on my Sony VPCEH: > uname -a > Linux globe 3.11-0.bpo.2-amd64 #1 SMP Debian 3.11.8-1~bpo70+1 (2013-11-21) > x86_64 GNU/Linux The fix patch is dedicated for HP Folio 13. Please open a new bug for your machine.