Re: [Gems-users] ATMTP: Problem with strange Transaction-Aborts

[Philipp Tölke <toelke+gems@xxxxxxxxx>]

Hi Everyone,

>> Did your compiled benchmark have TLB warm up or TLB miss handling?
> 
> I don't think so.

I do now :-)

[cpu0] v:0x00000000000134f4 p:0x000301774f4  chkpt 0x13504
[cpu0] v:0x00000000000134f8 p:0x000301774f8  nop
[cpu0] v:0x00000000000134fc p:0x000301774fc  ba 0x13508
[cpu0] v:0x0000000000013500 p:0x00030177500  mov 1, %o0
[cpu0] v:0x0000000000013508 p:0x00030177508  mov %o0, %l0
[cpu0] v:0x000000000001350c p:0x0003017750c  stw %l0, [%fp + -4]
[cpu0] v:0x0000000000013510 p:0x00030177510  mov %l0, %i0
[cpu0] v:0x0000000000013514 p:0x00030177514  jmpl [%i7 + 8], %g0
[cpu0] v:0x0000000000013518 p:0x00030177518  restore %g0, %g0, %g0
[cpu0] v:0x0000000000025b88 p:0x00036c65b88  ldd [%sp + 160], %f62
[cpu0] v:0x0000000000025b8c p:0x00036c65b8c  orcc %g0, %o0, %g0
[cpu0] v:0x0000000000025b90 p:0x00036c65b90  ldd [%sp + 168], %f0
[cpu0] v:0x0000000000025b94 p:0x00036c65b94  ldd [%sp + 224], %f32
[cpu0] v:0x0000000000025b98 p:0x00036c65b98  ldd [%sp + 216], %f22
[cpu0] v:0x0000000000025b9c p:0x00036c65b9c  ldd [%sp + 232], %f58
[cpu0] v:0x0000000000025ba0 p:0x00036c65ba0  ldd [%sp + 200], %f28
[cpu0] v:0x0000000000025ba4 p:0x00036c65ba4  ldd [%sp + 176], %f48
[cpu0] v:0x0000000000025ba8 p:0x00036c65ba8  ldd [%sp + 184], %f36
[cpu0] v:0x0000000000025bac p:0x00036c65bac  ldd [%sp + 192], %f26
[cpu0] v:0x0000000000025bb0 p:0x00036c65bb0  ldd [%sp + 208], %f50
[cpu0] v:0x0000000000025bb4 p:0x00036c65bb4  bne,pn %icc, 0x25c28
[cpu0] v:0x0000000000025bb8 p:0x00036c65bb8  lduw [%l2 + 0], %l1
[cpu0] v:0x0000000000025c28 p:0x00036c65c28  ldd [%i1 + 176], %f60
[cpu0] v:0x0000000001001660 p:0x00007401660  retry
6826445428   0 [0,0] TID -1 XACT ABORT 0 caused by 0 [ 0, 0 ] xid: 0
address: [0x0, line 0x0] delay: 6826445428  PC [0x0, line 0x0]  *PC 0x0
'illtrap 0'

> I am concerned about two points:
> - in the above error-message, there are only zeros.

This still holds.

> - after this message, the simulation hangs. ^C^C cancels the simulation,
>   but not in a recoverable way

This still holds.

Is this consistent with a TLB-Miss? Why does the simulation fail after
this?

Thank you!

Regards,
-- 
Philipp Tölke

Attachment: signature.asc
Description: Digital signature