From: Disconnect <lkml@sigkill.net>
To: lkml <linux-kernel@vger.kernel.org>
Subject: Re: Oops with 2.4.23
Date: Mon, 22 Dec 2003 13:36:12 -0500 [thread overview]
Message-ID: <1072118172.7007.32.camel@slappy> (raw)
In-Reply-To: <20031222120557.A21530@netdirect.ca>
On Mon, 2003-12-22 at 12:05, Chris Frey wrote:
> At what point do people start suspecting the kernel?
Immediately. Maybe. My problems seem to have been two-fold ('seem to'
because it could take up to a week to hit..). First, the memory timings
listed by Kingston for this ram were way too aggressive for the ram+mobo
combo. (FWIW, for anyone tracking this from the other thread, the epox
"if your motherboard sucks, use these" timings worked much better, and I
left cas at 2 instead of the epox-suggested 2.5. Oh, and memtest86
reported an -increase- in memory bandwidth with those settings.) And
second, the kernel didn't have erratta fixes and workarounds that MS
operating systems use to get io-apic running and stable, acpi stable,
etc...
> I mean, I would hope the linux kernel is not so badly written as to stress
> the machine 24/7. So after 12 hours of running memtest86 with clean
> results, does that not begin to point to a software error rather than
> hardware?
Depends on the tests. See my earlier results (and, if you want some
light reading, the memtest86 technical docs on the website) as an
example of why its important to run the full tests before fully
'certifying' a problem as software. (Even though mine passed standard
tests, it failed extended. And, for that matter, it passed both when I
first built it, before I put an OS on it.)
Evidently many people can look at an oops or crash path and be 90%
certain its bad/misperforming memory. (How they do this I don't
know..) I've noticed that 'check your ram' is not always given as the
answer, but it seems that most of the time when it is given its also
correct.
--
Disconnect <lkml@sigkill.net>
next prev parent reply other threads:[~2003-12-22 18:36 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-12-18 8:56 Oops with 2.4.23 Arnaud Fontaine
2003-12-18 11:47 ` Marcelo Tosatti
2003-12-18 13:06 ` Arnaud Fontaine
2003-12-18 19:08 ` Mike Fedyk
2003-12-19 12:26 ` Arnaud Fontaine
2003-12-19 22:44 ` Arnaud Fontaine
2003-12-19 23:35 ` Maciej Zenczykowski
2003-12-19 23:55 ` Mike Fedyk
2003-12-22 10:07 ` Marc Bevand
2003-12-22 16:37 ` Disconnect
2003-12-21 7:54 ` Arnaud Fontaine
[not found] ` <Pine.LNX.4.58L.0312211238420.6632@logos.cnet>
2003-12-21 15:49 ` Arnaud Fontaine
2003-12-22 2:17 ` Barry K. Nathan
2003-12-22 17:05 ` Chris Frey
2003-12-22 18:36 ` Disconnect [this message]
2003-12-22 18:50 ` Mike Fedyk
2003-12-22 21:37 ` Barry K. Nathan
2003-12-23 14:13 ` Jesper Juhl
-- strict thread matches above, loose matches on Subject: below --
2003-12-19 16:09 Xose Vazquez Perez
2003-12-22 18:06 Xose Vazquez Perez
2003-12-22 18:44 ` Mike Fedyk
2003-12-22 18:53 ` Xose Vazquez Perez
2003-12-23 15:07 ` Arnaud Fontaine
2003-12-23 20:21 ` Xose Vazquez Perez
2003-12-28 14:00 ` Arnaud Fontaine
2003-12-28 21:49 ` James Bourne
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=1072118172.7007.32.camel@slappy \
--to=lkml@sigkill.net \
--cc=linux-kernel@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox