Date: Tue, 5 Dec 2006 08:48:30 +0100 (CET)
From: Jiri Kosina <jikos@jikos.cz>
To: Neil Brown <neilb@suse.de>
cc: Andrew Morton <akpm@osdl.org>, linux-kernel@vger.kernel.org
Subject: Re: 2.6.19-rc6-mm2
In-Reply-To: <17780.61551.896455.157225@cse.unsw.edu.au>
Message-ID: <Pine.LNX.4.64.0612050844110.28502@twin.jikos.cz>
References: <20061128020246.47e481eb.akpm@osdl.org>
 <Pine.LNX.4.64.0611290147400.28502@twin.jikos.cz> <17780.52337.767875.963882@cse.unsw.edu.au>
 <17780.61551.896455.157225@cse.unsw.edu.au>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1354
Lines: 29

On Tue, 5 Dec 2006, Neil Brown wrote:

> As Andrew correctly pointed out, this bit error is not a RAM problem. It 
> is actually the low bit of a counter a spinlock that was decremented 
> just before the WARN_ON.  So it simply indicates that the inode had 
> already been freed, which I think we knew already. Unfortunately I still 
> have no idea why that inode had been freed but was still referenced by a 
> dentry.... How repeatable as this bug?  How did you narrow it down to 
> that patch? Did you use git-bisect or something else?

When this happened, I just looked at the broken-out patches in -mm, which 
ones touch the md subsystem, found your patch, reverse-applied it, and 
this stopped happening.

It seemed to be 100% reproducible - happened on every boot of FC6 system, 
so it was probably triggered by some raid/lvm command executed from init 
scripts after boot, but I didn't examine it further.

As soon as I get to the machine where this happens, I will try to narrow 
it down to the exact userspace command that triggers it and will let you 
know (probably this evening).

-- 
Jiri Kosina
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/