| 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
| ||
|
Message-ID: <CAAW1UO9gNMo0C3Zgf3x0p9mYHdF08x16tamh4a+QASG1WVyMpw@mail.gmail.com> Date: Sun, 2 Dec 2012 00:59:22 +0400 From: Azat Khuzhin <dohardgopro@...il.com> To: Robert Hancock <hancockrwd@...il.com> Cc: Feng Tang <feng.tang@...el.com>, "Moore, Robert" <robert.moore@...el.com>, "Rafael J. Wysocki" <rjw@...k.pl>, Greg KH <gregkh@...uxfoundation.org>, "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 I tried this patch - https://bugzilla.kernel.org/attachment.cgi?id=73510 from https://bugzilla.kernel.org/show_bug.cgi?id=14733. And I don't see such messages any more. But another problem surfaced - laptop can't resume working after a long time held in suspend, end there is not messages in kern.log about that laptop trying to resume. On Sat, Nov 17, 2012 at 9:40 AM, Robert Hancock <hancockrwd@...il.com> wrote: > 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 >> > -- Azat Khuzhin -- 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