On Tue, 14 Sep 1999, David S. Miller wrote:

> The dumps seem to be corrupted, it is very crucial for the initial
> oops generated to be completely visible and decoded.  Once the
> first oops happens, the only thing that can really be said about
> subsequent oopses are that they are due to corrupted state generated
> in the first oops, it's difficult then to reason about the true cause.

Ok, now I'm sure I include the first one, but also the rest, just in case.

> Also, are you getting correctable ECC memory errors in your kernel
> logs before this happens?  I am very close to starting to encourage

If it should log anything, I don't get it. No errors in the logs or the
console but the ones I include.

> users to return these AXi boards to Sun and asking for fixed parts
> which do not generate these ECC memory errors.  They addresses
> generating the ECC errors are always at the same exact spot, with the
> same ECC syndrome, regardless of how you arrange the simms.  This is a
> motherboard hardware bug without a doubt, and I'm imagining that a
> large set of AXi boards produced in the past half year have this
> problem. :-(

In fact these are Sparc compatible, but they have passed Sun the hardware
compatibility tests -twice :)-
And they don't fail with Solaris 2.7 :(((
I got 2 of them replaced, but the problems didn't disappear.

> I know this issue has never turned up on any other UltraSparc's,
> because if they did the machine would lock up at bootup and people
> would have told me about it :-)

Well, maybe with the new logs you can reach other conclusions.
If you need to know the gcc compiler used, the prom settings or something
else, just ask it.

Thanks
Pau