linux-kernel - Re: [BISECTED] EEE PC hangs when booting off battery

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 14 Apr 2009 10:56:13 -0600
From:	Bjorn Helgaas <bjorn.helgaas@...com>
To:	"Moore, Robert" <robert.moore@...el.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

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/