Hello -
We still have this filesystem which we created with 2.4.16 that
seems to be unusable under 2.4.19. Newer kernels crash during
log recovery whenever we attempt to mount. I just tried today's
CVS kernel and kdb over the serial port as suggested, but I'm
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
Oh, and I'm using egcs-2.91.66, and frame pointers are turned on.
Thanks for any advice you may have,
- Sidik
Stack traceback for pid 803
EBP EIP Function (args)
0xf770bf14 0xc0200613 xlog_recover_add_to_trans+0xb3 (0xf770bf14, 0xf6af0074,
0x60, 0x0, 0xf6b59bac)
kernel .text 0xc0100000 0xc0200560 0xc02006dc
0xf6b59ae8 0xc0202227 xlog_recover_process_data+0x213 (0xf7cbfed4, 0xf6b59bac,
0xf7715a00, 0xf6af0074, 0x1)
kernel .text 0xc0100000 0xc0202014 0xc0202290
0xc03ccd00 (msstab+0x44ae)
0xc01094ce (nmi+0x1e)
0xc0541220 (async_sercons)
0xc0541220 (async_sercons)
0xf6b59bec 0xc02030ee xlog_do_recovery_pass+0x3e6 (0xf7cbfed4, 0x36c58, 0x0,
0x36220, 0x0)
kernel .text 0xc0100000 0xc0202d08 0xc0203898
0xf6b59c20 0xc02038cb xlog_do_log_recovery+0x33 (0xf7cbfed4, 0x36c58, 0x0,
0x36220, 0x0)
kernel .text 0xc0100000 0xc0203898 0xc0203960
0xf6b59c50 0xc0203982 xlog_do_recover+0x22 (0xf7cbfed4, 0x36c58, 0x0, 0x36220,
0x0)
kernel .text 0xc0100000 0xc0203960 0xc0203b18
0xc038dc40 (extflag.748+0x3878)
0xf6b59ca4 0xc0203bac xlog_recover+0x94 (0xf7cbfed4, 0x1, 0xf786ec00, 0x40000,
0x5f800080)
kernel .text 0xc0100000 0xc0203b18 0xc0203bd8
0xf6b59cc4 0xc01f9907 xfs_log_mount+0xc7 (0xf786ec00, 0x900, 0x5f800080, 0x0,
0x40000)
kernel .text 0xc0100000 0xc01f9840 0xc01f993c
0xc04c6000 (init_task_union)
|