Re: Panic - FFS background buffer bla bla

On Wed, Feb 09, 2005 at 11:04:19PM -0600, Eric Anderson wrote:
> Kris Kennaway wrote:
> 
> >On Wed, Feb 09, 2005 at 10:40:03PM -0600, Eric Anderson wrote:
> >
> > 
> >
> >>panic(c09811a1,d19f4fc8,c0730c71,c0a92ec0,0) at panic+0xe8
> >>bufwrite(d19f4fc8,0,c0991b40,652,0) at bufwrite+0x84
> >>ffs_bufwrite(d19f4fc8,0,c09907be,1407,c097d9cd) at ffs_bufwrite+0x2f8
> >>flush_pagedep_deps(c254dcf0,c251fc00,c254ae74,129b,2) at 
> >>flush_pagedep_deps+0x2d
> >>d
> >>softdep_sync_metadata(c254dcf0,0,c0991de3,129,1) at 
> >>softdep_sync_metadata+0x501
> >>ffs_syncvnode(c254dcf0,1,e7dec688,c0706f33,c0a760c0) at 
> >>ffs_syncvnode+0x3a5
> >>ffs_truncate(c254dcf0,200,0,880,c220e780) at ffs_truncate+0x5be
> >>ufs_direnter(c254dcf0,c25d4450,e7dec8e8,e7decbfc,0) at ufs_direnter+0x980
> >>ufs_makeinode(81a4,c254dcf0,e7decbe8,e7decbfc,e7deca64) at 
> >>ufs_makeinode+0x4e7
> >>ufs_create(e7deca64,e7decd14,e7decbd4,e7decd14,e7decb20) at 
> >>ufs_create+0x37
> >>VOP_CREATE_APV(c0a17b80,e7deca64,2,2,1) at VOP_CREATE_APV+0xbc
> >>vn_open_cred(e7decbd4,e7deccd4,1a4,c220e780,4) at vn_open_cred+0x1fb
> >>vn_open(e7decbd4,e7deccd4,1a4,4,c0a927d8) at vn_open+0x33
> >>kern_open(c255ecf0,804b048,0,602,21b6) at kern_open+0xc8
> >>open(c255ecf0,e7decd14,c,3ff,3) at open+0x36
> >>syscall(2f,2f,2f,805f100,bfbfeea4) at syscall+0x2a0
> >>Xint0x80_syscall() at Xint0x80_syscall+0x1f
> >>--- syscall (5, FreeBSD ELF32, open), eip = 0x280cad6f, esp = 
> >>0xbfbfec5c, ebp = 0xbfbfeca8 ---
> >>
> >>Sorry for any wrapping - I'm using a windows pc to grab this using 
> >>hyperterminal (eek!)..
> >>
> >>Does that help?
> >>   
> >>
> >
> >That's it.  What does
> >
> >x/s 0xc09811a1
> >
> >show?  It will be the format string for the panic message, which I'm
> >guessing is your
> >
> >      KASSERT(!(bp->b_vflags & BV_BKGRDINPROG),
> >           ("FFS background buffer should not get here %p", bp));
> >
> >again.  Anyway, dump core if you can in case phk needs to see it.
> > 
> >
> 
> Yep - that's it.  I did a 'panic' (which I think tries to dump core), 
> and it spewed a ton of:
> panic: sched_bind: cannot bind non-running thread
> cpuid = 0
> then locked up.. I'll reboot and see what happened..

It's often better to 'call doadump' instead.

Kris