dave@tis.com (David I. Dalva) (08/24/90)
Hi Wizards, I have a question regarding the implementation of panic()
in the UNIX kernel (both BSD and SYSV kernels are equivalent).
The code goes something like this:
panic(s)
char *s;
{
printf("%s\n", s);
if (firsttime) {
firsttime = FALSE;
sync();
}
halt();
}
Why is it that panic calls sync() (or update()) before the system is
halted, when data structures may be messed up causing further damage to
the filesystem? I believe fsck should be able to recover to the most
recent sync().
I am experiencing a problem where the sync() itself is panicking
(recursively) messing up the filesystem further. Taking the sync()
out greatly reduces filesystem damage.
Dave Dalva
Trusted Information Systems, Inc.
Glenwood, MD 21738
(301) 854-6889jbm@eos.UUCP (Jeffrey Mulligan) (08/25/90)
dave@tis.com (David I. Dalva) writes: >The code goes something like this: > panic(s) > char *s; > { > printf("%s\n", s); > if (firsttime) { > firsttime = FALSE; > sync(); > } > halt(); > } >I am experiencing a problem where the sync() itself is panicking >(recursively) messing up the filesystem further. Taking the sync() >out greatly reduces filesystem damage. It would seem that the use of the flag "firsttime" is to prevent multiple or recursive calls to sunc(); if this is happening, then perhaps whatever is causing the panic is also scribbling over firsttime. Maybe you could try moving it to another part of the address space and see what happens. My naive guess about doing a sync()/update() at all, is that it's just a probabalistic tradeoff, there is a certain probability that there will be errors without a sync, there is another probability that the sync will make matters worse. It sounds like in your case the roulette wheel is coming up 00. -- Jeff Mulligan (jbm@eos.arc.nasa.gov) NASA/Ames Research Ctr., Mail Stop 262-2, Moffet Field CA, 94035 (415) 604-3745
chris@mimsy.umd.edu (Chris Torek) (08/25/90)
In article <24280@adm.BRL.MIL> dave@tis.com (David I. Dalva) asks why the 4BSD and SysVR? (neither release number nor platform mentioned, although these have a great deal of significance) kernels attempt to sync the disks on a call to panic: >Why is it that panic calls sync() (or update()) before the system is >halted, when data structures may be messed up causing further damage to >the filesystem? In general, the panic is due to something relatively minor, and the sync makes things better instead of worse. Very occasionally (especially after mucking with the filesystem code :-) ) it has the opposite effect, but overall the sync was deemed to be a win. (Anyway, system developers can always disable it temporarily.) -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 405 2750) Domain: chris@cs.umd.edu Path: uunet!mimsy!chris
Daniel_Roedding@fiction.ms.sub.org (08/28/90)
jbm@eos.UUCP (Jeffrey Mulligan) writes: dave@tis.com (David I. Dalva) writes: > >The code goes something like this: > > panic(s) > > char *s; > > { > > printf("%s\n", s); > > if (firsttime) { > > firsttime = FALSE; > > sync(); > > } > > halt(); > > } > It would seem that the use of the flag "firsttime" is to prevent > multiple or recursive calls to sunc(); if this is happening, then > perhaps whatever is causing the panic is also scribbling over > firsttime. Maybe you could try moving it to another part of the > address space and see what happens. Probably it's sufficient to assign a "magic" value to "firsttime". A manipulation could be detected much easier: panic(s) char *s; { printf("%s\n",s); switch (firsttime) { case FT_FIRST: firsttime=FT_SECOND; sync(); case FT_SECOND: halt(); default: printf("Argh -- who manipulated my vars????\n"); halt(); } } Daniel --- Daniel Roedding #include <disclaimer.h> Geiststrasse 32 "This golden age of communication D-4400 Muenster Means everyone talks at the same time" (NMA) ++49 251 525306 daniel@fiction.ms.sub.org; ..!uunet!mcsun!unido!mcshh!veeble!fiction!daniel