Date: Fri, 3 Mar 2006 03:10:11 GMT From: Yarema <yds@CoolRat.org> To: freebsd-bugs@FreeBSD.org Subject: Re: kern/93942: panic: ufs_dirbad: bad dir Message-ID: <200603030310.k233AB94098592@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
The following reply was made to PR kern/93942; it has been noted by GNATS. From: Yarema <yds@CoolRat.org> To: FreeBSD-gnats-submit@freebsd.org, FreeBSD-current@freebsd.org Cc: Kris Kennaway <kris@obsecurity.org>, David Rhodus <drhodus@machdep.com>, Dennis Koegel <amf@hobbit.neveragain.de>, Doug White <dwhite@gumbysoft.com>, Martin Machacek <m@m3a.net>, David O'Brien <obrien@freebsd.org>, Scott Long <scottl@samsco.org>, Pawel Jakub Dawidek <pjd@freebsd.org>, Matthew Dillon <dillon@apollo.backplane.com>, Dmitry Pryanishnikov <dmitry@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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200603030310.k233AB94098592>