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]

Message-Id: <200904131315.55519.bjorn.helgaas@hp.com>
Date:	Mon, 13 Apr 2009 13:15:54 -0600
From:	Bjorn Helgaas <bjorn.helgaas@...com>
To:	Alan Jenkins <alan-jenkins@...fmail.co.uk>
Cc:	linux-acpi@...r.kernel.org,
	"linux-kernel" <linux-kernel@...r.kernel.org>,
	Kernel Testers List <kernel-testers@...r.kernel.org>,
	Venkatesh Pallipadi <venkatesh.pallipadi@...el.com>
Subject: Re: [BISECTED] EEE PC hangs when booting off battery

On Sunday 12 April 2009 07:11:57 am Alan Jenkins wrote:
> Alan Jenkins wrote:
> > Tzy-Jye Daniel Lin wrote:
> >> On Sat, Apr 11, 2009 at 5:41 AM, Alan Jenkins
> >> <alan-jenkins@...fmail.co.uk> wrote:
> >>   
> >>> Regression #6 on latest git! (last known good is 2.6.29-rc8)

You mention that this occurs when booting off battery.  So I
assume everything works fine when the EEE is plugged in to the
wall socket?

> >>> Magic SysRQ keys work though.  ...
> > I was able to run SysRq-P, and found the following backtrace -
> >
> > Pid: 0
> > EIP is at acpi_idle_enter_bm+0x1df/0x208 [processor]

Can you figure out where this is in acpi_idle_enter_bm() or
maybe just email me your processor.ko module?

Does it always happen at the same point?

If you blacklist or rename the processor module to prevent it
from loading, does that keep the hang from occurring?

> > cpud_idle_call
> > cpu_idle
> > rest_init
> > start_kernel
> > i386_start_kernel
> 
> 7ec0a7290797f57b780f792d12f4bcc19c83aa4f is first bad commit
> commit 7ec0a7290797f57b780f792d12f4bcc19c83aa4f
> Author: Bjorn Helgaas <bjorn.helgaas@...com>
> Date:   Mon Mar 30 17:48:24 2009 +0000

Ouch, sorry about that.  Thanks for doing all the bisection work.

>     ACPI: processor: use .notify method instead of installing handler
> directly
> 
>     This patch adds a .notify() method.  The presence of .notify() causes
>     Linux/ACPI to manage event handlers and notify handlers on our behalf,
>     so we don't have to install and remove them ourselves.
> 
>     Signed-off-by: Bjorn Helgaas <bjorn.helgaas@...com>
>     CC: Zhang Rui <rui.zhang@...el.com>
>     CC: Zhao Yakui <yakui.zhao@...el.com>
>     CC: Venki Pallipadi <venkatesh.pallipadi@...el.com>
>     CC: Anil S Keshavamurthy <anil.s.keshavamurthy@...el.com>
>     Signed-off-by: Len Brown <len.brown@...el.com>
> 
> However, reverting this commit from v2.6.30-rc1 doesn't solve the hang.

I don't see the problem in that commit yet, and if there is a problem
with it, I would think that reverting it from 2.6.30-rc1 would solve
it.  But maybe it'd be useful to revert the whole .notify series to
make sure.  From 2.6.30-rc1, you should be able to revert these:

  7ec0a7290797f57b780f792d12f4bcc19c83aa4f processor
  373cfc360ec773be2f7615e59a19f3313255db7c button
  46ec8598fde74ba59703575c22a6fb0b6b151bb6 Linux/ACPI infrastructure

What happens with those commits reverted?

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/