| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Date: Fri, 16 Nov 2012 23:40:26 -0600 From: Robert Hancock <hancockrwd@...il.com> To: Feng Tang <feng.tang@...el.com> CC: "Moore, Robert" <robert.moore@...el.com>, "Rafael J. Wysocki" <rjw@...k.pl>, Greg KH <gregkh@...uxfoundation.org>, Azat Khuzhin <dohardgopro@...il.com>, "linux-acpi@...r.kernel.org" <linux-acpi@...r.kernel.org>, Linux Kernel Mailing List <linux-kernel@...r.kernel.org>, "Zheng, Lv" <lv.zheng@...el.com>, Len Brown <lenb@...nel.org> Subject: Re: ACPI errors with 3.7-rc3 On 11/09/2012 10:36 AM, Feng Tang wrote: > On Fri, Nov 09, 2012 at 10:30:43PM +0800, Moore, Robert wrote: >> The ACPI Global Lock is in fact intended to provide exclusion between the BIOS and the OS. >> Bob > > Thanks for the info. > > And per my check, most of ACPI FW don't implement this lock, say > after driver probe, the ec->global_lock will be 0. The DSDT is supposed to define the _GLK control method on the EC if the BIOS needs to perform its own access which may conflict with the OS usage. If it doesn't, then it should be the case that either the BIOS doesn't touch the EC itself or it uses a separate interface that doesn't cause conflicts with what the OS is doing. > > - Feng > >> >> >>> -----Original Message----- >>> From: Tang, Feng >>> Sent: Friday, November 09, 2012 1:29 AM >>> To: Rafael J. Wysocki >>> Cc: Greg KH; Azat Khuzhin; linux-acpi@...r.kernel.org; Linux Kernel >>> Mailing List; Zheng, Lv; Len Brown; Moore, Robert >>> Subject: Re: ACPI errors with 3.7-rc3 >>> >>> On Thu, Nov 08, 2012 at 05:49:40AM +0800, Rafael J. Wysocki wrote: >>>> On Tuesday, November 06, 2012 01:48:26 PM Greg KH wrote: >>>>> On Tue, Nov 06, 2012 at 04:42:24PM +0400, Azat Khuzhin wrote: >>>>>> I'v also have such errors on my macbook pro. >>>>>> >>>>>> $ dmesg | tail >>>>>> [17056.008564] ACPI Error: Method parse/execution failed >>>>>> [\_SB_.PCI0.LPCB.EC__.SMB0.SBRW] (Node ffff88026547ea10), AE_TIME >>>>>> (20120711/psparse-536) >>>>>> [17056.011194] ACPI Error: Method parse/execution failed >>>>>> [\_SB_.BAT0.UBST] (Node ffff88026547e678), AE_TIME >>>>>> (20120711/psparse-536) >>>>>> [17056.013793] ACPI Error: Method parse/execution failed >>>>>> [\_SB_.BAT0._BST] (Node ffff88026547e740), AE_TIME >>>>>> (20120711/psparse-536) >>>>>> [17056.016383] ACPI Exception: AE_TIME, Evaluating _BST >>>>>> (20120711/battery-464) [17056.511373] ACPI: EC: input buffer is >>>>>> not empty, aborting transaction [17056.512672] ACPI Exception: >>>>>> AE_TIME, Returned by Handler for [EmbeddedControl] >>>>>> (20120711/evregion-501) [17056.515256] ACPI Error: Method >>>>>> parse/execution failed [\_SB_.PCI0.LPCB.EC__.SMB0.SBRW] (Node >>>>>> ffff88026547ea10), AE_TIME >>>>>> (20120711/psparse-536) >>>>>> [17056.517886] ACPI Error: Method parse/execution failed >>>>>> [\_SB_.BAT0.UBST] (Node ffff88026547e678), AE_TIME >>>>>> (20120711/psparse-536) >>>>>> [17056.520479] ACPI Error: Method parse/execution failed >>>>>> [\_SB_.BAT0._BST] (Node ffff88026547e740), AE_TIME >>>>>> (20120711/psparse-536) >>>>>> [17056.523070] ACPI Exception: AE_TIME, Evaluating _BST >>>>>> (20120711/battery-464) >>>>> >>>>> I'm seeing this again right now. I'm wondering if it's because I'm >>>>> running on battery power at the moment: >>>>> >>>>> [41694.309264] ACPI Exception: AE_TIME, Returned by Handler for >>>>> [EmbeddedControl] (20120913/evregion-501) [41694.309282] ACPI Error: >>>>> Method parse/execution failed [\_SB_.PCI0.LPCB.EC__.SMB0.SBRW] (Node >>>>> ffff88045cc64618), AE_TIME (20120913/psparse-536) [41694.309300] >>>>> ACPI Error: Method parse/execution failed [\_SB_.BAT0.UBST] (Node >>>>> ffff88045cc64988), AE_TIME (20120913/psparse-536) [41694.309310] >>>>> ACPI Error: Method parse/execution failed [\_SB_.BAT0._BST] (Node >>>>> ffff88045cc648c0), AE_TIME (20120913/psparse-536) [41694.309324] >>>>> ACPI Exception: AE_TIME, Evaluating _BST (20120913/battery-464) >>>>> [41694.809093] ACPI: EC: input buffer is not empty, aborting >>>>> transaction >>>>> >>>>> ec_storm_threshold is still set to 8 in /sys/module/acpi/parameters/ >>>>> so that's not the issue here. >>>>> >>>>>> And also loadavg is too high ~ 10 >>>>>> While there is no process that load CPU up to 100% or like that. >>>>>> I think that this because of processes that is done in kernel space. >>>>>> (basically that one who write such errors) >>>>>> >>>>>> $ uname -a >>>>>> Linux macbook-pro-sq 3.6.5macbook-pro-custom-v0.1 #4 SMP Sun Nov 4 >>>>>> 12:39:03 UTC 2012 x86_64 GNU/Linux >>>>> >>>>> Ah, ok, that means it's not something new in 3.7-rc, so maybe it's >>>>> just never worked properly for this hardware :) >>>>> >>>>> So it's not a regression, just an ACPI issue, any ACPI developer >>>>> have an idea about this? >>>> >>>> Can you please send the output of acpidump from the affected machine(s)? >>> >>> I doubt this problem is sometimes inevitable for some machines, because >>> AFAIK most modern machines have the race problem for EC HW controller, as >>> both OS side and the BIOS may access the EC HW at the same time >>> without any race control. >>> >>> For this case, usually the battery and thermal modules (which may be >>> controlled through EC) are always monitored by BIOS, when OS also >>> frequently visit them too, the EC's own state machine may be broken and >>> not responsive due to the race, then cause the timeout error. >>> And how severe the problem will be depends on the EC HW, the quality of >>> BIOS code and OS/driver code. >>> >>> Myself have seen the similar "ACPI: EC: input buffer is not empty, >>> aborting transaction" error message on one laptop when its EC is busy >>> visited by OS. >>> >>> btw, in EC driver I see a "ec->global_lock", don't know if it was designed >>> to control the race between OS and BIOS. >>> >>> Thanks, >>> Feng > -- > To unsubscribe from this list: send the line "unsubscribe linux-acpi" in > the body of a message to majordomo@...r.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists