kern/93942: panic: ufs_dirbad: bad dir
Yarema
yds at CoolRat.org
Thu Mar 2 19:10:12 PST 2006
The following reply was made to PR kern/93942; it has been noted by GNATS.
From: Yarema <yds at CoolRat.org>
To: FreeBSD-gnats-submit at freebsd.org, FreeBSD-current at freebsd.org
Cc: Kris Kennaway <kris at obsecurity.org>,
David Rhodus <drhodus at machdep.com>,
Dennis Koegel <amf at hobbit.neveragain.de>,
Doug White <dwhite at gumbysoft.com>, Martin Machacek <m at m3a.net>,
David O'Brien <obrien at freebsd.org>, Scott Long <scottl at samsco.org>,
Pawel Jakub Dawidek <pjd at freebsd.org>,
Matthew Dillon <dillon at apollo.backplane.com>,
Dmitry Pryanishnikov <dmitry at atlantis.dp.ua>
Subject: Re: kern/93942: panic: ufs_dirbad: bad dir
Date: Thu, 02 Mar 2006 22:04:32 -0500
Update:
Attempting to mount my corrupt /home slice produces the following:
Fatal trap 12: page fault while in kernel mode
cpuid = 0; apic id = 00
fault virtual address = 0xdab2d004
fault code = supervisor read, page not present
instruction pointer = 0x20:0xc06ff7d7
stack pointer = 0x28:0xe9c56514
frame pointer = 0x28:0xe9c56570
code segment = base 0x0, limit 0xfffff, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags = interrupt enabled, resume, IOPL = 0
current process = 73 (mount)
trap number = 12
panic: page fault
cpuid = 0
Uptime 23s
Dumping 1023 MB (2 chunks)
chunk 0: 1MB (159 pages) ... ok
chunk 1: 1023MB (261748 pages) ... ok
However I am able to mount this same corrupt /home partition with the
6.1-BETA2 kernel without error. After tweaking, building and testing my
custom KERNCONF the problem seems to be with:
options UFS_EXTATTR
options UFS_EXTATTR_AUTOSTART
which according to the src/sys/ufs/ufs/README.* should only effect UFS1. I
only use UFS2, so technically I do not need these options.
To sum up: my computer became unresponsive. Reboot and fsck produced a
"panic: ufs_dirbad: bad dir". Many fsck -f runs later 'mount -r /home'
started causing the "Fatal trap 12: page fault while in kernel mode" panic.
Booting a kernel without options UFS_EXTATTR & UFS_EXTATTR_AUTOSTART does
not cause this mount proc kernel panic. I have a vmcore dump if anyone
cares to look at it.
Question: Why does fsck mark a UFS2 clean, but a kernel with options
UFS_EXTATTR & UFS_EXTATTR_AUTOSTART still cause a kernel panic on that one
UFS2 but none of the other UFS2 slices?
Regarding the src/sys/kern/vfs_cluster.c patch. All of the testing
described above was performed with the patch applied. But the initial
corruption occurred before the patch. It would be nice if someone who
understands that code looked at it, blessed it and got it committed. We
will only find out if the patch indeed fixes the ufs_dirbad problem if all
those who've been bitten by this bug no longer run into this sort of
corruption over time.
--
Yarema
More information about the freebsd-bugs
mailing list