On Sat, Jun 05, 2004 at 03:08:06PM +0200, Manuel Bouyer wrote:
> Hi,
> I initially posted this to port-sparc, but I wonder if it may be a MI problem
> that could affect other ports with alignement contraint.
> 
> I get this under moderate load on a sparc IPX 2.0_BETA (moderate = one or 2
> kernel compiles, + some perl processes from mrtg or spamassassin) which was
> solid when it was running 1.6.x.
> 
> login: trap type 0x7: pc=0xf01c4090 npc=0xf01c4094 psr=ffffffff908010c3<EF,S,PS>
> kernel: alignment fault trap
> Stopped in pid 24633.1 (perl) at        netbsd:uvmfault_anonget+0x4:    sethi           %
> hi(0xf02e3000), %l6
> db> tr
> uvmfault_anonget(0xf335ee50, 0xf33a0d78, 0xf2fe1790, 0x5, 0x9, 0xf347c330) at ne
> tbsd:uvm_fault+0x464
> uvm_fault(0xf335ede4, 0x5, 0x7, 0xf335ee70, 0x1, 0xf335ee10) at netbsd:mem_acces
> s_fault+0x178
> mem_access_fault(0x9, 0x80, 0x10259364, 0x101cfeb0, 0x2400042, 0xf335efb0) at 0x
> f00062f4

I got a variant of this:
trap type 0x7: pc=0xf01c4090 npc=0xf01c4094 psr=ffffffff908010c5<EF,S,PS>
kernel: alignment fault trap
panic: alignment fault
Begin traceback...
0x0(0x7, 0x908010c5, 0xf01c4090, 0xf383dc80, 0x700, 0x7b3040) at 0xf000640c
0xf000640c(0xf383de10, 0xf0ad9324, 0x14, 0xf329ebd8, 0xf329ec08, 0xf34975b8) at 
netbsd:amap_lookups+0x44
amap_lookups(0xf383de50, 0xf3494290, 0xf2ff6ec0, 0x5, 0x9, 0xf38491f8) at netbsd
:uvm_fault+0x464
uvm_fault(0xf383dde4, 0x5, 0x7, 0xf383de70, 0x1, 0xf383de10) at netbsd:mem_acces
s_fault+0x178
mem_access_fault(0x9, 0x80, 0x10259364, 0x101cfeb0, 0x2400042, 0xf383dfb0) at 0x
f00062f4
End traceback...
db> tr/t 0t27346
[...]
trap(0x7, 0x908010c5, 0xf01c4090, 0xf383dc80, 0x700, 0x7b3040) at 0xf000640c
0xf000640c(0xf383de10, 0xf0ad9324, 0x14, 0xf329ebd8, 0xf329ec08, 0xf34975b8) at netbsd:amap_lookups+0x44
amap_lookups(0xf383de50, 0xf3494290, 0xf2ff6ec0, 0x5, 0x9, 0xf38491f8) at netbsd:uvm_fault+0x464
uvm_fault(0xf383dde4, 0x5, 0x7, 0xf383de70, 0x1, 0xf383de10) at netbsd:mem_access_fault+0x178
mem_access_fault(0x9, 0x80, 0x10259364, 0x101cfeb0, 0x2400042, 0xf383dfb0) at 0xf00062f4

(gdb) l *(amap_lookups+0x44)
0xf01bff8c is in amap_lookups (uvm_amap_i.h:100).
95                      amap->am_nslot, 0);
96      
97              if ((slot + (npages - 1)) >= amap->am_nslot)
98                      panic("amap_lookups: offset out of range");
99      
100             memcpy(anons, &amap->am_anon[slot], npages * sizeof(struct vm_anon *));
101     
102             UVMHIST_LOG(maphist, "<- done", 0, 0, 0, 0);
103             return;
104     }

-- 
Manuel Bouyer <bouyer@antioche.eu.org>
     NetBSD: 26 ans d'experience feront toujours la difference
--