[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
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.
Main Index |
Thread Index |