Date:	Tue, 14 Apr 2009 10:22:25 -0700
From:	"Moore, Robert" <robert.moore@...el.com>
To:	Bjorn Helgaas <bjorn.helgaas@...com>
CC:	Arjan van de Ven <arjan@...radead.org>,
	Alan Jenkins <alan-jenkins@...fmail.co.uk>,
	"linux-acpi@...r.kernel.org" <linux-acpi@...r.kernel.org>,
	linux-kernel <linux-kernel@...r.kernel.org>,
	Kernel Testers List <kernel-testers@...r.kernel.org>,
	"Pallipadi, Venkatesh" <venkatesh.pallipadi@...el.com>
Subject: RE: [BISECTED] EEE PC hangs when booting off battery

Your understanding is correct. 

The only interesting thing that happens when executing the battery methods like _STA, _BIF, and _BST is that the EC is usually involved - and this can be slow. Note that the AML interpreter is unlocked before accessing an EC operation region.

>-----Original Message-----
>From: Bjorn Helgaas [mailto:bjorn.helgaas@...com]
>Sent: Tuesday, April 14, 2009 9:56 AM
>To: Moore, Robert
>Cc: Arjan van de Ven; Alan Jenkins; linux-acpi@...r.kernel.org; linux-
>kernel; Kernel Testers List; Pallipadi, Venkatesh
>Subject: Re: [BISECTED] EEE PC hangs when booting off battery
>
>On Tuesday 14 April 2009 09:55:58 am Moore, Robert wrote:
>> In fact, ACPI methods can execute concurrently -- constrained by the ACPI
>specification itself. The "big lock" is released before anything that will
>block for a significant amount of time, allowing other methods to run.
>
>We had a discussion about this a couple years ago:
>  http://www.mail-archive.com/linux-acpi%40vger.kernel.org/msg06976.html
>
>Here's my understanding (please correct me if I'm wrong):
>
>- The ACPI CA holds a mutex while executing an AML method (see
>  acpi_ex_enter_interpreter()).
>
>- When an AML method blocks, the ACPI CA releases the mutex, which
>  allows another AML method to run while the first is blocked.
>
>- Because of the mutex, at most one AML method can be executing at
>  any given time.  Others may have started, but they are blocked
>  until the current method completes or blocks itself.
>
>- The undocumented "acpi_serialize" option makes the ACPI CA hold
>  the mutex for the entire duration of a method, even while a method
>  is blocked.
>
>Based on that, my guess about the battery init being slow because of
>a long-running AML method might be incorrect, although I suppose
>it's still possible to write AML busy-loops that never block.
>
>I'd really like to understand what's making it slow.  The only
>thing that looks at all unusual in acpi_battery_add() is
>acpi_battery_update(), and that evaluates _STA and _BIF and
>not much else.
>
>Arjan, do you have any more information?  Is the battery driver
>slow on all laptops?  If not, where did you see the problem?  Do
>you have a DSDT for them?
>
>Bjorn
>
>> >-----Original Message-----
>> >From: linux-acpi-owner@...r.kernel.org [mailto:linux-acpi-
>> >owner@...r.kernel.org] On Behalf Of Bjorn Helgaas
>> >Sent: Tuesday, April 14, 2009 8:49 AM
>> >To: Arjan van de Ven
>> >Cc: Alan Jenkins; linux-acpi@...r.kernel.org; linux-kernel; Kernel
>Testers
>> >List; Pallipadi, Venkatesh
>> >Subject: Re: [BISECTED] EEE PC hangs when booting off battery
>> >
>> >On Tuesday 14 April 2009 09:17:28 am Arjan van de Ven wrote:
>> >> On Tue, 14 Apr 2009 08:59:01 -0600
>> >> Bjorn Helgaas <bjorn.helgaas@...com> wrote:
>> >>
>> >> > I can't help with the real problem of why the asynchronous battery
>> >> > init causes the hang.
>> >>
>> >> that got fixed already for the module case.
>> >
>> >But apparently still broken for the builtin case?  I think Alan is
>> >running pretty new bits -- he said "latest git" on April 11.
>> >
>> >> > But I do object to the magic makefile ordering change in that
>commit.
>> >> > Nobody reading the makefile can tell why battery is down at the end,
>> >> > and moving it apparently slows down boot significantly.
>> >>
>> >> for all cases I've seen it actually speeds it up, because the battery
>> >> now runs concurrently with the disk probe.
>> >
>> >I understand; I just meant that if somebody moves it back where it
>> >was, we'll mysteriously lose the speedup you got.  Maybe a comment
>> >in the makefile would be a short-term solution.
>> >
>> >> > So the
>> >> > ordering change just feels like a band-aid that covers up a place
>> >> > where ACPI could be improved.
>> >>
>> >> the reason for the move is that both the battery and other pieces take
>> >> the big acpi lock; which defeats the parallelism. So the battery needs
>> >> to happen at the end instead.
>> >
>> >Yep.  But I don't think it's anything about the Linux battery driver
>> >itself that makes it slow.  I think it's more likely that some of the
>> >ACPI methods it executes happen to be slow.  And that could afflict
>> >*any* driver, depending on the whim of a BIOS writer.
>> >
>> >My guess is that if we could run ACPI methods concurrently and avoid
>> >that big lock, the ordering wouldn't matter.  I know we probably can't
>> >do that any time soon, but I think it's good to make the problem
>> >visible at least with a "we need this magic order because ACPI doesn't
>> >support concurrent method execution" sort of comment.
>> >
>> >Bjorn
--
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