xfs
[Top] [All Lists]

Re: Timing critical portions of XFS at startup?

To: ian.nelson@xxxxxxxxxxxx
Subject: Re: Timing critical portions of XFS at startup?
From: Steve Lord <lord@xxxxxxx>
Date: 30 Nov 2001 13:24:50 -0600
Cc: Eric Sandeen <sandeen@xxxxxxx>, "linux-xfs@xxxxxxxxxxx" <linux-xfs@xxxxxxxxxxx>
In-reply-to: <3C07D542.E13EB0EF@echostar.com>
References: <3C07BDD9.B71E5600@echostar.com> <1007140779.16790.11.camel@stout.americas.sgi.com> <3C07C251.273312EB@echostar.com> <3C07D2D5.65A78599@echostar.com> <1007145351.4099.13.camel@jen.americas.sgi.com> <3C07D542.E13EB0EF@echostar.com>
Sender: owner-linux-xfs@xxxxxxxxxxx
On Fri, 2001-11-30 at 12:51, Ian S. Nelson wrote:
> That's what I gather.  I disassembled the kernel and it's blowing up when it
> dereferences *tp in xfs_trans_count_vecs on line 4 of the function.     I 
> have 32MB
> of RAM in the box.  Is this a kernel memory allocation failure?  There aren't
> really any user mode apps running.

OK, I think I want to withdraw the memory allocation failure diagnosis,
xfs_trans_count_vecs does not look at anything which has not been 
referenced a lot prior to this. You state that it dies the first
time it dereferences tp, which would actually be in this code:

STATIC uint
xfs_trans_count_vecs(
        xfs_trans_t     *tp)
{
        int                     nvecs;
        xfs_log_item_desc_t     *lidp;

        nvecs = 1;
        lidp = xfs_trans_first_item(tp);
                ^^^^^^^^^^^^^^^^^^^^^^^

        ASSERT(lidp != NULL);

This is starting to sound a lot more like a memory corruption than an
allocation failure. 32M should be ample unless you are doing a lot of
I/O in parallel.

Can you decode the oops output - I doubt it will tell us much, but it
may help.

Steve


> 
> thanks,
> Ian
> 
> Steve Lord wrote:
> 
> > On Fri, 2001-11-30 at 12:41, Ian S. Nelson wrote:
> > > Unable to handle kernel NULL pointer dereference at virtual address 
> > > 0000000d
> > >  printing eip:
> > > c019d8ff
> > > *pde = 00000000
> > > Oops: 0000
> > > CPU:    0
> > > EIP:    0010:[<c019d8ff>]
> > > EFLAGS: 00010246
> > > eax: 0000000d   ebx: c10a8c00   ecx: c11a5060   edx: 00000000
> > > esi: c10a8c00   edi: c11a51a0   ebp: 00000000   esp: c10b7c24
> > > ds: 0018   es: 0018   ss: 0018
> > > Process init (pid: 1, stackpage=c10b7000)
> > > Stack: c10a8c00 c10a8c00 c11a51a0 c019d722 c11a5060 00000002 c10b7d6c 
> > > c11a51a0
> > >
> > >        c11a2060 00000070 ffffffff ffffffff 00000000 c027e33c c10a8c00 
> > > c01272f0
> > >
> > >        00000000 c012758a 00000246 c10bf82c 00000070 00000001 c10bf82c 
> > > 00000001
> > >
> > > Call Trace: [<c019d722>] [<c01272f0>] [<c012758a>] [<c012465d>] 
> > > [<c01b3c2c>]
> > > [<c01b3c2c>] [<c019cdc7>]
> > >        [<c0163ad4>] [<c018b592>] [<c01a2605>] [<c01a1b3c>] [<c0188e9e>]
> > > [<c01a189c>] [<c01ae04e>] [<c01a1b3c>]
> > >        [<c013fdd5>] [<c012a739>] [<c0137034>] [<c012b58c>] [<c012b88c>]
> > > [<c0106d93>]
> > >
> > > Code: 8b 00 26 10 57 be 01 00 00 00 e8 42 17 00 00 89 c3 83 c4 04
> > > Kernel panic: Attempted to kill init!
> > >
> > > This one appears to hang up in xfs_trans_count_vecs.
> > >
> >
> > You are almost certainly running out of memory - time to start looking
> > for things to prune out of your kernel/user space. How much memory do
> > you have, 12M is the smallest system I remember getting very far with
> > XFS.
> >
> > Steve
> >
> > --
> >
> > Steve Lord                                      voice: +1-651-683-3511
> > Principal Engineer, Filesystem Software         email: lord@xxxxxxx
-- 

Steve Lord                                      voice: +1-651-683-3511
Principal Engineer, Filesystem Software         email: lord@xxxxxxx


<Prev in Thread] Current Thread [Next in Thread>