On Thu, Oct 03, 2002 at 04:08:56PM +1000, Keith Owens wrote:
> On Wed, 2 Oct 2002 19:16:23 -1000,
> Sidik Isani <lksi@xxxxxxxxxxxxxxx> wrote:
> > confused by the backtrace. I read about how kdb sometimes displays
> > too many arguments, but some of the valid arguments don't make
> > sense. For example, xlog_do_recovery_pass() seems to be given
> > either a 0 or a 1 for the "pass" argument, but the argument in
> > that position has the value from the previous stack level. Am
> > I not using kdb properly? I've put a more complete minicom dump
> > at this URL: http://software.cfht.hawaii.edu/minicom.cap
>
> >0xf6b59bec 0xc02030ee xlog_do_recovery_pass+0x3e6 (0xf7cbfed4, 0x36c58, 0x0,
> >0x36220, 0x0)
> > kernel .text 0xc0100000 0xc0202d08 0xc0203898
>
> xlog_do_recovery_pass(xlog_t *log,
> xfs_daddr_t head_blk,
> xfs_daddr_t tail_blk,
> int pass)
>
> head_blk and tail_blk are defined as xfs_daddr_t, 64 bit values (long
> long on i386) which occupy two words on stack, with the most
> significant word coming second. kdb has no idea about the parameter
> types, the backtrace prints _words_. That trace shows :-
>
> log = 0xf7cbfed4
> head_blk = [0,0x36c58]
> tail_blk = [0,0x36220]
>
> The default for kdb is to stop after 5 words of parameters, pass is not
> being printed. At the kdb prompt 'set BTARGS 6' then backtrace.
Ok. I've done that, and posted the new backtrace at the URL
http://software.cfht.hawaii.edu/minicom.cap
The latest versions of xfs_logprint crash on this filesystem too
(and others we had created under 2.4.16). Is there anything that
can be done? We're going to reformat this one, because we need
to get it back into service. The output of xfs_logprint, before
it blows up and consumes all the memory, was posted a couple of
weeks ago.
Thanks,
- Sidik
|