freebsd stable - Nov 2005 - RELENG_6 vm_fault panic on filesystem mount

Skipped content of type multipart/mixed-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url :
http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20051118/16d85802/attachment.bin

Hi, Joerg,

On 11/19/05, Joerg Pernfuss <elessar@bsdforen.de> wrote:
[...]
> From the output of the backtrace (below) I figure the problem for me
> lies in /usr/src/sys/ufs/ufs/ufs_dirhash.c line 232; this block:
>
>      if (ep->d_reclen == 0 || ep->d_reclen >
>          DIRBLKSIZ - (pos & (DIRBLKSIZ - 1))) {
>              /* Corrupted directory. */
>              brelse(bp);
>              goto fail;
>      }
>
> Which is consistent with the very first panic message I got saying
> something about 'Fatal Trap 12, page fault while in kernel mode,
>  ufs_dirhash: bad dir' - sadly, I didn't write down that one.
> Hasn't reappeared since then.
Unfortunately the "ufs_dirhash: bad dir" in most cases indicate some
bugs elsewhere, or some hardware hazard.  I have recently upgraded
several production boxes at lab and suggested many other guys to
upgrade to 6.0-RELEASE, and I am very eager to see if there is some
problems that we can catch and fix.

If this is a production then my suggestion would be trying to remove
something that you do not need for everyday use from the kernel
configuration, and if it is not then my suggestion would be enabling
INVARIANTS and makeoptions=-g to see if something strange happen, and
possibly some backtraces would inspire us to catch the bug.

Thanks,
--
Xin LI <delphij@delphij.net> http://www.delphij.net

On Fri, 18 Nov 2005, Joerg Pernfuss wrote:
> #6  0xc078806a in calltrap () at /usr/src/sys/i386/i386/exception.s:139
> #7  0xc070c00c in ufsdirhash_build (ip=0xc5426948) at
/usr/src/sys/ufs/ufs/ufs_dirhash.c:232
> #8  0xc070f5c3 in ufs_lookup (ap=0xeabb6824) at
/usr/src/sys/ufs/ufs/ufs_lookup.c:192
> #9  0xc070d8f4 in ufs_extattr_lookup (start_dvp=0xc5414dd0, lockparent=0x2,
dirname=0xd71f3000 "\002", vp=0xd71f3000, td=0xc5558780) at
/usr/src/sys/
> ufs/ufs/ufs_extattr.c:274
> #10 0xc070dfd6 in ufs_extattr_autostart (mp=0xc4ca3000, td=0xc5558780) at
/usr/src/sys/ufs/ufs/ufs_extattr.c:463
> #11 0xc0706fa6 in ffs_mount (mp=0xc4ca3000, td=0xc5558780) at
/usr/src/sys/ufs/ffs/ffs_vfsops.c:779
> #12 0xc0640d57 in vfs_donmount (td=0xc5558780, fsflags=0x8008,
fsoptions=0xeabb6bf4) at /usr/src/sys/kern/vfs_mount.c:739
> #13 0xc06427c0 in kernel_mount (ma=0xc5235240, flags=0x0) at pcpu.h:162
The UFS1 extended attribute code performs directory listings, lookups, and 
file operations very early in the "life cycle" of a UFS file system in
order to identify attribute backing files.  We could be looking at a bug 
or new negative interaction between the extended attribute code in UFS1, 
dirhash, and the changes to VFS required to get SMP VFS support in 6.x. 
In principle, however, the EA code waits until everything is "ready to
go"
before starting on file system I/O.  Are you actively using UFS1 
attributes on that file system?  Could I ask you to boot to single user 
mode, try mounting the file system, then try compiling a kernel without 
UFS_EXTATTR and UFS_EXTATTR_AUTOSTART, boot to single user mode, and see 
if you can mount the file system successfully?  I.e., compare mounting 
with and without extended attributes, but on a "quiet" file system so
any
existing extended attributes remain in sync.

Robert N M Watson