On Tue, 9 Feb 2010, David Holland wrote:
> On Tue, Feb 09, 2010 at 04:14:58AM +0000, Eduardo Horvath wrote:
> > I'm a bit low on disk space at the moment, but if you build me a generic
> > sparc64 kernel I can test it.
>
> http://www.eecs.harvard.edu/~dholland/tmp/netbsd/ now contains:
>
> SHA1 (netbsd-sparc64-GENERIC.MP.gz) = 0cd34756d2fce2f6deeaa4192a669b0619986d6c
> SHA1 (netbsd-sparc64-GENERIC.gz) = b80187131d38fdb1689443692ea8970dd87dfe1f
>
> Get them while they're hot :-)
>
> (They are straight from my lfs tree, which was synced with HEAD at
> around 2230Z on 20100206. I dunno offhand if sparc64 was expected to
> work then or not. Usual provisos about accepting kernels over the
> internet apply, although if my build machine is owned I'm in a lot of
> trouble...)
I tried out the MP kernel. The system booted properly and mounted the lfs
filesystems. Then I fired up a -j4 kernel build which worked fine until
the link phase where this happened:
1 0 311448 4800 1663 3 3 147 207 271 22 84 1221 1978 419 25 38
36
trap type 0x34: cpu 0, pc=14a5f40 npc=14a5f44
pstate=0xffffffff99820006<PRIV,IE>
kernel trap 34: mem address not aligned
Stopped in pid 9851.1 (sh) at netbsd:uvm_pageactivate: lduh
[
%o0 + 0x54], %g1
db{0}> tr
data_access_fault(d269840, 30, 1009cdc, da50000, da50000, d266000) at
netbsd:dat
a_access_fault+0xc4
?(40c14900, da50000, 40000, d269ce8, d266000, da50000) at 0x10086c8
execve1(0, da50000, d1b5468, 0, 0, e608c00) at netbsd:execve1+0x36c
syscall_plain(d269ed0, d269f58, 409416a0, 409416a4, ffffffff, d269dc0) at
netbsd
:syscall_plain+0x138
?(40c14b00, 40c149b0, 40c14a08, 40c16f56, 6e, 40c14b00) at 0x1008c28
db{0}>
db{0}> show reg
tstate 0x9982000601
pc 0x14a5f40 uvm_pageactivate
npc 0x14a5f44 uvm_pageactivate+0x4
ipl 0
y 0
g0 0
g1 0x1
g2 0x1497d60 uao_get
g3 0xd810ce8
g4 0x169c510 aobj_pager
g5 0xca50000
g6 0
g7 0
o0 0x1
o1 0
o2 0xd269660
o3 0xd269668
o4 0
o5 0x2
o6 0xd268c41
o7 0x149b7cc uvm_fault_internal+0xbcc
l0 0xbd7840000
l1 0xfffcf828ff
l2 0xffffffffffffff00
l3 0
l4 0xe0018000ff
l5 0xffffffffffffff00
l6 0xc00
l7 0
i0 0x256740000
i1 0
i2 0x4100
i3 0x2000
i4 0xf000000
i5 0x18c180000
i6 0xd26850100
i7 0x14da3cc00
I'm not sure I trust the stacktrace since the fault appears to have
happened here:
db{0}> x/i 14a5f40
netbsd:uvm_pageactivate: lduh [%o0 + 0x54], %g1
Eduardo
