Re: Boot failure with ext2 and initrds

[Hugh Dickins <hugh@veritas.com>]

On Thu, 16 Nov 2006, Andrew Morton wrote:
> On Thu, 16 Nov 2006 12:15:16 -0800
> Mingming Cao <cmm@us.ibm.com> wrote:
> > On Thu, 2006-11-16 at 01:13 -0800, Andrew Morton wrote:
> > > 
> > > I assume that the while (1) loop in ext3_try_to_allocate_with_rsv() has
> > > gone infinite.  I don't see why, but more staring is needed.
> > 
> > The loop should not go forever, it will stops when there is no window
> > with free bit to reserve in the given block group.
> 
> It seems to have done so in Hugh's testing, but there's some question there
> now.  Although I didn't check to see if there's a significant difference
> between Hugh's patch and mine.

After four days of running, the EM64T has at last reproduced the same
hang as it did in an hour before: stuck in ext2_try_to_allocate_with_rsv,
repeatedly ext2_rsv_window_add, ext2_try_to_allocate, rsv_window_remove
(perhaps not in that order).

But somehow I've screwed up, and before I'd extracted any new info,
kdb was spinning on its own kdb_printf_lock, and then the box completely
frozen: nothing for it but to reboot.

Grrrr.

Well: at least this resolves the doubt I raised earlier, whether
I'd been testing with the right ext2 patch.  This time was definitely
with your patch not my two-liner: your original patch from Tuesday 14 Nov,
ext2-reservations-bring-ext2-reservations-code-in-line-with-latest-ext3-fix

Various other patches have come into -mm (one gone) since then, but I've
been running just with that: so far as I can see, none of the later ones
should be important in my case - the filesystem is too small for the
difference between int and ext2_fsblk_t to become important, and
neither "ld" nor "as" (the writer this time) does MAP_SHARED pageout.

I'll do a little staring at the code myself: I'm unlikely to notice
anything you've missed, but there's just a chance staring at it will
direct me to some detail I've jotted down from before.

Hugh
-
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/