freebsd stable - Mar 2006 - panic: ffs_valloc: dup alloc

I get the above panic after nfs clients attach to this nfs server and 
being read/write ops on it after an unclean shutdown.  I've fsck'ed the 
fs, and it marks it as clean, but I get this every time.  It's an NFS 
share of a GEOM stripe (about 2TB). 

mode = 0100600, inum = 58456203, fs = /mnt
panic: ffs_valloc: dup alloc

I do have dumps from two crashes so far. 

This is FreeBSD-6.1-PRERELEASE from Friday-ish.

What should I do with these vmcores?

(please cc/to me since I am not on -stable list)


Thanks!
Eric



-- 
------------------------------------------------------------------------
Eric Anderson        Sr. Systems Administrator        Centaur Technology
Anything that works is better than anything that doesn't.
------------------------------------------------------------------------

Eric Anderson wrote:
> I get the above panic after nfs clients attach to this nfs server and 
> being read/write ops on it after an unclean shutdown.  I've fsck'ed
the
> fs, and it marks it as clean, but I get this every time.  It's an NFS 
> share of a GEOM stripe (about 2TB).
> mode = 0100600, inum = 58456203, fs = /mnt
> panic: ffs_valloc: dup alloc
Do you happen to have disk mirroring on this server (RAID 1)?  At work, 
on a workstation with RAID 1, we once had a case where after a power 
failure fsck would succeed, but subsequently, when mounting and using 
the partitions, the kernel still paniced because of a corrupt 
filesystem.  Repeatedly.

This caused some major head scratching on our part until we figured out 
what was happening.  The mirrored disks had gone out of sync.  For 
performance reasons, a RAID 1 controller reads data from one disk drive 
or the other, depending on which drive is less busy in that particular 
moment.  So while fsck was able to find and fix some filesystem 
inconsistencies there were still some more left in disk sectors it 
didn't access.

The RAID controller we used turned out to have a verification mode where 
it would scan the disks and re-synchronize them.  Afterwards we did 
another fsck run, and this fixed the remaining filesystem 
inconsistencies.  The kernel panics were gone.

Now, with the information you've provided I can't tell whether these 
findings apply to your case, but perhaps this story helps at least 
others in a similar situation.

    Uwe
-- 
Uwe Doering         |  EscapeBox - Managed On-Demand UNIX Servers
gemini@geminix.org  |  http://www.escapebox.net

Mike Tancsa wrote:
> At 04:48 PM 13/03/2006, Eric Anderson wrote:
>> I get the above panic after nfs clients attach to this nfs server and 
>> being
>> I do have dumps from two crashes so far.
>> This is FreeBSD-6.1-PRERELEASE from Friday-ish.
>
> Dont know if it was fixed or not, but there were a lot of VM changes 
> committed last night that might help.
>
> http://lists.freebsd.org/pipermail/freebsd-stable/2006-March/023526.html
I just updated, and it still happens.  More information for those 
interested:

mode = 0100600, inum = 58456203, fs = /mnt
panic: ffs_valloc: dup alloc


#0  doadump () at pcpu.h:165
165             __asm __volatile("movl %%fs:0,%0" : "=r"
(td));
(kgdb) backtrace
#0  doadump () at pcpu.h:165
#1  0xc064482f in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:399
#2  0xc0644b55 in panic (fmt=0xc0890967 "ffs_valloc: dup alloc") at
/usr/src/sys/kern/kern_shutdown.c:555
#3  0xc077ee3c in ffs_valloc (pvp=0xc8eab440, mode=33152, cred=0xc8a91d80,
vpp=0xe83a5824) at /usr/src/sys/ufs/ffs/ffs_alloc.c:945
#4  0xc07a5933 in ufs_makeinode (mode=33152, dvp=0xc8eab440, vpp=0xe83a5acc,
cnp=0xe83a5ae0) at /usr/src/sys/ufs/ufs/ufs_vnops.c:2165
#5  0xc07a2b0d in ufs_create (ap=0x0) at /usr/src/sys/ufs/ufs/ufs_vnops.c:171
#6  0xc082dc98 in VOP_CREATE_APV (vop=0x0, a=0xe83a5a18) at vnode_if.c:204
#7  0xc0737590 in nfsrv_create (nfsd=0xc8a91d00, slp=0xc8816700, td=0xc7d99780,
mrq=0xe83a5c98) at vnode_if.h:111
#8  0xc0744e95 in nfssvc_nfsd (td=0x0) at
/usr/src/sys/nfsserver/nfs_syscalls.c:472
#9  0xc0744688 in nfssvc (td=0xc7d99780, uap=0xe83a5d04) at
/usr/src/sys/nfsserver/nfs_syscalls.c:181
#10 0xc081cd7f in syscall (frame      {tf_fs = 59, tf_es = 59, tf_ds = 59,
tf_edi = 1, tf_esi = 0, tf_ebp = -1077941448, tf_isp = -398828188, tf_ebx = 4,
tf_edx = 672385208, tf_ecx = 25, tf_eax = 155, tf_trapno = 12, tf_err = 2,
tf_eip = 671840155, tf_cs = 51, tf_eflags = 662, tf_esp = -1077941476, tf_ss =
59}) at /usr/src/sys/i386/i386/trap.c:981
#11 0xc0809e8f in Xint0x80_syscall () at /usr/src/sys/i386/i386/exception.s:200
#12 0x00000033 in ?? ()
Previous frame inner to this frame (corrupt stack?)
(kgdb) 


Maybe that helps somebody?

Should I sent this to -current instead, since it appears this would 
happen under -current also, and possibly there is a larger base of 
people watching the list?

Thanks!
Eric





-- 
------------------------------------------------------------------------
Eric Anderson        Sr. Systems Administrator        Centaur Technology
Anything that works is better than anything that doesn't.
------------------------------------------------------------------------