On Mon, 24 Feb 1997 19:40:51 (-0800) 
 Scott Ellis <scotte@warped.com> wrote:

 > Are you running lpd?  I noticed that using yesterdays vm_object (building
 > a kernel with the new .c file now...) that lpd would cause the system
 > to hang on startup, rather than when it was killed.  Removing lpd from
 > rc.conf solved the problem.

I got it with just tar :-)

Actually, the problem here is "tar -zxvf ..." ... note the "z" ... it
creates a sub-process.  This sub-process is the one that's hung..

So, I did some groveling with kgdb and ddb and came up with the following
kernel stack trace for the wedged subprocess:

(This is on a SPARC, BTW)

_thread_sleep_msg
_lock_read + 0xbc
_vm_map_lookup + 0xc
_vm_fault(f8645a00, 0, 1, 0) at vm_fault + 0x54
                    ^
		    NULL pointer deref
_mem_access_fault + 0x1a8
_normal_mem_fault + 0x28
_vm_object_shadow + 0x28
_vm_map_lookup + 0x17c
_vm_fault + 0x54 (this one looked normal page faulting operation)
_mem_access_fault + 0x1a8
_normal_mem_fault + 0x28

(kgdb) list *vm_object_shadow + 0x28
0xf80cb4cc is in vm_object_shadow (../../../../vm/vm_object.c:911).
906              * The new object shadows the source object.  Our caller changes his
907              * reference to point to the new object, removing a reference to the
908              * source object.
909              */
910             vm_object_lock(source);
911             vm_object_set_shadow(result, source);
912             source->ref_count--;
913             vm_object_unlock(source);
914             
915             /*
(kgdb) 

Jason R. Thorpe                                       thorpej@nas.nasa.gov
NASA Ames Research Center                               Home: 408.866.1912
NAS: M/S 258-6                                          Work: 415.604.0935
Moffett Field, CA 94035                                Pager: 415.428.6939