Date: Sat, 26 Sep 1998 08:55:52 -0700 From: Don Lewis <Don.Lewis@tsc.tdk.com> To: Kevin Street <street@iname.com>, freebsd-current@FreeBSD.ORG Subject: Re: Softupdates panics Message-ID: <199809261555.IAA00941@salsa.gv.tsc.tdk.com> In-Reply-To: Kevin Street <street@iname.com> "Softupdates panics" (Sep 26, 1:50am)
next in thread | previous in thread | raw e-mail | index | archive | help
On Sep 26, 1:50am, Kevin Street wrote:
} Subject: Softupdates panics
} Here for your enjoyment are two softupdates panics. These are the first
} I've seen after months of softupdates use. They came shortly after I
} added `noatime' to two of my heavily used softupdates slices in
} /etc/fstab, but I have been in the habit of dynamically updating the
} mounts with noatime before make worlds with no problems. These happened
} in the middle of large port compiles. I've taken the noatime out of
} fstab and have survived a couple of passes through the same port build.
}
} The system is ELF built Sept 24. I do have the Sept 24 ffs_softdep.c.
} The softupdates drives are all IDE. I do have SCSI drives using CAM,
} but do not have softupdates enabled on them.
}
}
} IdlePTD 2326528
} initial pcb at 212948
} panicstr: softdep_disk_write_complete: lock is held
} panic messages:
} ---
} panic: newdirrem: inum 494166 should be 494160
}
} syncing disks... panic: softdep_disk_write_complete: lock is held
Something should probably be done about this double panic. The problem
is that the softupdates code is calling panic() while it has an internal
lock set, and then softupdates is being reentered when the kernel tries to
flush all the dirty buffers.
I'd be willing to bet that the newdirrem panic is has a similar cause
to the recently fixed initiate_write_filepage panic. That problem was
caused by the softupdates code unlocking a directory at the wrong time
during ufs_create() and allowing a directory slot to be reused. Alas,
ufs_rename() is much more complicated to debug.
} ---
} #0 boot (howto=260) at ../../kern/kern_shutdown.c:268
} 268 dumppcb.pcb_cr3 = rcr3();
} (kgdb) where
} #0 boot (howto=260) at ../../kern/kern_shutdown.c:268
} #1 0xf0131fcb in panic (
} fmt=0xf018e7cb "softdep_disk_write_complete: lock is held")
} at ../../kern/kern_shutdown.c:430
} #2 0xf018e88b in softdep_disk_write_complete (bp=0xf32c4ea0)
} at ../../ufs/ffs/ffs_softdep.c:2922
} #3 0xf014e4ef in biodone (bp=0xf32c4ea0) at ../../kern/vfs_bio.c:1915
} #4 0xf01e4e8f in wdintr (unit=1) at ../../i386/isa/wd.c:1270
} #5 0xf01ad2ee in vec15 ()
} #6 0xf014e2cb in biowait (bp=0xf33182a0) at ../../kern/vfs_bio.c:1851
} #7 0xf014c2e6 in bread (vp=0xf5b6bf60, blkno=64, size=8192, cred=0x0,
} bpp=0xf5c92b40) at ../../kern/vfs_bio.c:299
} #8 0xf0189d50 in ffs_update (vp=0xf5b6bec0, access=0xf5c92ba8,
} modify=0xf5c92ba8, waitfor=0) at ../../ufs/ffs/ffs_inode.c:102
} #9 0xf0193e49 in ffs_fsync (ap=0xf5c92be4) at ../../ufs/ffs/ffs_vnops.c:252
} #10 0xf0192247 in ffs_sync (mp=0xf0914a00, waitfor=2, cred=0xf08fa800,
} p=0xf022d5dc) at vnode_if.h:499
} #11 0xf0155127 in sync (p=0xf022d5dc, uap=0x0) at ../../kern/vfs_syscalls.c:527
} #12 0xf0131ba2 in boot (howto=256) at ../../kern/kern_shutdown.c:201
} #13 0xf0131fcb in panic (fmt=0xf018daf6 "newdirrem: inum %d should be %d")
} at ../../kern/kern_shutdown.c:430
} #14 0xf018dc49 in newdirrem (bp=0xf32c9778, dp=0xf0b9ae00, ip=0xf0b89800,
} isrmdir=0) at ../../ufs/ffs/ffs_softdep.c:2384
} #15 0xf018da74 in softdep_setup_remove (bp=0xf32c9778, dp=0xf0b9ae00,
} ip=0xf0b89800, isrmdir=0) at ../../ufs/ffs/ffs_softdep.c:2313
} #16 0xf01967e7 in ufs_dirremove (dvp=0xf5c64c80, ip=0xf0b89800, flags=37900,
} isrmdir=0) at ../../ufs/ufs/ufs_lookup.c:895
} #17 0xf01997dd in ufs_rename (ap=0xf5c92ea4) at ../../ufs/ufs/ufs_vnops.c:1230
} #18 0xf019a989 in ufs_vnoperate (ap=0xf5c92ea4)
} at ../../ufs/ufs/ufs_vnops.c:2285
} #19 0xf0157ce6 in rename (p=0xf5c89c40, uap=0xf5c92f84) at vnode_if.h:583
} #20 0xf01b5a9f in syscall (frame={tf_es = 39, tf_ds = 39, tf_edi = -272643708,
} tf_esi = -272641052, tf_ebp = -272643760, tf_isp = -171364396,
} tf_ebx = -272643701, tf_edx = -1, tf_ecx = 2, tf_eax = 128,
} tf_trapno = 12, tf_err = 2, tf_eip = 134528056, tf_cs = 31,
} tf_eflags = 662, tf_esp = -272645176, tf_ss = 39})
} at ../../i386/i386/trap.c:1031
} #21 0xf01abdbc in Xint0x80_syscall ()
} #22 0x8048305 in ?? ()
} #23 0x80480c9 in ?? ()
} IdlePTD 2326528
} initial pcb at 212948
} panicstr: softdep_lock: locking against myself
} panic messages:
} ---
} panic: newdirrem: inum 494335 should be 494334
}
} syncing disks... panic: softdep_lock: locking against myself
This is very similar. First newdirrem detects a problem and calls
panic(), then the softupdates code is be reentered and it detects
the lock is already set.
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199809261555.IAA00941>