Date: Fri, 16 Sep 2005 01:17:50 -0700 (PDT) From: Don Lewis <truckman@FreeBSD.org> To: dgerow@afflictions.org Cc: freebsd-stable@FreeBSD.org Subject: Re: NFS directory copies cause crash Message-ID: <200509160817.j8G8Ho58062224@gw.catspoiler.org> In-Reply-To: <20050916035838.GA32336@afflictions.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 15 Sep, Damian Gerow wrote:
> Thus spake Kris Kennaway (kris@obsecurity.org) [15/09/05 21:39]:
> : > Is this something known and being worked on, or should I try to gather some
> : > debugging information?
> :
> : The latter..at least a DDB traceback to begin with so we can tell if
> : it's a known issue or not.
>
> This is what I've got:
>
> Fatal trap 18: integer divide fault while in kernel mode
> instruction pointer = 0x8:0xc063c94d
> stack pointer = 0x10:0xd40166e4
> frame pointer = 0x10:0xd4016720
> 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 = 11639 (nfsd)
> trap number = 18
> panic: integer divide fault
>
> And the backtrace:
>
> #0 doadump () at pcpu.h:160
> #1 0xc051c647 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:412
> #2 0xc051c989 in panic (fmt=0xc06e3166 "%s") at /usr/src/sys/kern/kern_shutdown.c:568
> #3 0xc06c2d0c in trap_fatal (frame=0xd40166a4, eva=0) at /usr/src/sys/i386/i386/trap.c:817
> #4 0xc06c2722 in trap (frame=
> {tf_fs = 24, tf_es = 16, tf_ds = 16, tf_edi = -1048248320, tf_esi = 0, tf_ebp = -738105568, tf_isp = -738105648, tf_ebx = 0, tf_edx = 0, tf_ecx = 0, tf_eax = 183205888, tf_trapno = 18, tf_err = 0, tf_eip = -1067202227, tf_cs = 8, tf_eflags = 66182, tf_esp = 38, tf_ss = 0}) at /usr/src/sys/i386/i386/trap.c:622
> #5 0xc06afefa in calltrap () at /usr/src/sys/i386/i386/exception.s:140
> #6 0x00000018 in ?? ()
> #7 0x00000010 in ?? ()
> #8 0x00000010 in ?? ()
> #9 0xc1850000 in ?? ()
> #10 0x00000000 in ?? ()
> #11 0xd4016720 in ?? ()
> #12 0xd40166d0 in ?? ()
> #13 0x00000000 in ?? ()
> #14 0x00000000 in ?? ()
> #15 0x00000000 in ?? ()
> #16 0x0aeb8000 in ?? ()
> #17 0x00000012 in ?? ()
> #18 0x00000000 in ?? ()
> #19 0xc063c94d in ffs_dirpref (pip=0xc1b193d4) at libkern.h:56
> #20 0xc063c42a in ffs_valloc (pvp=0xc1e38d68, mode=16877, cred=0xc1e08d80, vpp=0xd40167a0) at /usr/src/sys/ufs/ffs/ffs_alloc.c:863
> #21 0xc0669866 in ufs_mkdir (ap=0xd40169fc) at /usr/src/sys/ufs/ufs/ufs_vnops.c:1381
> #22 0xc066bc08 in ufs_vnoperate (ap=0x0) at /usr/src/sys/ufs/ufs/ufs_vnops.c:2827
> #23 0xc062c05e in nfsrv_mkdir (nfsd=0xc1e08d00, slp=0x0, td=0xc1580600, mrq=0xd4016c7c) at vnode_if.h:772
> #24 0xc0637225 in nfssvc_nfsd (td=0x0) at /usr/src/sys/nfsserver/nfs_syscalls.c:471
> #25 0xc0636852 in nfssvc (td=0xc1580600, uap=0xd4016d04) at /usr/src/sys/nfsserver/nfs_syscalls.c:181
> #26 0xc06c30c0 in syscall (frame=
> {tf_fs = 47, tf_es = 47, tf_ds = 47, tf_edi = 0, tf_esi = 0, tf_ebp = -1077941448, tf_isp = -738103964, tf_ebx = 0, tf_edx = -1077936144, tf_ecx = 2, tf_eax = 155, tf_trapno = 12, tf_err = 2, tf_eip = 671953119, tf_cs = 31, tf_eflags = 582, tf_esp = -1077941476, tf_ss = 47}) at /usr/src/sys/i386/i386/trap.c:1009
> #27 0xc06aff4f in Xint0x80_syscall () at /usr/src/sys/i386/i386/exception.s:201
> #28 0x0000002f in ?? ()
> #29 0x0000002f in ?? ()
> #30 0x0000002f in ?? ()
> #31 0x00000000 in ?? ()
> #32 0x00000000 in ?? ()
> #33 0xbfbfeb38 in ?? ()
> #34 0xd4016d64 in ?? ()
> #35 0x00000000 in ?? ()
> #36 0xbfbffff0 in ?? ()
> #37 0x00000002 in ?? ()
> #38 0x0000009b in ?? ()
> #39 0x0000000c in ?? ()
> #40 0x00000002 in ?? ()
> #41 0x280d30df in ?? ()
> #42 0x0000001f in ?? ()
> #43 0x00000246 in ?? ()
> #44 0xbfbfeb1c in ?? ()
> #45 0x0000002f in ?? ()
> #46 0x00000000 in ?? ()
> #47 0x00000000 in ?? ()
> #48 0x00000000 in ?? ()
> #49 0x00000000 in ?? ()
> #50 0x1f481000 in ?? ()
> #51 0xc15c5c5c in ?? ()
> #52 0xc1580600 in ?? ()
> #53 0xd4016b90 in ?? ()
> #54 0xd4016b74 in ?? ()
> #55 0xc1578300 in ?? ()
> #56 0xc052ff10 in sched_switch (td=0x0, newtd=0x0, flags=Cannot access memory at address 0xbfbfeb48
> ) at /usr/src/sys/kern/sched_4bsd.c:881
> Previous frame inner to this frame (corrupt stack?)
See PR kern/41723: [2TB] on 1TB fs, copying files to filesystem causes "integer divide fault" and panic.
Just doing a mkdir should be sufficient to trigger the panic.
The panic is enabled if the ufs file system avgfilesize and/or avgfpdir
parameters are set too high. If the product of these two values
overflows a (signed?) 32 bit number, then boom! It doesn't make any
sense to set avgfilesize (units are bytes) larger than the file system
maxbpg (units are blocks), because only the first maxbgp blocks of each
file are allocated from the file's home cylinder group. It also doesn't
make sense to set the product of avgfilesize and avgfpdir larger than
the file system cylinder group size because that means the average
directory will overflow a cylinder group, so no more than one directory
should be allocated per cylinder group.
As a workaround, use tunefs to adjust the file system avgfilesize and/or
avgfpdir paramaters.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200509160817.j8G8Ho58062224>