Bug #2340
closed
UFS panic when running fsstress
Added by swildner about 12 years ago.
Updated about 12 years ago.
Description
Around 20s into fsstress (run like in test/stress/fsstress/dotest.sample), I hit the following UFS panic:
#12 0xc0378242 in panic (fmt=0xc069e38f "sysctl_debug_panic") at /usr/src/sys/kern/kern_shutdown.c:822
#13 0xc018de95 in sysctl_debug_panic (oidp=0xc0731560, arg1=0x0, arg2=0, req=0xd9645bf4) at /usr/src/sys/ddb/db_sysctl.c:92
#14 0xc0390309 in sysctl_root (oidp=<optimized out>, arg1=0xd9645c7c, arg2=<optimized out>, req=0xd9645bf4) at /usr/src/sys/kern/kern_sysctl.c:1202
#15 0xc0390445 in userland_sysctl (name=0xd9645c7c, namelen=2, old=0x0, oldlenp=0x0, inkernel=0, new=0xbfbff738, newlen=4, retval=0xd9645c78) at /usr/src/sys/kern/kern_sysctl.c:1284
#16 0xc039071f in sys___sysctl (uap=0xd9645cf0) at /usr/src/sys/kern/kern_sysctl.c:1224
#17 0xc064b26c in syscall2 (frame=0xd9645d40) at /usr/src/sys/platform/pc32/i386/trap.c:1324
#18 0xc06232e6 in Xint0x80_syscall () at /usr/src/sys/platform/pc32/i386/exception.s:878
It is an i386 system running v3.1.0.399.g590ba-DEVELOPMENT.
Crash dump is in ~swildner/crash/ on leaf (kern.15 and vmcore.15).
Sorry, the backtrace was a mis-paste. Here's the real trace:
#10 0xc05bc022 in trap (frame=0xda71fb74) at /home/s/projects/dragonfly/src/sys/platform/pc32/i386/trap.c:714
#11 0xc058bbc7 in calltrap () at /home/s/projects/dragonfly/src/sys/platform/pc32/i386/exception.s:787
#12 0xc04a04c5 in ffs_sync_scan1 (mp=0xd4a6b1e0, vp=0xdaa7def8, data=0xda71fc1c) at /home/s/projects/dragonfly/src/sys/vfs/ufs/ffs_vfsops.c:1034
#13 0xc0363281 in vmntvnodescan (mp=0xd4a6b1e0, flags=<optimized out>, fastfunc=0xc04a04b0 <ffs_sync_scan1>, slowfunc=0xc04a09ac <ffs_sync_scan2>, data=0xda71fc1c) at /home/s/projects/dragonfly/src/sys/kern/vfs_mount.c:1078
#14 0xc04a0921 in ffs_sync (mp=0xd4a6b1e0, waitfor=6) at /home/s/projects/dragonfly/src/sys/vfs/ufs/ffs_vfsops.c:993
#15 0xc0371005 in vfs_sync (mp=0xd4a6b1e0, waitfor=6) at /home/s/projects/dragonfly/src/sys/kern/vfs_vfsops.c:212
#16 0xc036bff7 in sync_callback (mp=0xd4a6b1e0, data=0x0) at /home/s/projects/dragonfly/src/sys/kern/vfs_syscalls.c:896
#17 0xc0363969 in mountlist_scan (callback=0xc036bfb5 <sync_callback>, data=0x0, how=<optimized out>) at /home/s/projects/dragonfly/src/sys/kern/vfs_mount.c:924
#18 0xc036bb00 in sys_sync (uap=0xda71fcf0) at /home/s/projects/dragonfly/src/sys/kern/vfs_syscalls.c:875
#19 0xc05bc72e in syscall2 (frame=0xda71fd40) at /home/s/projects/dragonfly/src/sys/platform/pc32/i386/trap.c:1328
#20 0xc058bc76 in Xint0x80_syscall () at /home/s/projects/dragonfly/src/sys/platform/pc32/i386/exception.s:878
The rest of the info was correct:
It is an i386 system running v3.1.0.399.g590ba-DEVELOPMENT.
Crash dump is in ~swildner/crash/ on leaf (kern.15 and vmcore.15).
I believe commit 609f61878d1378c3d04602cf1e581a6f57dfae47 fixes this particular panic. Details in the commit message.
There are more panics in ffs when running fsstress; issues will be raised for each.
- Status changed from New to Resolved
Also available in: Atom
PDF
Updated by 
Updated by