Re: BUG 2.3.23-pre5 locks up

Alexander Viro (viro@math.psu.edu)
Thu, 21 Oct 1999 15:20:24 -0400 (EDT)


On Thu, 21 Oct 1999, Simon Kirby wrote:

> On Thu, Oct 21, 1999 at 04:39:44AM -0400, Alexander Viro wrote:
>
> > On Thu, 21 Oct 1999, Jeff Garzik wrote:
> >
> > > Jeff Garzik wrote:
> > > > With a fairly standard .config, 2.3.23-pre5 locks up after a few minutes
> > > > of usage.
> > >
> > > Some messages in the log I missed:
> > >
> > > Oct 21 03:27:25 chief kernel: kernel BUG at filemap.c:65!
> > [snip]
> >
> > Impressive. I got something interesting quite near that place - in
> > pagemap.h:102 (inode's page list being nonempty with i_nrpages==0).
> > And it's a UP box - SMP races have nothing with it. -pre4. I'm trying to
> > cactch it right now. _Very_ reproducible - as the matter of fact it hits
> > before the sucker gets to spawning getty. init=/bin/sh is your friend ;-/
>
> Yep, this looks like the exact same BUG() that happened with me as well
> twice on 2.3.23pre4 (pagemap.h:102). SMP box. Both times it happened I
> was compiling a kernel or the ALSA tree (with -j3). It definitely boots
> up and works for a few minutes, though... Hmm. :)

You've got more core - I was testing the sucker with 8Mb. Fit hits the
shan as soon as it tries to swap. It looks like add_page_to_inode_queue
is called with inode->i_pages.next==NULL.

Oh, crap! I got it. Now, who came up with that swapper_inode thing? It's
not initialized, it... arrrgh. OK, quick and dirty fix follows (warning:
it's cut'n'paste, so TABs can be mungled...)
--- swap_state.c.old Wed Oct 20 23:37:57 1999
+++ swap_state.c Thu Oct 21 15:13:21 1999
@@ -50,7 +50,9 @@
NULL /* revalidate */
};

-struct inode swapper_inode = { i_op: &swapper_inode_operations };
+struct inode swapper_inode = {
+i_pages: {&swapper_inode.i_pages,&swapper_inode.i_pages},
+i_op: &swapper_inode_operations };

#ifdef SWAP_CACHE_INFO
unsigned long swap_cache_add_total = 0;
(

Folks, could you check if it fixes the rest of problems? It _is_
the source of pagemap.h:102 one. However, I _don't_ think that it's the
right solution. Leaving the thing in will give us new rounds of the same
stuff in the future... What was the motivation behind this thing?
Al

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