Date: Fri, 14 Dec 2001 18:40:01 -0800 (PST) From: Bruce Evans <bde@zeta.org.au> To: freebsd-bugs@FreeBSD.org Subject: Re: kern/32809: yet another panic while syncing disks after a panic Message-ID: <200112150240.fBF2e1810896@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
The following reply was made to PR kern/32809; it has been noted by GNATS. From: Bruce Evans <bde@zeta.org.au> To: Yar Tikhiy <yar@comp.chem.msu.su> Cc: <FreeBSD-gnats-submit@FreeBSD.ORG> Subject: Re: kern/32809: yet another panic while syncing disks after a panic Date: Sat, 15 Dec 2001 13:32:55 +1100 (EST) 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 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200112150240.fBF2e1810896>