mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Tobias Karnat <tobias.karnat@googlemail.com>
To: Thomas Renninger <trenn@suse.de>
Cc: richard.coe@med.ge.com, jslaby@novell.com,
	linux-acpi@vger.kernel.org,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: acpi_button: random oops on boot
Date: Mon, 24 Jan 2011 19:13:06 +0100	[thread overview]
Message-ID: <1295892786.3265.48.camel@Tobias-Karnat> (raw)
In-Reply-To: <201101241403.21707.trenn@suse.de>

Am Montag, den 24.01.2011, 14:03 +0100 schrieb Thomas Renninger:
> Aren't there some memory corruption checkers which can
> additionally be enabled?
> 
> CONFIG_DEBUG_SLAB
> Say Y here to have the kernel do limited verification on memory
> allocation as well as poisoning memory on free to catch use of freed
> memory. This can make kmalloc/kfree-intensive workloads much slower.
> 
> CONFIG_DEBUG_VM
> Enable this to turn on extended checks in the virtual-memory system
> that may impact performance.
> 
> CONFIG_DEBUG_LIST
> Enable this to turn on extended checks in the linked-list
> walking routines.
> 
> CONFIG_DEBUG_PAGEALLOC
> Unmap pages from the kernel linear mapping after free_pages().
> This results in a large slowdown, but helps to find certain types
> of memory corruption.
> 
> Did I oversee one?
> 
> Not sure which is best, it should not hurt to turn on all
> (if possible) for a test.
> 
>     Thomas

I would like to help, but I don't have another pc here, which I could
connect over serial. And when it crashes on boot, there is never a call
trace to see.

I hope Rich is still interested in a solution as I am. The bad thing is
that the latest working version I had been running on that machine was
ancient 2.6.23. So this problem is a regression, which I would have
noticed earlier, if I had updated that machine more often.

It is not an hardware problem, I have edac enabled and I don't see any
errors. The only strange thing I get related to memory is an mtrr entry
of 64GB (I only have 6GB).

-Tobias


  reply	other threads:[~2011-01-24 18:13 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-12-04 15:49 Tobias Karnat
2010-12-06 16:28 ` Bjorn Helgaas
2010-12-06 23:01   ` Tobias Karnat
2010-12-06 23:26     ` Bjorn Helgaas
2010-12-06 23:54       ` Tobias Karnat
2010-12-07  0:22         ` Tobias Karnat
2010-12-07  5:15         ` Bjorn Helgaas
2010-12-07 14:44           ` Rich Coe
2010-12-07 15:02           ` Tobias Karnat
2010-12-07 15:35             ` Tobias Karnat
2010-12-07 15:52               ` Tobias Karnat
2011-01-24 13:03           ` Thomas Renninger
2011-01-24 18:13             ` Tobias Karnat [this message]
2011-01-24 18:48               ` Rich Coe

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1295892786.3265.48.camel@Tobias-Karnat \
    --to=tobias.karnat@googlemail.com \
    --cc=jslaby@novell.com \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=richard.coe@med.ge.com \
    --cc=trenn@suse.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®