Re: port-sparc64/39868: kernel trap 34: mem address not aligned

[Manuel Bouyer <bouyer%antioche.eu.org@localhost>]

On Sat, Nov 22, 2008 at 03:45:02PM +0000, Martin Husemann wrote:
> The following reply was made to PR port-sparc64/39868; it has been noted by 
> GNATS.
> 
> From: Martin Husemann <martin%duskware.de@localhost>
> To: gnats-bugs%NetBSD.org@localhost
> Cc: 
> Subject: Re: port-sparc64/39868: kernel trap 34: mem address not aligned
> Date: Sat, 22 Nov 2008 16:41:32 +0100
> 
>  What are the "variants"? Different backtrace?

Yes, at last the 2 I inclued in the PR. I've also seen these traces (thanks
rtty's logs :):
kernel trap 34: mem address not aligned
Stopped in pid 0.27 (system) at netbsd:pmap_page_protect+0x268: ld            
  [
%l1 + 0x8], %g2
db> tr
genfs_do_putpages(e2c1838, 1, a, 1, 0, a) at netbsd:genfs_do_putpages+0x964
genfs_putpages(bf6b9b0, b95b1a0, b95b1a0, 0, 0, 0) at netbsd:genfs_putpages+0x24
VOP_PUTPAGES(e2c1838, 0, 0, 0, 0, a) at netbsd:VOP_PUTPAGES+0x6c
uvm_vnp_setsize(e2c1838, 0, 0, 0, 0, 0) at netbsd:uvm_vnp_setsize+0x88
ffs_truncate(16, 281d800, 0, 0, ffffffff, 0) at netbsd:ffs_truncate+0x1060
ufs_inactive(0, 12, b95b1a0, 251b, 0, 0) at netbsd:ufs_inactive+0x27c
VOP_INACTIVE(e2c1838, bf6bccf, 1892c00, bf6bcc8, e0018000, 800000) at 
netbsd:VOP_INACTIVE+0x54
vrelel(e2c1838, 0, b95b1a0, 0, bf6bd3c, 281d800) at netbsd:vrelel+0xe8
handle_workitem_remove(2c09980, b95b1a0, b95b1a0, 1, e0018000, 0) at 
netbsd:handle_workitem_remove+0xfc
softdep_process_worklist(0, b95b1a0, b95b1a0, 0, 0, 187e800) at 
netbsd:softdep_process_worklist+0x10c
sched_sync(1815400, 1815400, 1896c00, 1885400, 1885400, 1885400) at 
netbsd:sched_sync+0x134
lwp_trampoline(f0075db8, fffa3cf8, 111800, 1106c8, fffa3df8, 1) at 
netbsd:lwp_trampoline+0x8

Stopped in pid 0.27 (system) at netbsd:vmark+0x18:      st              %g2, 
[%g1 + 0x7c]
db> tr
VFS_SYNC(c79e400, 3, b949ed8, 10, 0, 4000030) at netbsd:VFS_SYNC+0x14
sync_fsync(0, 12, 1, 1, 0, 0) at netbsd:sync_fsync+0x60
VOP_FSYNC(b96da40, b949ed8, 8, 0, 0, e0018000) at netbsd:VOP_FSYNC+0x70
sched_sync(1815400, 1815400, 1896c00, 1885400, 1885400, 1885400) at 
netbsd:sched_sync+0x188
lwp_trampoline(f0075db8, fffa3cf8, 111800, 1106c8, fffa3df8, 1) at 
netbsd:lwp_trampoline+0x8

Stopped in pid 26861.1 (cc1plus) at     netbsd:pool_get+0x234:  st           
%g1, [%g2 + 0x4]
db> tr
cache_enter(ccbe710, e899ae0, ca75d24, ca75a20, 0, 23338e) at 
netbsd:cache_enter+0x254
ufs_lookup(5c, 3fff, 1, ca75d24, 0, 200) at netbsd:ufs_lookup+0x7c4
VOP_LOOKUP(ccbe710, ca75d10, ca75d24, 11641d58, 0, bfe4c14) at 
netbsd:VOP_LOOKUP+0x24
lookup(0, 20002, ca75b0c, 20, 0, bfe4c00) at netbsd:lookup+0x328
namei(0, 0, ca75d24, ca75d00, 14, 1) at netbsd:namei+0xe4
vn_open(0, 603, 1a4, ffffa9ac, 40482800, bfc04e0) at netbsd:vn_open+0x74
sys_open(0, ca75dd0, ca75e10, 1, 0, ffffaa88) at netbsd:sys_open+0x84
syscall_plain(ca75ed0, ca75f58, 404f47b0, ca75dd0, 0, 4) at 
netbsd:syscall_plain+0x138
?(ffffb384, 602, 1b6, 5c2d0, 0, 0) at 0x1008c9c

For this one I also did a 'sh reg':
db> sh reg
tstate      0
pc          0
npc         0
ipl         0
y           0
g0          0
g1          0
g2          0
g3          0
g4          0
g5          0
g6          0
g7          0xffffffff
o0          0
o1          0
o2          0
o3          0
o4          0
o5          0
o6          0
o7          0
l0          0
l1          0x700
l2          0
l3          0x404f47b4
l4          0x1879190   namecache_pool
l5          0x233a8e
l6          0
l7          0xca75900
i0          0xfd3c580
i1          0xfd3ca50
i2          0x111724f0
i3          0xbfc04e0
i4          0x10
i5          0x700
i6          0xe
i7          0xca7594e
f0          0x2487e98
f2          0
f4          0x1
f6          0x298b43c
f8          0xfffffffc
f10         0x1522bc4   vop_getpages_desc
f12         0
f14         0
f16         0xffffffff
f18         0
f20         0x66666666
f22         0x66663832
f24         0
f26         0
f28         0
f30         0
f32         0x1
f34         0x1
f36         0
f38         0xffffffff
f40         0
f42         0
f44         0
f46         0
f48         0xffffffff
f50         0
f52         0
f54         0x313266
f56         0
f58         0
f60         0x8
f62         0x1
fsr         0xca75510
gsr         0xca755a9

I also have in the log:
Stopped in pid 0.27 (system) at netbsd:pmap_page_protect+0x268: ld           
[%l1 + 0x8], %g2
db> tr
genfs_do_putpages(de71e20, 1, a, 1, 0, a) at netbsd:genfs_do_putpages+0x964
genfs_putpages(bc919b0, b65b1a0, b65b1a0, 0, 0, 0) at netbsd:genfs_putpages+0x24
VOP_PUTPAGES(de71e20, 0, 0, 0, 0, a) at netbsd:VOP_PUTPAGES+0x6c
uvm_vnp_setsize(de71e20, 0, 0, 0, 0, 0) at netbsd:uvm_vnp_setsize+0x88
ffs_truncate(16, 2543800, 0, 0, ffffffff, 0) at netbsd:ffs_truncate+0x1060
ufs_inactive(0, 12, b65b1a0, 572a, 0, 0) at netbsd:ufs_inactive+0x27c
VOP_INACTIVE(de71e20, bc91ccf, 1892c00, bc91cc8, e0018000, 800000) at 
netbsd:VOP_INACTIVE+0x54
vrelel(de71e20, 0, b65b1a0, 0, bc91d3c, 2543800) at netbsd:vrelel+0xe8
handle_workitem_remove(2bdc360, b65b1a0, b65b1a0, 1, e0018000, 0) at 
netbsd:handle_workitem_remove+0xfc
softdep_process_worklist(0, b65b1a0, b65b1a0, 0, 0, 187e800) at 
netbsd:softdep_process_worklist+0x10c
sched_sync(1815400, 1815400, 1896c00, 1885400, 1885400, 1885400) at 
netbsd:sched_sync+0x134
lwp_trampoline(f0075db8, fffa3cf8, 111800, 1106c8, fffa3df8, 1) at 
netbsd:lwp_trampoline+0x8
db> sh reg
tstate      0x8
pc          0
npc         0
ipl         0
y           0
g0          0
g1          0
g2          0
g3          0
g4          0
g5          0
g6          0
g7          0xffffffff
o0          0
o1          0
o2          0
o3          0
o4          0
o5          0
o6          0
o7          0
l0          0
l1          0
l2          0x1893000   uvmexp+0x120



>  With the case you have shown, what are the register values (%o1 and %o2
>  being the most interesting)? Could you build a netbsd.gdb and show
>  the line numbers?

I can. But given the number of different cases I wonder if it could
be a memory corruption.

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