On Fri, Sep 15, 2006 at 10:06:48AM +0200, Michal Piotrowski wrote:
> On 15/09/06, David Chinner <dgc@xxxxxxx> wrote:
> >On Thu, Sep 14, 2006 at 08:48:01PM -0700, Andrew Morton wrote:
> >> "BAD" is a bisection point, as per
> >> http://www.zip.com.au/~akpm/linux/patches/stuff/bisecting-mm-trees.txt.
> >So
> >> just 2.6.18-rc6+origin.patch exhibits the failure. That is mainline.
> >
> >Ah - thanks for explaining that for me, Andrew.
> >
> >Michal, there were several XFS fixes (4, I think) that went into -rc7. If
> >-rc6 fails and -rc7 doesn't then we need to check if one of those fixes is
> >responsible.
>
> As I said before "I was wrong" (I use lockdep only with -mm kernels).
>
> >The crash doesn't match any of the symptoms we've seen from them,
> >but it's worth checking.
>
> http://www.ussg.iu.edu/hypermail/linux/kernel/0608.1/1202.html
>
> The problem with this bug is "bad interaction" between lockdep and
> XFS. (I forgot about this probably because lockdep was broken for me
> in 2.6.18-rc5-mm* - and previous bug appeared while mounting XFS, not
> umounting).
According to the above link, unmount was the problem as well.
I know little about lockdep, but if this really is the superblock
lock that we are oopsing on then I cannot see how XFS is involved
at all seeing as it does not ever touch the superblock lock.
I'd say the first step is to get a lockdep expert to explain why
we are oopsing here....
> 2006-07-03 locdep was merged
> 2006-07-28 - 2006-08-10 a few XFS fixes
>
> So I guess that binary search won't solve this mystery.
Don't use lockdep with XFS yet. XFS hasn't been instrumented
with lockdep notations, so nothing good will come from using
it right now. There is work in progress to fix this, but it's not
ready yet.
Cheers,
Dave.
--
Dave Chinner
Principal Engineer
SGI Australian Software Group
|