On Wed, Mar 17, 1999 at 12:54:40PM +1030, Greg Lehey wrote:
# On Tuesday, 16 March 1999 at 22:41:22 +0300, Mikhail A. Sokolov wrote:
# > Hello,
# > the box is the same as in previous mail of mine which described ufs_dirbad()
# > panics on 4.0-C. Panics are reproducable (run squid 2.1-pl2 with some
# > 30 requests/second).
#
# These two crashes both tend to suggest a file system structure problem
# which fsck doesn't detect. What's the vp in the ffs_truncate frame?
Couldn't help agreeing more ;) See previous answer, though.
# How does it compare to the *vpp in the ufs_lookup frame of the
# previous dump?
Unfortunately, at the moment I have to admit I have been able to afford
keeping the dumps, let's wait the next time. Then again, whilst I am typing
this (below). I tend to be somewhat amazed that the frame 8 is usually the
same for many different panics this box experiences (little summary: this is
probably to be named the most panicing FreeBSD box in the world, 140 panics in
a month, all the hardware has been swapped to the same, but new (i.e. reproduced
the same configuration from spare new parts), panics were either already
announced by other peple, like, Matthew Jacob's reports, or fixed after
many other different reports, like, Matthew Dillon's work brought much more
stability to the beast, no more 'lockmgr: locking against myself' and
'vm_page*' of many kinds. Then again, this box is an experimental and was
brought to 4.0-C to check if it could survive with it, since it couldn't when
it was 3.1-S)
var/crash# gdb -k *3
initial pcb at 21c7b8
panicstr: ffs_valloc: dup alloc
panic messages:
---
panic: ffs_valloc: dup alloc
syncing disks... 147 75 2 done
(da1:ahc1:0:1:0): SYNCHRONIZE CACHE. CDB: 35 0 0 0 0 0 0 0 0 0
(da1:ahc1:0:1:0): ILLEGAL REQUEST asc:20,0
(da1:ahc1:0:1:0): Invalid command operation code
(da2:ahc1:0:2:0): SYNCHRONIZE CACHE. CDB: 35 0 0 0 0 0 0 0 0 0
(da2:ahc1:0:2:0): ILLEGAL REQUEST asc:20,0
(da2:ahc1:0:2:0): Invalid command operation code
(da3:ahc1:0:3:0): SYNCHRONIZE CACHE. CDB: 35 0 0 0 0 0 0 0 0 0
(da3:ahc1:0:3:0): ILLEGAL REQUEST asc:20,0
(da3:ahc1:0:3:0): Invalid command operation code
Btw, Kenneth, I know this is harmless, but didn't Justing's (Gibbs) explicitely
forbid the sync cache to be so verbose or I confuse wanted with the done
things?;)
dumping to dev 20401, offset 821524
dump 256 ...
---
#0 boot (howto=256) at ../../kern/kern_shutdown.c:287
287 dumppcb.pcb_cr3 = rcr3();
(kgdb) where
#0 boot (howto=256) at ../../kern/kern_shutdown.c:287
#1 0xc013b4b9 in panic (fmt=0xc01fdf01 "ffs_valloc: dup alloc")
at ../../kern/kern_shutdown.c:448
#2 0xc01b4e84 in ffs_valloc (pvp=0xce418ac0, mode=33188, cred=0xc1fab580,
vpp=0xce264cd0) at ../../ufs/ffs/ffs_alloc.c:604
#3 0xc01c21cd in ufs_makeinode (mode=33188, dvp=0xce418ac0, vpp=0xce264f14,
cnp=0xce264f28) at ../../ufs/ufs/ufs_vnops.c:2097
#4 0xc01bf9de in ufs_create (ap=0xce264e30) at ../../ufs/ufs/ufs_vnops.c:179
#5 0xc01c23a1 in ufs_vnoperate (ap=0xce264e30)
at ../../ufs/ufs/ufs_vnops.c:2309
#6 0xc01631c7 in vn_open (ndp=0xce264f04, fmode=1550, cmode=420)
at vnode_if.h:83
#7 0xc015fee9 in open (p=0xcce8b860, uap=0xce264f94)
at ../../kern/vfs_syscalls.c:928
#8 0xc01e769f in syscall (frame={tf_es = 47, tf_ds = -1078067153,
tf_edi = 1549, tf_esi = 247619088, tf_ebp = -1078010952,
tf_isp = -836349980, tf_ebx = 134788528, tf_edx = 219774816, tf_ecx = 0,
tf_eax = 5, tf_trapno = 22, tf_err = 2, tf_eip = 672227132, tf_cs = 31,
tf_eflags = 534, tf_esp = -1078010980, tf_ss = 47})
at ../../i386/i386/trap.c:1101
#9 0xc01de9fc in Xint0x80_syscall ()
#10 0x808ae54 in ?? ()
#11 0x808b3c2 in ?? ()
#12 0x8084c1f in ?? ()
#13 0x8067e87 in ?? ()
#14 0x805c06a in ?? ()
#15 0x8071f7f in ?? ()
#16 0x804a1b1 in ?? ()
(kgdb)
#
# Greg
# --
# See complete headers for address, home page and phone numbers
# finger g...@lemis.com for PGP public key
--
-mishania
To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message
