#28 kernel panic - ext2_dirbad

closed-out-of-date
Crash (44)
5
2004-10-05
2004-07-25
will
No

I have a 120 partitioned ext2 drive over firewire which I have a
bunch of mp3's on.. A couple of times recently my machine has
had a panic.. Im wondering if "ext2_dirbad" would perhaps come
from itunes trying to read from a intrestingly named folder? (one
with umlauts or something in there - perhaps??!)

panic(cpu 0): ext2_dirbad: bad dir
Latest stack backtrace for cpu 0:
Backtrace:
0x0008391C 0x00083E00 0x0001EDA4 0x1B31037C
0x1B30FAA4 0x1B318210 0x000BE324 0x000BDD6C
0x000C7AA0 0x00244A94 0x00094400 0x21040100
Kernel loadable modules in backtrace (with dependencies):
net.sourceforge.ext2fs.fs.ext2(1.2.1)@0x1b304000
Proceeding back via exception chain:
Exception state (sv=0x272BFA00)
PC=0x900144CC; MSR=0x0200F030; DAR=0x00636010;
DSISR=0x42000000; LR=0x90288DCC; R1=0xBFFFE1C0;
XCP=0x00000030 (0xC00 - System call)

Kernel version:
Darwin Kernel Version 7.4.0:
Wed May 12 16:58:24 PDT 2004; root:xnu/xnu-517.7.7.obj~7/
RELEASE_PPC

Discussion

  • Logged In: YES
    user_id=595265

    Wade,

    This is likely a very serious filesystem corruption problem. In production
    drivers (which includes the 1.3bx releases), ext2_dirbad is only triggered
    when an internal inconsistency problem is encountered.

    Here are the possibilities:
    1) The directory entry is 0, this should never be the case even if the dir
    is empty (because of . and ..).
    2) The entry we were searching for was found past the EOF of the
    directory.

    Please run fsck_ext2 -fy on the device to make sure there are no
    problems. If you still have the problem, then the only thing I can think of
    would be an bug in the dir index code, but you would have to have dir
    indexes enabled. Do you?

     
    • labels: --> Crash
    • assigned_to: nobody --> bbergstrand
     
  • Logged In: YES
    user_id=595265

    1.3 final (which was just released) will now print the reason ext2_dirbad
    was called. If you get this panic with the new version, please report the
    new panic message.

    Thanks.

     
  • Logged In: YES
    user_id=595265

    More info: according to the panic log, the crash is happening because one
    of the directory entries was zero in length ("mangled enry"). If this
    happens again, before you repair the FS, get me a dump of the directory
    entries. You can do this with debugfs.

    once in debugfs, use 'cd' to get to the bad directory and then 'ls' to list its
    entries:

    # /usr/local/sbin/debugfs <DEVICE>
    debugfs 1.34 (25-Jul-2003)
    debugfs: ls
    2 (12) . 2 (12) .. 11 (1000) lost+found

    Thanks.

     
  • Logged In: YES
    user_id=595265

    Closing after two months of inactivity. No further problem reports from
    submitting user nor others.

     
    • status: open --> closed-out-of-date