Bug 32809
| Summary: | yet another panic while syncing disks after a panic | ||
|---|---|---|---|
| Product: | Base System | Reporter: | Yar Tikhiy <yar> |
| Component: | kern | Assignee: | freebsd-bugs (Nobody) <bugs> |
| Status: | Closed FIXED | ||
| Severity: | Affects Only Me | ||
| Priority: | Normal | ||
| Version: | 5.0-CURRENT | ||
| Hardware: | Any | ||
| OS: | Any | ||
On Thu, 13 Dec 2001, Yar Tikhiy wrote: > >Description: > > After any panic, the system tries to sync disks, > but gets yet another panic as follows: > > stylish# sysctl debug.debugger_on_panic=0 > debug.debugger_on_panic: 1 -> 0 > stylish# ./666 > panic: test panic > > syncing disks... panic: bremfree: bp 0xc217a428 not locked > Uptime: 4m43s > pfs_vncache_unload(): 1 entries remaining sync() from panic() only works accidentally. I'ts like calling a non-signal safe function from a signal handler -- when the system panics, it quite likely to be executing filesystem code or holding a lock that should prevent filesystem code being run, but panic() executes filesystem code (the sync()) unless the panic is recursive. Addition of locks has greatly increased the chance that the sync() in panic will deadlock instead of appearing to work. > dumping to dev ad0s1b, offset 139376 > dump ata0: resetting devices .. > [the system hangs dead at this point sometimes] addump() seems to have regressed relative to wddump(). Dump routines should not use any normal i/o routines. Bruce Responsible Changed From-To: freebsd-bugs->sos bde thinks the problem has to do with addump(). Soren, perhaps you can get more specific information out of Bruce? :-) Responsible Changed From-To: sos->freebsd-bugs Hmm, Dumping works just fine here, the problem might be more entangled ... I have a suspicion that the KASSERT macro is panicking the system when it is called from bremfree(). On Tue, Dec 24, 2002 at 07:36:21AM -0600, KAREN THODE wrote:
> I have a suspicion that the KASSERT macro is panicking the system when it is called from bremfree().
It's the purpose of KASSERT() to panic the system if the assertion
fails.
--
Yar
State Changed From-To: open->closed -CURRENT no longer syncs disks after panics. |
After any panic, the system tries to sync disks, but gets yet another panic as follows: stylish# sysctl debug.debugger_on_panic=0 debug.debugger_on_panic: 1 -> 0 stylish# ./666 panic: test panic syncing disks... panic: bremfree: bp 0xc217a428 not locked Uptime: 4m43s pfs_vncache_unload(): 1 entries remaining dumping to dev ad0s1b, offset 139376 dump ata0: resetting devices .. [the system hangs dead at this point sometimes] A stack trace looks like as follows (sorry, the above bp pointer doesn't match the stack trace): #0 dumpsys () at /usr/src/sys/kern/kern_shutdown.c:492 #1 0xc0167847 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:335 #2 0xc0167c81 in panic (fmt=0xc0224c01 "bremfree: bp %p not locked") at /usr/src/sys/kern/kern_shutdown.c:634 #3 0xc01935d1 in bremfree (bp=0xc218debc) at /usr/src/sys/kern/vfs_bio.c:545 #4 0xc0194bcd in vfs_bio_awrite (bp=0xc218debc) at /usr/src/sys/kern/vfs_bio.c:1535 #5 0xc01cc6d4 in ffs_fsync (ap=0xc68819d4) at /usr/src/sys/ufs/ffs/ffs_vnops.c:239 #6 0xc01caf12 in ffs_sync (mp=0xc0dcae00, waitfor=2, cred=0xc05a6e00, td=0xc02a2b24) at vnode_if.h:441 #7 0xc019fb8d in sync (td=0xc02a2b24, uap=0x0) at /usr/src/sys/kern/vfs_syscalls.c:657 #8 0xc0167490 in boot (howto=256) at /usr/src/sys/kern/kern_shutdown.c:244 #9 0xc0167c81 in panic (fmt=0xc0235c5e "test panic") at /usr/src/sys/kern/kern_shutdown.c:634 Fix: I had better left it to the disk/fs subsystem wizards for now. How-To-Repeat: Just make a system of a close version panic.