Subject: Re: /sys/scsi/sd.c's sddump()
To: None <tech-kern@netbsd.org>
From: matthew green <mrg@mame.mu.OZ.AU>
List: tech-kern
Date: 12/06/1994 01:21:18
>what are the current problems with sddump() that it's currently
>"not implimented" ? it's be nice to have some kernel core dumps..
The only barrier to this as far as I can tell is that it's a bit hard to
debug -- if you goof, your filesystem is toast :-).
i realised this. you might not believe me, though.. ;-)
I'm interested in getting this working ... anyone else want to work on it?
i've mostly done it, i think. at least, it spent time
counting down from 16 to 0 (i have 16 meg), and then when
it ran savecore it created the relevant files in /var/crash.
the problem was the core file was useless. i believe this
is because /etc/rc has this:
[ ... ]
swapon -a
[ ... ]
if [ -d /var/crash ]; then
echo checking for core dump...
savecore /var/crash
fi
[ ... ]
so it's possible that something trashes the swap area before
savecore has a chance to save it. i could be wrong, i got
sick of building kernels for the night a few hours ago and
haven't looked at it since ;-)
There's a bunch of code that's commented out in there, but I suspect that it's
old and isn't relevant anymore.
most of it was `ok'. a few interfaces had changed but i
worked out the new ones (i think), then tried it with the
NOT_TRUSTED define still in place, watched mountains for
messages fly by my screen (the *slow* sparc console, at
that).. they seemed ok, so i undef'ed NOT_TRUSTED and gave
it a go. seemed to dump ok, besides not actually getting
a useful core at the end ;-)