I had similar problems from -current of a couple of weeks ago.
	Recompiled this weekend and has been rock solid since (not
	that its really been that long)

		David/absolute

                -=-  "Just when everything was making sense"  -=-

On Wed, 27 May 1998, Brad Spencer wrote:

> 
> Hello...
> 
> Given an IPX with 28MB of memory, after updating the system to
> 1.3-fairly_current I have seen 2 panics indicating an 'alignment fault'.
> This seems to happen under load when things being to swap.  Here is some
> information from gdb:
> 
> elrond% gdb netbsd.gdb
> GDB is free software and you are welcome to 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.
> GDB 4.16 (sparc-netbsd), Copyright 1996 Free Software Foundation, Inc...
> (gdb) target kcore /usr/crash/netbsd.2.core
> panic: alignment fault
> #0  mi_switch () at ../../../../kern/kern_synch.c:631
> 631             cpu_switch(p);
> (gdb) where
> #0  mi_switch () at ../../../../kern/kern_synch.c:631
> #1  0xf00261f0 in bpendtsleep () at ../../../../kern/kern_synch.c:370
> #2  0xf00410bc in biowait (bp=0xf0247438) at ../../../../kern/vfs_bio.c:811
> #3  0xf00a5eb8 in uvm_swap_io (pps=0x3, startslot=-268169216, npages=1, 
>     flags=1048576) at ../../../../uvm/uvm_swap.c:1763
> #4  0xf00a5c24 in uvm_swap_get (page=0xf018d638, swslot=8415, flags=2)
>     at ../../../../uvm/uvm_swap.c:1630
> #5  0xf0097968 in uao_get (uobj=0xf00f06e8, offset=4028159544, pps=0xf00e5ce0, 
>     npagesp=0xf00e5ce0, centeridx=0, access_type=0, advice=1, flags=0)
>     at ../../../../uvm/uvm_aobj.c:929
> #6  0xf00993d8 in uvm_fault (orig_map=0x4, vaddr=4052901888, fault_type=2, 
>     access_type=7) at ../../../../uvm/uvm_fault.c:1281
> #7  0xf0099a2c in uvm_fault_wire (map=0xf00f0730, start=4052897792, 
>     end=4052905984) at ../../../../uvm/uvm_fault.c:1692
> #8  0xf0099f2c in uvm_swapin (p=0xf037ca00) at ../../../../uvm/uvm_glue.c:360
> #9  0xf009a0c8 in uvm_scheduler () at ../../../../uvm/uvm_glue.c:438
> #10 0xf00192cc in main () at ../../../../kern/init_main.c:412
> (gdb) 
> 
> 
> The machine usually runs well, but there is a chance that it does not like
> the 72 pin memory from my Intel box and I don't know if the above is a
> software bug or a hardware problem.
> 
> [I also have a SS2 with the same OS edition, but with less memory that
> does swap and have not seen this panic there].
> 
> Ideas welcome, core dumps and the like available upon request.
> 
> Thanks...
> 
> 
> 
> Brad Spencer - brad@anduin.eldar.org   http://anduin.eldar.org
> [finger brad@anduin.eldar.org for PGP public key]
>