Return to BSD News archive
Path: sserve!newshost.anu.edu.au!munnari.oz.au!goanna!escargot!minyos.xx.rmit.OZ.AU!s902113
From: s902113@minyos.xx.rmit.OZ.AU (Luke Mewburn)
Newsgroups: comp.os.386bsd.questions
Subject: Re: fsck summary info bad after every shutdown
Message-ID: <1tk3raINN3h6@escargot.xx.rmit.OZ.AU>
Date: 22 May 93 02:40:42 GMT
References: <root.737640955@gimli>
Reply-To: zak@rmit.edu.au
Organization: NetBSD For Me
Lines: 132
NNTP-Posting-Host: minyos.xx.rmit.oz.au
root@gimli.cs.uct.ac.za (Sandi Donno) writes:
> Has anyone had the following problem, or can anyone point me at the
> likely cause:
> I have installed 386bsd on 4 identical 486's with 120MB IDE hard drives, and
> patchkit 0.2.3. Whether I use /sbin/shutdown, /usr/distbin/shutdown or reboot,
> fsck always finds the summary information bad after rebooting; the system
> is rebooted and the next time fsck finds no errors.
I think I've worked it out. Try using 'reboot -q' instead of 'reboot'
(or shutdown -h instead of shutdown -r). Now, as I've not tracked down
exactly how to reproduce this, I'm hadn't got around to reporting it
to the NetBSD dudes (cause I never used to use reboot on 386bsd and
thus thought it might have been something brought in under netbsd -
seems i'm wrong). Back on track, I have determined a few things:
- reboot -q never seems to cause the problem. It will always do
something like:
updating disks before reboot ... succeded
before rebooting. ^^^(sic :)
- reboot by itself does a log to the wtmp file if -n or -q aren't
present, then syncs and waits for 5 seconds. something like:
if (!qflag && (howto & RB_NOSYNC) == 0) {
logwtmp("~", "shutdown", "");
sync();
setalarm(5);
pause();
}
Now, sometimes when I use 'reboot' w/o a sync (on the command line)
first, it does the log to wtmp but DOESN'T print the 'updating
disks before rebooting mesg' which indicated to me that kernel
was doing some conditional syncing inside it's boot() code.
In any case, a lot of the time, by using 'reboot' w/o -q, I got
the inconsitant file system.
- /var/log/wtmp doesn't exist in the default NetBSD installation.
at first, I thought that this might have cause a problem (since
syslog() won't create a logfile), but I'm pretty sure that this
isn't a relevant as I first thought.
- the boot code (in i386/i386/machdep.c) has something like the
following. A note about this (regarding the initial if statement.
- howto&RB_NOSYNC == 0 for 'reboot' and 'reboot -q'
- waittime is < 0 the first time thru
- I _don't_ know when bfreelist[0].b_forw is !0. this
could be part of it.
-- code from machdep.c --
if ((howto&RB_NOSYNC) == 0 && waittime < 0 && bfreelist[0].b_forw) {
register struct buf *bp;
int iter, nbusy;
waittime = 0;
(void) splnet();
/*
* Release inodes held by texts before update.
*/
if (panicstr == 0)
vnode_pager_umount(NULL);
sync((struct sigcontext *)0);
for (iter = 0; iter < 20; iter++) {
nbusy = 0;
for (bp = &buf[nbuf]; --bp >= buf; )
if ((bp->b_flags & (B_BUSY|B_INVAL)) == B_BUSY)
nbusy++;
if (nbusy == 0)
break;
if (nomsg) {
printf("updating disks before rebooting... ");
nomsg = 0;
}
/* printf("%d ", nbusy); */
DELAY(40000 * iter);
}
if (nbusy)
printf(" failed!\n");
else if (nomsg == 0)
printf("succeded.\n");
/*
* XXX: Zak, 930522 - fix this ^^^^^^^^^ typo :)
*/
DELAY(10000); /* wait for printf to finish */
}
-- end code excerpt --
- NetBSD has a dirty fs after you've finished the major part of the
installation (which incidently, tells you to type 'reboot' to
start the whole thing going post-install). Maybe they should
recommend 'shutdown -h now' or 'reboot -q' until this problem is
solved.
Unfortunately, I'll admit that that is where I'm at. I know the
problem is related to one of the things that I've mentioned here.
I found most of this out friday morning whilst getting ready for
work. I'll work on it over the weeking. Maybe a better kernel hacker
than I can work it out from here.
[I've seen posts mentioning to have a flag indicating that a FS is
'clean' and get 'fsck' to ignore clean FS's, but I think that that
proposal is on the wrong track. fsck is correct in noting that the fs
is dirty, and you might get a program which stuffs up one day and
constantly marks your FS as ok, when it's not. I don't want to take
that risk.]
> One thing that is interesting is that the wdgetctlr fails in i386/isa/wd.c,
> and the comment says that this happens with old ST506 controllers. These
> are brand new IDE controllers, but I am not sure what make they are.
Dunno about this one.
> --
> Sandi Donno
> sandi@cs.uct.ac.za
Luke.
--
Luke Mewburn [Zak], <zak@rmit.edu.au>
"Lawyers - the only group for which ignorance of the law is not a crime" - anon