Re: unhooking lfs from ufs

[Eduardo Horvath <eeh%NetBSD.org@localhost>]

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