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

2011-03-06 Thread Kostik Belousov
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,,,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  (obr...@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 ?


pgprYtAFSWDPc.pgp
Description: PGP signature


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

2011-03-05 Thread David O'Brien
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,,,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  (obr...@freebsd.org)

P.S. I am using this UFS patch:

Index: ufs/ffs/ffs_softdep.c
===
--- ufs/ffs/ffs_softdep.c   (revision 218815)
+++ ufs/ffs/ffs_softdep.c   (working copy)
@@ -6068,6 +6068,7 @@ indir_trunc(freework, dbn, lbn)
struct jnewblk *jnewblk;
struct freeblks *freeblks;
struct buf *bp;
+   struct bufobj *bo;
struct fs *fs;
struct worklist *wkn;
struct worklist *wk;
@@ -6106,14 +6107,13 @@ indir_trunc(freework, dbn, lbn)
 * a complete copy of the indirect block in memory for our use.
 * Otherwise we have to read the blocks in from the disk.
 */
-#ifdef notyet
-   bp = getblk(freeblks->fb_devvp, dbn, (int)fs->fs_bsize, 0, 0,
-   GB_NOCREAT);
-#else
-   bp = incore(&freeblks->fb_devvp->v_bufobj, dbn);
-#endif
+   bo = &freeblks->fb_devvp->v_bufobj;
+check_incore:
ACQUIRE_LOCK(&lk);
+   BO_LOCK(bo);
+   bp = gbincore(bo, dbn);
if (bp != NULL && (wk = LIST_FIRST(&bp->b_dep)) != NULL) {
+   BO_UNLOCK(bo);
if (wk->wk_type != D_INDIRDEP ||
(wk->wk_state & GOINGAWAY) == 0)
panic("indir_trunc: lost indirdep %p", wk);
@@ -6126,15 +6126,34 @@ indir_trunc(freework, dbn, lbn)
ump->um_numindirdeps -= 1;
FREE_LOCK(&lk);
} else {
-#ifdef notyet
-   if (bp)
-   brelse(bp);
-#endif
FREE_LOCK(&lk);
-   if (bread(freeblks->fb_devvp, dbn, (int)fs->fs_bsize,
-   NOCRED, &bp) != 0) {
-   brelse(bp);
-   return;
+   if (bp != NULL) {
+   if (BUF_LOCK(bp, LK_EXCLUSIVE | LK_NOWAIT |
+   LK_INTERLOCK, BO_MTX(bo)) != 0) {
+   pause("INDIRT", 1);
+   goto check_incore;
+   }
+   } else {
+   BO_UNLOCK(bo);
+   bp = getblk(freeblks->fb_devvp, dbn, fs->fs_bsize, 0,
+   0, 0);
+   if (LIST_FIRST(&bp->b_dep) != NULL) {
+   brelse(bp);
+   goto check_incore;
+   }
+   }
+
+   if ((bp->b_flags & B_CACHE) == 0) {
+   bp->b

Re: [PANIC] ffs_alloccg: map corrupted

2010-12-15 Thread Garrett Cooper
On Wed, Dec 15, 2010 at 7:29 PM, David O'Brien  wrote:
> On Thu, Dec 02, 2010 at 03:31:41PM -0800, Garrett Cooper wrote:
>> On Thu, Dec 2, 2010 at 2:43 PM, David O'Brien  wrote:
>> > Thoughts?
>> >
>> > FreeBSD 9.0-CURRENT #654 r215604M: Sat Nov 20 19:51:27 PST 2010
>> >    ro...@dragon:/sys/i386/compile/DRAGON i386
>> > [..]
>> > start = 0, len = 3359, fs = /files
>> > panic: ffs_alloccg: map corrupted
> [..]
>> > ffs_balloc_ufs2(ce55e660,38000,0,4000,ce77b300,...) at 0xc0755629 = 
>> > ffs_balloc_ufs2+0x1949
> [..]
>> > panic: bufwrite: buffer is not busy???
>>
>>     UFS? UFS2? SU? SU+J? Got more details :)?
>
> UFS2, SU+J, ahd(4) HBA

Hmmm.. interesting. Was a cylinder block corrupted by an fsck and
the map not updated (properly) to reflect the change? I haven't seen
this particular issue before, but then again I stick to mfi(4)
controllers for RAIDs and standalone ahci(4) drives.
Thanks,
-Garrett
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Re: [PANIC] ffs_alloccg: map corrupted

2010-12-15 Thread Buganini
I've see many times that SUJ doesnt really make fs clean,
then some problem in fs leads to panics.
And sometimes I boot into single user mode after crash (caused by
other things, eg. page fault), then
fsck_ffs -y ; use SUJ and marked clean, and again:
fsck_ffs -fy ; should not fix anything more, but actually it does
report fixing something


On Thu, Dec 16, 2010 at 11:29 AM, David O'Brien  wrote:
> On Thu, Dec 02, 2010 at 03:31:41PM -0800, Garrett Cooper wrote:
>> On Thu, Dec 2, 2010 at 2:43 PM, David O'Brien  wrote:
>> > Thoughts?
>> >
>> > FreeBSD 9.0-CURRENT #654 r215604M: Sat Nov 20 19:51:27 PST 2010
>> >    ro...@dragon:/sys/i386/compile/DRAGON i386
>> > [..]
>> > start = 0, len = 3359, fs = /files
>> > panic: ffs_alloccg: map corrupted
> [..]
>> > ffs_balloc_ufs2(ce55e660,38000,0,4000,ce77b300,...) at 0xc0755629 = 
>> > ffs_balloc_ufs2+0x1949
> [..]
>> > panic: bufwrite: buffer is not busy???
>>
>>     UFS? UFS2? SU? SU+J? Got more details :)?
>
> UFS2, SU+J, ahd(4) HBA
>
> --
> -- David  (obr...@freebsd.org)
> ___
> freebsd-current@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
>
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Re: [PANIC] ffs_alloccg: map corrupted

2010-12-15 Thread David O'Brien
On Thu, Dec 02, 2010 at 03:31:41PM -0800, Garrett Cooper wrote:
> On Thu, Dec 2, 2010 at 2:43 PM, David O'Brien  wrote:
> > Thoughts?
> >
> > FreeBSD 9.0-CURRENT #654 r215604M: Sat Nov 20 19:51:27 PST 2010
> > ? ?ro...@dragon:/sys/i386/compile/DRAGON i386
> > [..]
> > start = 0, len = 3359, fs = /files
> > panic: ffs_alloccg: map corrupted
[..]
> > ffs_balloc_ufs2(ce55e660,38000,0,4000,ce77b300,...) at 0xc0755629 = 
> > ffs_balloc_ufs2+0x1949
[..]
> > panic: bufwrite: buffer is not busy???
> 
> UFS? UFS2? SU? SU+J? Got more details :)?

UFS2, SU+J, ahd(4) HBA

-- 
-- David  (obr...@freebsd.org)
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Re: [PANIC] ffs_alloccg: map corrupted

2010-12-02 Thread Garrett Cooper
On Thu, Dec 2, 2010 at 2:43 PM, David O'Brien  wrote:
> Thoughts?
>
> FreeBSD 9.0-CURRENT #654 r215604M: Sat Nov 20 19:51:27 PST 2010
>    ro...@dragon:/sys/i386/compile/DRAGON i386
> [..]
> start = 0, len = 3359, fs = /files
> panic: ffs_alloccg: map corrupted
> cpuid = 1
> KDB: stack backtrace:
> db_trace_self_wrapper(c0839222,a0d7365,0,c08affe0,7,...) at 0xc04e9ab6 = 
> db_trace_self_wrapper+0x26
> kdb_backtrace(c0857e2a,1,c084c0c3,e99dd70c,1,...) at 0xc05fa2fa = 
> kdb_backtrace+0x2a
> panic(c084c0c3,0,d1f,c6bfc8d4,e123,...) at 0xc05cd297 = panic+0x117
> ffs_mapsearch(3f03fe0,0,8,0,0,...) at 0xc0751793 = ffs_mapsearch+0x153
> ffs_alloccgblk(3f03fe0,0,4000,5a5,0,...) at 0xc075198c = ffs_alloccgblk+0xec
> ffs_alloccg(c98706cc,2be,3f03fe0,0,4000,...) at 0xc07522b3 = ffs_alloccg+0x1b3
> ffs_hashalloc(3f03fe0,0,4000,4000,c0752100,...) at 0xc074ebb1 = 
> ffs_hashalloc+0x41
> ffs_alloc(c98706cc,e,0,3f03fe0,0,...) at 0xc075332f = ffs_alloc+0x19f
> ffs_balloc_ufs2(ce55e660,38000,0,4000,ce77b300,...) at 0xc0755629 = 
> ffs_balloc_ufs2+0x1949
> ffs_write(e99ddb90,e99ddb4c,e99ddb10,c0778dc2,ce55e6b8,...) at 0xc0777f66 = 
> ffs_write+0x276
> VOP_WRITE_APV(c08b0500,e99ddb90,ce55e660,264,0,...) at 0xc07fb574 = 
> VOP_WRITE_APV+0xe4
> vn_write(cf7a9cb0,e99ddc24,ce77b300,0,cb5a2870,...) at 0xc065ec93 = 
> vn_write+0x1c3
> dofilewrite(e99ddc24,,,0,cf7a9cb0,...) at 0xc060a9f5 = 
> dofilewrite+0x95
> kern_writev(cb5a2870,1,e99ddc24,e99ddc44,1,...) at 0xc060ac88 = 
> kern_writev+0x58
> write(cb5a2870,e99ddcec,4,c08ecbc0,b,...) at 0xc060ad0f = write+0x4f
> syscallenter(cb5a2870,e99ddce4,c05bde7d,c709d0d0,3110a33f,...) at 0xc0605d43 
> = syscallenter+0x2c3
> syscall(e99ddd28) at 0xc07dcf94 = syscall+0x34
> Xint0x80_syscall() at 0xc07c8e91 = Xint0x80_syscall+0x21
> --- syscall (4, FreeBSD ELF32, write), eip = 0x281e260b, esp = 0xbfbfc19c, 
> ebp = 0xbfbfc1b8 ---
> panic: bufwrite: buffer is not busy???
> cpuid = 1

UFS? UFS2? SU? SU+J? Got more details :)?
Thanks,
-Garrett
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


[PANIC] ffs_alloccg: map corrupted (2nd file system)

2010-12-02 Thread David O'Brien
FreeBSD 9.0-CURRENT #654 r215604M: Sat Nov 20 19:51:27 PST 2010
ro...@dragon:/sys/i386/compile/DRAGON i386
[..]
start = 0, len = 2, fs = /jazz
panic: ffs_alloccg: map corrupted
cpuid = 2
KDB: stack backtrace:
db_trace_self_wrapper(c0839222,0,1,4,0,...) at 0xc04e9ab6 = 
db_trace_self_wrapper+0x26
kdb_backtrace(c0857e2a,2,c084c0c3,ea17f70c,2,...) at 0xc05fa2fa = 
kdb_backtrace+0x2a
panic(c084c0c3,0,2,c5d580d4,dc7d4000,...) at 0xc05cd297 = panic+0x117
ffs_mapsearch(3af3c10,0,8,0,0,...) at 0xc0751793 = ffs_mapsearch+0x153
ffs_alloccgblk(3af3c10,0,4000,5a5,0,...) at 0xc075198c = ffs_alloccgblk+0xec
ffs_alloccg(c7758ae0,291,3af3c10,0,4000,...) at 0xc07522b3 = ffs_alloccg+0x1b3
ffs_hashalloc(3af3c10,0,4000,4000,c0752100,...) at 0xc074ebb1 = 
ffs_hashalloc+0x41
ffs_alloc(c7758ae0,380c,0,3af3c10,0,...) at 0xc075332f = ffs_alloc+0x19f
ffs_balloc_ufs2(c7753110,e03,0,4000,c8ac8880,...) at 0xc0755369 = 
ffs_balloc_ufs2+0x1689
ffs_write(ea17fb90,ea17fb4c,ea17fb10,c0778dc2,c7753168,...) at 0xc0777f66 = 
ffs_write+0x276
VOP_WRITE_APV(c08b0500,ea17fb90,c7753110,264,0,...) at 0xc07fb574 = 
VOP_WRITE_APV+0xe4
vn_write(c6cc6888,ea17fc24,c8ac8880,0,c88c2000,...) at 0xc065ec93 = 
vn_write+0x1c3
dofilewrite(ea17fc24,,,0,c6cc6888,...) at 0xc060a9f5 = 
dofilewrite+0x95
kern_writev(c88c2000,4,ea17fc24,ea17fc44,1,...) at 0xc060ac88 = kern_writev+0x58
write(c88c2000,ea17fcec,c88c2000,ea17fd28,e8e2d15e,...) at 0xc060ad0f = 
write+0x4f
syscallenter(c88c2000,ea17fce4,ea17fce4,0,0,...) at 0xc0605d43 = 
syscallenter+0x2c3
syscall(ea17fd28) at 0xc07dcf94 = syscall+0x34
Xint0x80_syscall() at 0xc07c8e91 = Xint0x80_syscall+0x21
--- syscall (4, FreeBSD ELF32, write), eip = 0x281e260b, esp = 0xbfbfb61c, ebp 
= 0xbfbfb638 ---
panic: bufwrite: buffer is not busy???
cpuid = 2

-- 
-- David  (obr...@freebsd.org)
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


[PANIC] ffs_alloccg: map corrupted

2010-12-02 Thread David O'Brien
Thoughts?

FreeBSD 9.0-CURRENT #654 r215604M: Sat Nov 20 19:51:27 PST 2010
ro...@dragon:/sys/i386/compile/DRAGON i386
[..]
start = 0, len = 3359, fs = /files
panic: ffs_alloccg: map corrupted
cpuid = 1
KDB: stack backtrace:
db_trace_self_wrapper(c0839222,a0d7365,0,c08affe0,7,...) at 0xc04e9ab6 = 
db_trace_self_wrapper+0x26
kdb_backtrace(c0857e2a,1,c084c0c3,e99dd70c,1,...) at 0xc05fa2fa = 
kdb_backtrace+0x2a
panic(c084c0c3,0,d1f,c6bfc8d4,e123,...) at 0xc05cd297 = panic+0x117
ffs_mapsearch(3f03fe0,0,8,0,0,...) at 0xc0751793 = ffs_mapsearch+0x153
ffs_alloccgblk(3f03fe0,0,4000,5a5,0,...) at 0xc075198c = ffs_alloccgblk+0xec
ffs_alloccg(c98706cc,2be,3f03fe0,0,4000,...) at 0xc07522b3 = ffs_alloccg+0x1b3
ffs_hashalloc(3f03fe0,0,4000,4000,c0752100,...) at 0xc074ebb1 = 
ffs_hashalloc+0x41
ffs_alloc(c98706cc,e,0,3f03fe0,0,...) at 0xc075332f = ffs_alloc+0x19f
ffs_balloc_ufs2(ce55e660,38000,0,4000,ce77b300,...) at 0xc0755629 = 
ffs_balloc_ufs2+0x1949
ffs_write(e99ddb90,e99ddb4c,e99ddb10,c0778dc2,ce55e6b8,...) at 0xc0777f66 = 
ffs_write+0x276
VOP_WRITE_APV(c08b0500,e99ddb90,ce55e660,264,0,...) at 0xc07fb574 = 
VOP_WRITE_APV+0xe4
vn_write(cf7a9cb0,e99ddc24,ce77b300,0,cb5a2870,...) at 0xc065ec93 = 
vn_write+0x1c3
dofilewrite(e99ddc24,,,0,cf7a9cb0,...) at 0xc060a9f5 = 
dofilewrite+0x95
kern_writev(cb5a2870,1,e99ddc24,e99ddc44,1,...) at 0xc060ac88 = kern_writev+0x58
write(cb5a2870,e99ddcec,4,c08ecbc0,b,...) at 0xc060ad0f = write+0x4f
syscallenter(cb5a2870,e99ddce4,c05bde7d,c709d0d0,3110a33f,...) at 0xc0605d43 = 
syscallenter+0x2c3
syscall(e99ddd28) at 0xc07dcf94 = syscall+0x34
Xint0x80_syscall() at 0xc07c8e91 = Xint0x80_syscall+0x21
--- syscall (4, FreeBSD ELF32, write), eip = 0x281e260b, esp = 0xbfbfc19c, ebp 
= 0xbfbfc1b8 ---
panic: bufwrite: buffer is not busy???
cpuid = 1

-- 
-- David  (obr...@freebsd.org)
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


repeatable ufs2 softupdate panic ffs_alloccg: map corrupted

2003-08-18 Thread Aaron Wohl
I got a couple of kernel crashes this morning when amanda tried to
allocate disk space.  I guessed which structure this was writing to,
unounted it and did a fsck -f -y on it.  Remounted it and all is happy
now.  It corrected three block counts that where off.  This was in 5.1
-current less than a week old

Shouldnt it have forced a regular fsck at boot time on its own?  Or how
come the background fsck didnt complain about it?

panic: ffs_alloccg: map corrupted
panic messages:
---
dmesg: kvm_read: 
---

warning: failed to read linker file data at 0xcc02aa00

#0  doadump () at /usr/src/sys/kern/kern_shutdown.c:240
240 dumping++;
(kgdb) where
#0  doadump () at /usr/src/sys/kern/kern_shutdown.c:240
#1  0xc030bd6b in boot (howto=260) at
/usr/src/sys/kern/kern_shutdown.c:372
#2  0xc030c176 in panic () at /usr/src/sys/kern/kern_shutdown.c:550
#3  0xc0352a71 in bremfreel (bp=0xd82a6628) at
/usr/src/sys/kern/vfs_bio.c:644
#4  0xc0352945 in bremfree (bp=0x0) at /usr/src/sys/kern/vfs_bio.c:626
#5  0xc035c921 in vop_stdfsync (ap=0xe6d867c0) at
/usr/src/sys/kern/vfs_default.c:740
#6  0xc02d1870 in spec_fsync (ap=0xe6d867c0) at
/usr/src/sys/fs/specfs/spec_vnops.c:417
#7  0xc02d0b48 in spec_vnoperate (ap=0x0) at
/usr/src/sys/fs/specfs/spec_vnops.c:122
#8  0xc0428417 in ffs_sync (mp=0xcbda6400, waitfor=2, cred=0xc6752e80,
td=0xc05a3960) at vnode_if.h:627
#9  0xc0368c2b in sync (td=0xc05a3960, uap=0x0) at
/usr/src/sys/kern/vfs_syscalls.c:142
#10 0xc030b8bf in boot (howto=256) at
/usr/src/sys/kern/kern_shutdown.c:281
#11 0xc030c176 in panic () at /usr/src/sys/kern/kern_shutdown.c:550
#12 0xc0410e41 in ffs_mapsearch (fs=0xcc013800, cgp=0xdf15,
bpref=8589934592, allocsiz=8)
at /usr/src/sys/ufs/ffs/ffs_alloc.c:2041
#13 0xc040f414 in ffs_alloccgblk (ip=0xcbdb06c0, bp=0xd82a6628,
bpref=120663592) at /usr/src/sys/ufs/ffs/ffs_alloc.c:1405
#14 0xc040f043 in ffs_alloccg (ip=0xcbdb06c0, cg=1283, bpref=120663592,
size=16384) at /usr/src/sys/ufs/ffs/ffs_alloc.c:1302
#15 0xc040e9f7 in ffs_hashalloc (ip=0xcbdb06c0, cg=1283, pref=0,
size=16384, allocator=0xc040eee0 )
at /usr/src/sys/ufs/ffs/ffs_alloc.c:1155
#16 0xc040c8d7 in ffs_alloc (ip=0xcbdb06c0, lbn=274445, bpref=120663592,
size=16384, cred=0xcc2e9280, bnp=0xe6d86a58)
at /usr/src/sys/ufs/ffs/ffs_alloc.c:157
#17 0xc04122c0 in ffs_balloc_ufs1 (vp=0xcb93e7fc, startoffset=0,
size=16384, cred=0xcc2e9280, flags=2130706432, bpp=0xe6d86b9c)
at /usr/src/sys/ufs/ffs/ffs_balloc.c:311
#18 0xc0429b67 in ffs_write (ap=0xe6d86be0) at
/usr/src/sys/ufs/ffs/ffs_vnops.c:698
#19 0xc0371183 in vn_write (fp=0xcc42bcc0, uio=0xe6d86c7c,
active_cred=0xcc2e9280, flags=0, td=0xcb907e40) at vnode_if.h:432
#20 0xc0333ce8 in dofilewrite (td=0xcb907e40, fp=0xcc42bcc0, fd=0,
buf=0x50238000, nbyte=0, offset=0, flags=0)
at /usr/src/sys/sys/file.h:249
#21 0xc0333b1e in write (td=0xcb907e40, uap=0xe6d86d10) at
/usr/src/sys/kern/sys_generic.c:330
#22 0xc0492253 in syscall (frame=
  {tf_fs = 47, tf_es = 47, tf_ds = -1078001617, tf_edi = 240, tf_esi
  = 4, tf_ebp = -1077938056, tf_isp = -422023820, tf_ebx =
  1208604828, tf_edx = 240, tf_ecx = 32768, tf_eax = 4, tf_trapno =
  22, tf_err = 2, tf_eip = 1209550783, tf_cs = 31, tf_eflags = 514,
  tf_esp = -1077938116, tf_ss = 47}) at
  /usr/src/sys/i386/i386/trap.c:1008
#23 0xc047988d in Xint0x80_syscall () at {standard input}:145
---Can't read userspace from dump, or kernel process---
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"