Re: [PANIC] ffs_alloccg: map corrupted (w/SU+J)

On Sat, Mar 05, 2011 at 03:33:01PM -0800, David O'Brien wrote:
> Feb 24 19:43:16 : FreeBSD 9.0-CURRENT #662 r218815:218845M: Tue Feb 22 00:13:31 PST 2011
> Feb 24 19:43:16 : /sys/i386/compile/DRAGON i386
> [..]
> Mar  5 14:41:38 : start = 0, len = 1659, fs = /storage
> Mar  5 14:41:38 : panic: ffs_alloccg: map corrupted
> Mar  5 14:41:38 : cpuid = 0
> Mar  5 14:41:38 : KDB: stack backtrace:
> Mar  5 14:41:38 : db_trace_self_wrapper(c084242b,65676172,a0d,4,0,...) at 0xc04ebf46 = db_trace_self_wrapper+0x26
> Mar  5 14:41:38 : kdb_backtrace(c0860edc,0,c085531a,eaf4870c,0,...) at 0xc05ff87a = kdb_backtrace+0x2a
> Mar  5 14:41:38 : panic(c085531a,0,67b,c65230d4,e000c000,...) at 0xc05d1d67 = panic+0x117
> Mar  5 14:41:38 : ffs_mapsearch(4462ea0,0,8,0,0,...) at 0xc0759163 = ffs_mapsearch+0x153
> Mar  5 14:41:38 : ffs_alloccgblk(4462ea0,0,4000,5ae,0,...) at 0xc075935c = ffs_alloccgblk+0xec
> Mar  5 14:41:38 : ffs_alloccg(c99c29f8,2fa,4462ea0,0,4000,...) at 0xc0759c83 = ffs_alloccg+0x1b3
> Mar  5 14:41:38 : ffs_hashalloc(4462ea0,0,4000,4000,c0759ad0,...) at 0xc0756321 = ffs_hashalloc+0x41
> Mar  5 14:41:38 : ffs_alloc(c99c29f8,100e,0,4462ea0,0,...) at 0xc075acff = ffs_alloc+0x19f
> Mar  5 14:41:38 : ffs_balloc_ufs2(ca740110,4038000,0,4000,c8bc7400,...) at 0xc075cff9 = ffs_balloc_ufs2+0x1949
> Mar  5 14:41:38 : ffs_write(eaf48b90,eaf48b4c,eaf48b10,c0780ac2,ca740168,...) at 0xc077fc66 = ffs_write+0x276
> Mar  5 14:41:38 : VOP_WRITE_APV(c08bb080,eaf48b90,ca740110,264,0,...) at 0xc08036e4 = VOP_WRITE_APV+0xe4
> Mar  5 14:41:38 : vn_write(c7cfcc78,eaf48c24,c8bc7400,0,cddd05c0,...) at 0xc0663ad3 = vn_write+0x1c3
> Mar  5 14:41:38 : dofilewrite(eaf48c24,ffffffff,ffffffff,0,c7cfcc78,...) at 0xc060fe55 = dofilewrite+0x95
> Mar  5 14:41:38 : kern_writev(cddd05c0,4,eaf48c24,eaf48c44,1,...) at 0xc06100e8 = kern_writev+0x58
> Mar  5 14:41:38 : write(cddd05c0,eaf48cec,cddd05c0,eaf48d28,4,...) at 0xc061016f = write+0x4f
> Mar  5 14:41:38 : syscallenter(cddd05c0,eaf48ce4,eaf48ce4,0,3,...) at 0xc060b363 = syscallenter+0x2c3
> Mar  5 14:41:38 : syscall(eaf48d28) at 0xc07e3114 = syscall+0x34
> Mar  5 14:41:38 : Xint0x80_syscall() at 0xc07cf121 = Xint0x80_syscall+0x21
> Mar  5 14:41:38 : --- syscall (4, FreeBSD ELF32, write), eip = 0x2818c60b, esp = 0xbfbfe86c, ebp = 0xbfbfe8d8 ---
> 
> 
> Changes since my last reported SU+J panic:
> 1. Newer revision of ahd(4) ASIC
> 2. New U320 SCA enclosures (different vendor + model).
> 3. New motherboard
> 
> -- 
> -- David  (obrien_at_FreeBSD.org)
> 
> P.S. I am using this UFS patch:
Both changes you are using were superseded by proper fixes committed
into HEAD for some time.

For me, this indeed sounds as disk corruption. Could you somehow verify
that the disks read the data that was written to ? E.g, putting
some iso image with known sha checksum onto the disk with dd, and then
reading that part and checksumming it ?