Bug 54621
|
Description
Stefan Nagy
2013-03-01 20:58:28 UTC
Hi Stefan, Please attach the your outpuf of acpidump: # acpidump > acpidump.out Thanks. Created attachment 94371 [details]
output of acpidump
Hi:
Please attach the output of "grep . /sys/firmware/acpi/interrupts/*".
Created attachment 94551 [details]
output of 'grep . /sys/firmware/acpi/interrupts/*'
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. 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.
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.
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.
Created attachment 95941 [details]
dmesg log: kernel 3.8.4, debug-patch applied, kernel parameter log_buf_len=1M
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… 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)
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. 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.
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?
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!! :) 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. 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. 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. Created attachment 97641 [details]
debug patch
Hi Stefan:
Could you test this patch and attach the output of dmesg? Thanks in advance.
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. 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
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. *** Bug 43097 has been marked as a duplicate of this bug. *** 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. It would be great if you could post a link to the patchset (commit) here when it's ready. Thanks! 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 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.
Created attachment 98441 [details]
patch
Please try this new patchset again. Thanks. I merge two patches as one.
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. Hi Lan, do you need any more information? Will this patch make it into v.3.10? Thanks, Stefan. 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.
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. 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. Created attachment 102791 [details]
patch
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.
BTW, please these patches are based on v3.10-rc3. So please base on it. 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. Two patches have been sent to ACPI maillist. https://patchwork.kernel.org/patch/2629531/ https://patchwork.kernel.org/patch/2629541/ These patches has been merged into linux-pm tree. commit 12909edd154fec4ff69fb97904c9c9c4847781ec Author: Lan Tianyu <tianyu.lan@intel.com> 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 <public@stefan-nagy.at> Signed-off-by: Lan Tianyu <tianyu.lan@intel.com> Cc: 3.9+ <stable@vger.kernel.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> commit 2242e7b8b264431379b4efec04287220eca769e5 Author: Lan Tianyu <tianyu.lan@intel.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 <public@stefan-nagy.at> Signed-off-by: Lan Tianyu <tianyu.lan@intel.com> Great, thanks for the info! 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 (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. |