From: Jeff Epler <jepler@inetnebr.com>
To: linux-kernel@vger.kernel.org
Subject: Re: Defective Red Hat Distribution poorly represents Linux
Date: Tue, 21 Nov 2000 15:50:27 -0600 [thread overview]
Message-ID: <20001121155027.I7090@inetnebr.com> (raw)
In-Reply-To: <200011202032.eAKKWQi06469@pincoya.inf.utfsm.cl> <3A1AE442.E8C83873@the-rileys.net>
In-Reply-To: <3A1AE442.E8C83873@the-rileys.net>; from oscar@the-rileys.net on Tue, Nov 21, 2000 at 04:08:26PM -0500
On Tue, Nov 21, 2000 at 04:08:26PM -0500, David Riley wrote:
> Windoze is not the only OS to handle bad hardware better than Linux. On
> my Mac, I had a bad DIMM that worked fine on the MacOS side, but kept
> causing random bus-type errors in Linux. Same as when I accidentally
> (long story) overclocked the bus on the CPU. I think that more
> tolerance for faulty hardware (more than just poorly programmed BIOS or
> chipsets with known bugs) is something that might be worth looking into.
And how do you propose to do that?
For instance, in some other operating systems having the top bit flip
in a pointer will cause silent use of incorrect data. On Linux, this
will cause a signal 11. Which do you prefer, bad results or an error
message?
Can you suggest a specific way in which Linux can react correctly to
e.g. flipped bits in RAM or cache which cannot be detected at the hardware
level? Or maybe tell me how Linux can react correctly when an overclocked
CPU starts producing incorrect results for right shifts once every few
thousand instructions?
There exists hardware specifically intended to be able to diagnose and
contain its own failures, but the number of such features on a common
home PC is probably a big fat zero.
> I'm sure it would solve problems like this (which I clearly identify as
> a hardware problem, because the same thing happened with the bad DIMM,
> the overclocked bus, and two different overclocked processors (AMD 5x86
> and AMD K6-2 500) and went away when I remedied the offending problem).
And that's what you have to do --- fix the problem. In a few situations,
you might be able to isolate and exclude the section of RAM which is
bad (in fact, there are patches for this and tools to diagnose the
problem), but what do you want Linux to do about a processor which cannot
reliably execute instructions?
> Additionally, overclockers (I myself am a reformed one) might appreciate
> more tolerance for such things.
I've got a better idea: Overclockers can go to hell, and their bug reports
to the trash, until they "reform" like you and I have.
Jeff
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
next prev parent reply other threads:[~2000-11-21 22:20 UTC|newest]
Thread overview: 46+ messages / expand[flat|nested] mbox.gz Atom feed top
2000-11-20 13:53 Defective Red Hat Distribution poorly represents Linux Charles Turner, Ph.D.
2000-11-20 14:00 ` Mohammad A. Haque
2000-11-20 14:05 ` Andreas Jaeger
2000-11-20 14:10 ` Tigran Aivazian
2000-11-20 16:13 ` Bernhard Rosenkraenzer
2000-11-20 17:18 ` Tigran Aivazian
2000-11-20 18:19 ` Mohammad A. Haque
2000-11-20 21:11 ` Ben Ford
2000-11-20 18:04 ` Charles Turner, Ph.D.
2000-11-20 18:22 ` John Jasen
2000-11-20 18:44 ` Mohammad A. Haque
2000-11-20 20:32 ` Horst von Brand
2000-11-21 21:08 ` David Riley
2000-11-21 20:43 ` Gérard Roudier
2000-11-21 21:46 ` Bob Lorenzini
2000-11-21 21:50 ` Jeff Epler [this message]
2000-11-21 22:27 ` David Riley
2000-11-21 22:31 ` Richard Torkar
2000-11-21 23:17 ` David Riley
2000-11-22 3:28 ` Jeff Epler
2000-11-22 20:35 ` David Riley
2000-11-22 11:02 ` Richard Torkar
2000-11-23 1:40 ` Was:Defective Red Hat Distribution poorly represents Linux, running with failed hardware? Richard.Reynolds
2000-11-21 21:52 ` Defective Red Hat Distribution poorly represents Linux Horst von Brand
2000-11-21 22:04 ` David Lang
2000-11-21 21:34 ` David Riley
2000-11-21 22:01 ` Horst von Brand
2000-11-21 22:11 ` Dan Hollis
2000-11-21 22:21 ` Gerd Knorr
2000-11-21 22:21 ` David Lang
2000-11-20 21:16 ` Ben Ford
2000-11-21 0:41 ` Fort David
2000-11-20 19:37 ` Mohammad A. Haque
2000-11-20 19:42 ` Andre Hedrick
2000-11-20 19:52 ` Paul Fulghum
2000-11-20 23:01 ` spam
2000-11-20 14:16 ` Gregory Maxwell
2000-11-20 14:50 ` Whiner spams linux-kernel (Re: Defective Red Hat Distribution poorly represents Linux) Jes Sorensen
2000-11-20 15:48 ` Defective Red Hat Distribution poorly represents Linux Bernhard Rosenkraenzer
2000-11-20 17:00 ` Werner Almesberger
2000-11-20 17:31 ` Jeff V. Merkey
2000-11-20 19:33 ` Frank van Maarseveen
2000-11-22 17:26 ` Anthony Liu
2000-11-20 20:15 ` Igmar Palsenberg
2000-11-21 5:53 ` Albert D. Cahalan
2000-11-21 8:16 ` Peter Samuelson
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=20001121155027.I7090@inetnebr.com \
--to=jepler@inetnebr.com \
--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