> > It may not be the same problem.  When I took DDB out of my kernel, the
> > system did a crash, rather than a lockup.  
> 
> That suggests that the "lockup" was actually a crash into DDB; you
> couldn't see the DDB prompt..

Yes, that was what another suggested (I can't remember how to spell his
name, so I won't risk mangling it...*grin*).  That's why I tried removing
DDB.


> As a first step, can you get a backtrace out of the crash dump?
> 
> cd /var/crash
> gdb ./netbsd.0
> (gdb) target kcore netbsd.0.core
> (gdb) where

I should probably read the gdb man page one of these days.  (^&

 /~~~

GNU gdb 4.17
Copyright 1998 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i386--netbsd"...(no debugging symbols found)...
(gdb) target kcore netbsd.0.core
panic: pagedaemon: clean anon page without backing store?
#0  0xf0217c42 in uvm_pageout ()
(gdb) where
#0  0xf0217c42 in uvm_pageout ()
#1  0xf021f6e7 in cpu_reboot ()
#2  0xf015eaf0 in log ()
#3  0xf0217ef9 in uvmpd_scan_inactive ()
#4  0xf02183cf in uvmpd_scan ()
#5  0xf0217ba3 in uvm_pageout ()
#6  0xf014cc28 in start_pagedaemon ()
(gdb) 

 \___

...so.  Does that mean anything to anyone reading this?

I assume that the #0 line is the function most recently entered, and the
others are successively deaper backtraces.  Is that correct?


So far, I have not been able to get SETI@Home to crash again, to see if it
gives the same info.


  "I probably don't know what I'm talking about."  --rkr@rkr.kcnet.com