From: <pau@readysoft.es>
To: ultralinux@vger.kernel.org
Subject: Re: bug in 2.2.13pre7 on Ultras (more oops)
Date: Wed, 15 Sep 1999 07:23:15 +0000 [thread overview]
Message-ID: <marc-linux-ultrasparc-93738047523759@msgid-missing> (raw)
[-- Attachment #1: Type: TEXT/PLAIN, Size: 1691 bytes --]
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
[-- Attachment #2: Type: APPLICATION/octet-stream, Size: 4814 bytes --]
next reply other threads:[~1999-09-15 7:23 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
1999-09-15 7:23 pau [this message]
1999-09-15 7:34 ` bug in 2.2.13pre7 on Ultras (more oops) David S. Miller
1999-09-15 7:42 ` pau
1999-09-15 8:10 ` David S. Miller
1999-09-15 10:10 ` pau
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=marc-linux-ultrasparc-93738047523759@msgid-missing \
--to=pau@readysoft.es \
--cc=ultralinux@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.