[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20120521202904.GB12123@redhat.com>
Date: Mon, 21 May 2012 16:29:04 -0400
From: Dave Jones <davej@...hat.com>
To: Christoph Lameter <cl@...ux.com>
Cc: Linus Torvalds <torvalds@...ux-foundation.org>,
Linux Kernel <linux-kernel@...r.kernel.org>,
linux-mm@...ck.org,
KOSAKI Motohiro <kosaki.motohiro@...fujitsu.com>,
Stephen Wilson <wilsons@...rt.ca>,
Mel Gorman <mgorman@...e.de>,
Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: 3.4-rc7 numa_policy slab poison.
On Mon, May 21, 2012 at 03:18:38PM -0500, Christoph Lameter wrote:
> On Mon, 21 May 2012, Dave Jones wrote:
>
> > On Mon, May 21, 2012 at 12:39:19PM -0700, Linus Torvalds wrote:
> >
> > > But there's not a lot of recent stuff. The thing that jumps out is Mel
> > > Gorman's recent commit cc9a6c8776615 ("cpuset: mm: reduce large
> > > amounts of memory barrier related damage v3"), which has a whole new
> > > loop with that scary mpol_cond_put() usage. And there's we had
> > > problems with vma merging..
> > >
> > > Dave, how recent is this problem? Have you already tried older kernels?
> >
> > I tried bisecting, but couldn't find a 'good' kernel.
> > I Went back as far as 3.0, before that I kept running into compile failures.
> > Newer gcc/binutils really seems to dislike 2.6.x now.
>
> Well binary distro kernels are available that allow easy testing. Will try
> with what I got here. I have reproduced it with 3.4 so far.
>
> Its always an mput on a freed memory policy. Slub recovery keeps my system
> up at least. I just get the errors dumped to dmesg.
interesting. after it's happened 1-2 times for me, it seems things get really
corrupted, and I start seeing spinlock errors, and soft lockup messages, then hard lockup.
> Is there any way to get the trinity tool to stop when the kernel writes
> errors to dmesg?
hmm, I added a test a while ago to stop when /proc/sys/kernel/tainted changes,
but maybe that broke. I'll take a look. (Of course if you start the tool
after already tainted, it'll ignore it).
> That way I could see the parameters passed to mbind?
It does create log files in the current dir with the parameters used.
You should be able to grep for the pid that caused the actual oops.
Dave
--
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