Re: Memory/data errors
Sad Clouds <[email protected]>
| Newsgroups | gmane.os.netbsd.ports.sparc64 |
|---|---|
| Message-ID | <[email protected]> |
On Mon, 19 Mar 2018 22:06:34 +0000 (UTC) Eduardo Horvath <[email protected]> wrote: > On Mon, 19 Mar 2018, Sad Clouds wrote: > > > On Mon, 19 Mar 2018 16:15:56 +0000 (UTC) > > Eduardo Horvath <[email protected]> wrote: > > > > > On Sun, 18 Mar 2018, Sad Clouds wrote: > > > > > > > Mar 15 17:53:42 ultra10 /netbsd: data error type 32 sfsr=0 > > > > sfva=425de020 afsr=400008 afva=17ff7b6fbf8 tf=0x1186c7ed0 > > > > > > Trap type 32 is a memory access error fault. It happens when > > > trying to access a device fails. > > > > > > Since the synchronous fault status register (SFSR) is zero, the > > > contents of SFVA is probably irrelevent. > > > > > > The AFSR, however, does have interesting values, so the AFVA is > > > probably valid. Ths AFSR has the EDP bit set which indicates data > > > parity in the E$ SRAM. Bit 3 in the syndrome is set pointing to > > > data bits 31-24. > > > > > > The memory coherence domain on ultrasparc processors is the E$. > > > Since neither the UE nor CE bits are set, this is probably not > > > indicative of bad DRAM. And the AFSR is not updated when the EDP > > > bit is set. > > > > > > The EDP bit indicates an ECC error on data read. > > > > > > I'd say either your E$ SRAM is dying, or some operation is causing > > > the contents of the E$ SRAM to get corrupted. > > > > > > Eduardo > > > > OK thanks for the info. I have a spare CPU from another Ultra 10, > > which I can try. Maybe that one is still OK. > > I don't think the E$ SRAM is on-chip. > > Eduardo I think it is all part of the same CPU module https://sep.yimg.com/ay/mxsun/440mhz-sun-ultra-5-10-ultrasparc-iii-cpu-module-p-n-501-5149-5.gif I've just swapped the module and running build.sh. Let's see what happens next.