linux-kernel - Re: acpi_button: random oops on boot

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: <20101207051521.GA16804@helgaas.com>
Date:	Mon, 6 Dec 2010 22:15:21 -0700
From:	Bjorn Helgaas <bjorn.helgaas@...com>
To:	Tobias Karnat <tobias.karnat@...glemail.com>
Cc:	linux-acpi@...r.kernel.org,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	richard.coe@....ge.com, jslaby@...ell.com
Subject: Re: acpi_button: random oops on boot

On Tue, Dec 07, 2010 at 12:54:59AM +0100, Tobias Karnat wrote:
> Am Montag, den 06.12.2010, 16:26 -0700 schrieb Bjorn Helgaas:
> > On Monday, December 06, 2010 04:01:43 pm Tobias Karnat wrote:
> > > No, it only crashes on boot (without the printk patch).
> > > If it happens the machine is completely dead, SysRq does not work.
> > > 
> > > However it is definitely the acpi_button module, because removing it
> > > also fixes this.
> > 
> > If it crashes on boot (not when loading an acpi_button module),
> > you must be building acpi_button into the static kernel.
> 
> It does crash on boot either if built-in to the kernel or as a module,
> However it does not crash if the module is loaded/unloaded after the
> machine has booted.
> 
> > The acpi_button driver has a fairly complicated add() method.
> > In the absence of a better idea, I might just comment out blocks
> > of it and try to isolate the problem.  For example, take out
> > all the input stuff, take out the wakeup GPE stuff, take out
> > the type/name setup, etc.
> 
> Couldn't this be a compiler issue?
> Adding some printk's to fix it seems to be insane.

Agreed, adding printk's is absolutely not any kind of fix.
I think it's more likely to be some sort of memory corruption or
race than a compiler problem.  I assume there is some old kernel
that works fine, even when compiled with the same compiler.

In addition to the isolation ideas I suggested above, you might
boot with "maxcpus=1" and turn on all the Kconfig memory debug
switches.

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/