Re: UltraSPARC III... Stability issue ?

On Thu, 17 Apr 2014, Mouse wrote:

> >> (gdb) disass 0x101017c
> >> Dump of assembler code for function data_miss:
> 
> >>    0x0000000001010178 <+120>:   ldxa  [ %g6 ] #ASI_PHYS_USE_EC, %g4
> >>    0x000000000101017c <+124>:   brgez,pn   %g4, 0x10101b8 <data_nfo>
> >>    0x0000000001010180 <+128>:   or  %g4, 0x200, %g7
> 
> > There's no way that's the faulting instruction.  There's either some
> > sort of mismatch between the kernel you're running and the one you
> > disassembled, or the faulting address is not really 0x101017c.
> 
> It occurs to me that a fault on the ldxa could occur late and show the
> next instruction's address, in a heavily pipelined machine.  I don't
> know whether any sparc64s fit that description, and I don't know what
> ASI_PHYS_USE_EC space's semantics are, but it might be worth at least a
> quick look at %g6, if the value as of the fault is available....

You're right.  Trap type 32 is a data_access_error trap.  Accoring to the 
USIII manual it can be either a precise or deferred trap:

> > data error type 32 sfsr=808000 sfva=40cea070 afsr=100000000000
> > afva=472636d83a0 tf=0x1644a7ed0

The fault valid bit (bit 0) is not set in the SFSR, so this was probably a 
deferred trap.  Unfortunately the USIII manual does not describe the bits 
in the ASFR register so it's difficult to say what "100000000000" means.  
However, 472636d83a0 does not look like a valid DRAM physical address.

Eduardo