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 ;-)