Linux & Pentium FDIV bug
Elan Feingold
Hey, Linux could be the first OS to print:
Testing FDIV...OK! or
Testing FDIV...Bug found! Call 1-800-xxx-xxxx.
elan
--
===============================================================================
|| Elan Feingold (Cornell '94) || "Two of the most famous products of ||
|| Software Engineer II || Berkeley are LSD and BSD. I don't ||
|| Digital Equipment Corporation || think that is a coincidence." ||
|| Work: 603.881.1115 || - Anonymous ||
===============================================================================
Linus Torvalds
Elan Feingold <fein...@avette.zko.dec.com> wrote:
>
>Hey, Linux could be the first OS to print:
>
>Testing FDIV...OK! or
>Testing FDIV...Bug found! Call 1-800-xxx-xxxx.
My kernel (and thus the 1.1.66 release) already does this:
Checking 386/387 coupling... Ok, FDIV bug i586 system
(and yes, that's a paste from my messages log: my university pentium
machine has the bug).
Linus
Rafal Maszkowski
> In article <3b0ajj$b...@jac.zko.dec.com>,
> Elan Feingold <fein...@avette.zko.dec.com> wrote:
> >Hey, Linux could be the first OS to print:
> >Testing FDIV...OK! or
> >Testing FDIV...Bug found! Call 1-800-xxx-xxxx.
> My kernel (and thus the 1.1.66 release) already does this:
> Checking 386/387 coupling... Ok, FDIV bug i586 system
Great! Would it be very difficult to add catching of FDIV to the kernel
(like it is in the emulator) and call 1/x * (always or only for some
arguments - if it is worth to differenciate) instead?
R.
--
Rafal Maszkowski r...@oso.chalmers.se http://www.mat.uni.torun.pl/~rzm
Opinia publiczna powinna byc zaalarmowana swoim nieistnieniem - St. J. Lec
Linus Torvalds
Rafal Maszkowski <r...@dain.oso.chalmers.se> wrote:
>Linus Torvalds (torv...@cc.Helsinki.FI) wrote:
>>
>> My kernel (and thus the 1.1.66 release) already does this:
>> Checking 386/387 coupling... Ok, FDIV bug i586 system
>
>Great! Would it be very difficult to add catching of FDIV to the kernel
>(like it is in the emulator) and call 1/x * (always or only for some
>arguments - if it is worth to differenciate) instead?
It wouldn't be impossible, but it's not something I will do: this isn't
a problem to be solved by the OS, but by Intel or the user. The fdiv
bug isn't a problem for most people, and for those that it is, it's more
efficient to make the compiler do the bug work-around instead.
Note that doing it in the kernel would mean trapping for *every* fp
operation, and that's not good for a fp-intensive program: and the main
programs which /would/ care about the fdiv bug are the fp-intensive
ones.
At least now (or with the next kernel version, to be exact), linux will
warn about the problem, so that users who need to take care will know to
do so. Note: if you don't know whether you'd need to fix it, you most
probably don't need to worry about fdiv.
Linus
Tim Smith
>
>Hey, Linux could be the first OS to print:
>
>Testing FDIV...OK! or
>Testing FDIV...Bug found! Call 1-800-xxx-xxxx.
It can be the first to check for the Pentium bug, but it won't be the
first OS to check for a processor bug. Interactive Unix checked for
some 386 bugs, if I recall correctly. I'm not sure if these checks were
in the released kernels, though. They may have been taken out once
Intel got past the very first version of the chip, and that happened
before Unix was finished.
--Tim Smith
Nick Kralevich
Linus Torvalds <torv...@cc.Helsinki.FI> wrote:
>My kernel (and thus the 1.1.66 release) already does this:
>
> Checking 386/387 coupling... Ok, FDIV bug i586 system
This may be a stupid question (since I haven't seen 1.1.66 yet).
Supposedly a patch has come out for GCC working around the bug
in the Pentinum chip. If we compile the kernel with that patch, isn't
there the possibility that the test will be optimized out/worked
around by the compiler? If so, that would defeat the testing for the
FDIV bug.
Take care,
-- Nick Kralevich
nick...@cory.eecs.berkeley.edu
--
Nick Kralevich nick...@cory.eecs.berkeley.edu
"A man sits with a pretty girl for an hour and it seems shorter than
a minute. But tell that same man to sit on a hot stove for a minute,
it is longer than any hour. That's relativity." -- Einstein
Frank Lofaro
>In article <3b43r0$r...@nyheter.chalmers.se>,
>Rafal Maszkowski <r...@dain.oso.chalmers.se> wrote:
>>Linus Torvalds (torv...@cc.Helsinki.FI) wrote:
>>>
>>> My kernel (and thus the 1.1.66 release) already does this:
>>> Checking 386/387 coupling... Ok, FDIV bug i586 system
>>
>>Great! Would it be very difficult to add catching of FDIV to the kernel
>>(like it is in the emulator) and call 1/x * (always or only for some
>>arguments - if it is worth to differenciate) instead?
>
>It wouldn't be impossible, but it's not something I will do: this isn't
>a problem to be solved by the OS, but by Intel or the user. The fdiv
Unfortunately, it seems Intel is _NOT_ going to solve it.
(from what I heard)
I heard if you've got a bad chip, they won't give you a free
replacement, I have even heard that they won't even give you any credit
whatsoever. They'll just tell you to buy a new one from them, at full price.
This could really anger a lot of people, things may be looking very good
for AMD, NextGen, etc. And very bad for Intel. Umm, I don't think they
stand a very good chance of getting into the scientific computing market
like they wanted. It has been said, the bug strikes rarely. In some
ways thats worse, an occasional error goes unnoticed far longer. Lord
only knows how many scientifc calculations have been hosed by the
drop in precision.
Many scientific users are not in a position to fix or even
understand the bug, they'll just know something is broken.
They program in FORTRAN, for heaven's sake! :) :)
>bug isn't a problem for most people, and for those that it is, it's more
>efficient to make the compiler do the bug work-around instead.
>
Probably true. Maybe even hack the assembler instead so asm
programs could work (disgusting I know).
What can one do about commercial software/software without source. I
can't trust commercial software companies to care about the bug, since
new Pentiums don't have it, and they might just say: "you are paying
a lot of the software, so you can afford a new Pentium..., its
a hardware bug, and its not our problem. Or, you have the OS source,
hack the OS, we don't want to bother messing with our code"
>Note that doing it in the kernel would mean trapping for *every* fp
>operation, and that's not good for a fp-intensive program: and the main
>programs which /would/ care about the fdiv bug are the fp-intensive
>ones.
How much of a slow down would that cause? Anyone know how many clock
cycles that would use? Maybe make it an option for those needing
precision, even at cost of some (a lot? I don't know) speed.
That way linux can compensate for Intel's _severe_ brain-damage.
It would be bad to have bought a Pentium, and to have it be useless
for what you need to do. It makes a pretty expensive space heater. :)
>
>At least now (or with the next kernel version, to be exact), linux will
>warn about the problem, so that users who need to take care will know to
>do so. Note: if you don't know whether you'd need to fix it, you most
>probably don't need to worry about fdiv.
>
> Linus
Maybe someone ought to write a translator that would replace fdiv
with an invalid sequence (replace the 0xdc 0xf1 with some unique illegal
opcode. Or hack the assembler to generate that for fdiv. Then make the
linux trap routine do an emulated fdiv there.
I admit, getting the hardware bug fixed is the best option, but may
not be practical.
For example, look at the floppies. The hardware is often terrible (*)
but the Linux code has been made to work around the bugs. (as of 1.1.65,
it seems to have done a very good job. It even handles my FDC which lies
about its version...)
* Like saying the disk isn't write protected even when it is, if the drive
motor is off. Why do some floppies (like mine) give a wrong result like
that? And that's not the whole of it... Like the fact the disk change
line stays active on my drive, even if I do a seek/recalibrate
unless _actual head movement_ occurs. And the fact recalibrate only
steps 78 tracks before saying it failed, etc, etc...
Frank Lofaro
Probably not, since Linus' test almost certainly uses inline assembly
to make sure fdiv is done. I don't think GCC will mess with inline
assembly, and probably even less likely since the inline assembly
used in the kernel has a volatile tag, which often means don't optimize.
Michele Bini
[ About changing the kernel to work around Pentium FDIV bug ]
: How much of a slow down would that cause? Anyone know how many clock
: cycles that would use? Maybe make it an option for those needing
: precision, even at cost of some (a lot? I don't know) speed.
: That way linux can compensate for Intel's _severe_ brain-damage.
: It would be bad to have bought a Pentium, and to have it be useless
: for what you need to do. It makes a pretty expensive space heater. :)
The slowdown will be terrible. Don't know exactly (I don't have a
Pentium reference at hand) but it will slow things a lot, let's say
down to the order of magnitude of FPU emulator (you will need to trap
all FPU instructions). As I see it, if you do FPU computations then
you can't afford such a slowdown (and, I'm afraid, you will have to
buy a new Pentium, goddamn Intel), while if you don't then you don't
care of the bug.
: Maybe someone ought to write a translator that would replace fdiv
: with an invalid sequence (replace the 0xdc 0xf1 with some unique illegal
: opcode. Or hack the assembler to generate that for fdiv. Then make the
: linux trap routine do an emulated fdiv there.
Although this will help performance compared to trapping any FPU
instruction (but not too much: FDIV is quite common), it is unfeasible
(the binary translator) or really the wrong thing to do (the hacked
assembler): binary distributions will come out with fdiv replaced with
a kernel trap, which will slow things down even for those with a
working Pentium. Not a good thing to do. Before doing something like
that consider this: how many Pentium have been sold before the bug was
corrected? How many after? How many will be sold from now on? How many
users will be happy of such a change? How many will not? How many
don't care (i.e. don't have Pentium or don't do FPU computations?)
: For example, look at the floppies. The hardware is often terrible (*)
: but the Linux code has been made to work around the bugs. (as of 1.1.65,
: it seems to have done a very good job. It even handles my FDC which lies
: about its version...)
This is because working around all those ugly FDC doesn't slow things
down too much. Remember you are dealing with a floppy, so things will
be slow anyway. But a FDIV takes only a handful of cycles to
complete...
--
Michele Bini:
bi...@cli.di.unipi.it
http://www.cli.di.unipi.it/~bini/intro
Theodore Ts'o
Date: 23 Nov 1994 21:01:39 GMT
Hey, Linux could be the first OS to print:
Testing FDIV...OK! or
Testing FDIV...Bug found! Call 1-800-xxx-xxxx.
Actually.... how about?
Testing FDIV... Bug found! Disabling FPU, using FPU emulator....
- Ted
Mike Kenney
Nick Kralevich <nick...@po.EECS.Berkeley.EDU> wrote:
>In article <3b4237$3...@klaava.Helsinki.FI>,
>Linus Torvalds <torv...@cc.Helsinki.FI> wrote:
>>My kernel (and thus the 1.1.66 release) already does this:
>>
>> Checking 386/387 coupling... Ok, FDIV bug i586 system
>
>This may be a stupid question (since I haven't seen 1.1.66 yet).
>Supposedly a patch has come out for GCC working around the bug
>in the Pentinum chip. If we compile the kernel with that patch, isn't
>there the possibility that the test will be optimized out/worked
>around by the compiler? If so, that would defeat the testing for the
>FDIV bug.
I don't believe a compiler can work around this problem. The problem
only manifests itself with certain input values to FDIV ... lets face
it, if you are doing serious number crunching (not sure a Pentium is the
best system for that job anyway :-), sooner or later you will need to
use FDIV and you may get bitten. All of our Pentiums have the bug but
it hasn't affected the few simulations we run on them.
The only solution is a replacement CPU from Intel. I haven't heard what
their official policy is on replacements ... I think it would be a PR
disaster for them to not offer free replacements.
--
Mike Kenney
mi...@apl.washington.edu
Arnt Gulbrandsen
Mike Kenney <mi...@wavelet.apl.washington.edu> wrote:
>I don't believe a compiler can work around this problem.
Michael Meissner's new patches appear to do this, however. H.J. Lu
asked on one of the mailing lists for assembler code to check for
the bug since his compiler worked right - he has the new,
not-yet-released, gcc.
This is why some hackers are called 'wizards'.
--Arnt
Michael Stroucken
> It wouldn't be impossible, but it's not something I will do: this isn't
> a problem to be solved by the OS, but by Intel or the user. The fdiv
> bug isn't a problem for most people, and for those that it is, it's more
> efficient to make the compiler do the bug work-around instead.
I just read, that Intel is refusing to replace chips unless you
*really, really, really* need a chip that can perform math
that correctly.
Greetings,
Michael.
--
Michael Stroucken stro...@lm.com mstr...@nox.cs.du.edu MUD+IRC: Stroucki
Phil Howard
| This may be a stupid question (since I haven't seen 1.1.66 yet).
| Supposedly a patch has come out for GCC working around the bug
| in the Pentinum chip. If we compile the kernel with that patch, isn't
| there the possibility that the test will be optimized out/worked
| around by the compiler? If so, that would defeat the testing for the
| FDIV bug.
You can always use inline assembly code.
--
Phil Howard KA9WGN | The drive spec says the capacity is 600mb unformatted
Unix/Internet/Sys Admin | and 525mb formatted. So where do I find an unformat
CLR/Fast-Tax | utility?
ph...@fasttax.com |
pag...@netcom.com
Windows 3.x's win386.exe file checks for the 386 bugs, but those
chips were very early ones which were replaced for free.
BTW, in the Linux Journal I think they listed a LILO option
which caused the floating point emulator to be used even in favor
of a coprocessor... which could help here.
- Chad Page
Harald Koenig
> >This may be a stupid question (since I haven't seen 1.1.66 yet).
> >Supposedly a patch has come out for GCC working around the bug
> >in the Pentinum chip. If we compile the kernel with that patch, isn't
> >there the possibility that the test will be optimized out/worked
> >around by the compiler? If so, that would defeat the testing for the
> >FDIV bug.
> Probably not, since Linus' test almost certainly uses inline assembly
> to make sure fdiv is done. I don't think GCC will mess with inline
> assembly, and probably even less likely since the inline assembly
> used in the kernel has a volatile tag, which often means don't optimize.
and i think (and hope) that there never will be such an official gcc
version since it would habe to check *every* FDIV result to catch an error
which occurs ~1 or 1000000 times. thats a performace hog.
get your pentium fixed or live with the bug!
Harald
--
All SCSI disks will from now on ___ _____
be required to send an email notice 0--,| /OOOOOOO\
24 hours prior to complete hardware failure! <_/ / /OOOOOOOOOOO\
\ \/OOOOOOOOOOOOOOO\
\ OOOOOOOOOOOOOOOOO|//
Harald Koenig, \/\/\/\/\/\/\/\/\/
Inst.f.Theoret.Astrophysik // / \\ \
koe...@tat.physik.uni-tuebingen.de ^^^^^ ^^^^^
Jeff Uphoff
MK> The only solution is a replacement CPU from Intel. I haven't heard what
MK> their official policy is on replacements ... I think it would be a PR
MK> disaster for them to not offer free replacements.
Remember the great Tylenol-cyanide scare of the early 80's? It cost
them millions, but the only way that the manufacturers could get
consumer confidence back was to pull _every bottle_ of extra-strength
Tylenol capsules from the shelves. Tylenol sales eventually rebounded
and the long-term effect of this policy was very positive.
Intel will be cutting its own throat if they don't offer free
replacements.
Then again...does Microsoft offer a free replacement every time somebody
figures out how to tickle a bug in Windows? And look how much they are
"trusted" by the consumers.
Go figure...
--
Jeff Uphoff -- "Uppie" | jup...@nrao.edu
National Radio Astronomy Observatory | jeff....@linux.org
520 Edgemont Road | http://tarsier.cv.nrao.edu/~juphoff/
Charlottesville, VA 22903, USA | (804) 296-0208
Derek Snider
: Unfortunately, it seems Intel is _NOT_ going to solve it.
: (from what I heard)
: I heard if you've got a bad chip, they won't give you a free
: replacement, I have even heard that they won't even give you any credit
: whatsoever. They'll just tell you to buy a new one from them, at full price.
: This could really anger a lot of people, things may be looking very good
: for AMD, NextGen, etc. And very bad for Intel. Umm, I don't think they
: stand a very good chance of getting into the scientific computing market
: like they wanted. It has been said, the bug strikes rarely. In some
: ways thats worse, an occasional error goes unnoticed far longer. Lord
: only knows how many scientifc calculations have been hosed by the
: drop in precision.
: Many scientific users are not in a position to fix or even
: understand the bug, they'll just know something is broken.
: They program in FORTRAN, for heaven's sake! :) :)
: >bug isn't a problem for most people, and for those that it is, it's more
: >efficient to make the compiler do the bug work-around instead.
: >
: Probably true. Maybe even hack the assembler instead so asm
: programs could work (disgusting I know).
: What can one do about commercial software/software without source. I
: can't trust commercial software companies to care about the bug, since
: new Pentiums don't have it, and they might just say: "you are paying
: a lot of the software, so you can afford a new Pentium..., its
: a hardware bug, and its not our problem. Or, you have the OS source,
: hack the OS, we don't want to bother messing with our code"
We found out Intel's attitude when we complained about our faulty i586
chip... and I think our company intends to sue Intel... :)
---------------------------------------------------------------------
Telnet to our mud ... Realms of Despair ---> mud.compulink.com 4000
Or join our International Teleconference ---> chat.compulink.com 9000
David Hedley
: Then again...does Microsoft offer a free replacement every time somebody
: figures out how to tickle a bug in Windows? And look how much they are
: "trusted" by the consumers.
I wish they would :-) But at least with software problems, it is possible
to get round them - by running a proper operating system for one! Hardware
bugs are a different kettle of fish - there is _no_ escape from them. I can
see great problems in the future if I decide to sell my Pentium. The first
question that anybody will ask me is 'Does the Pentium have the FDIV bug?'
and will expect some form of price reduction when I reply 'Yes'.
I intend to wait until Intel get their act together and start producing
bug-free chips (yes it may well be a long wait), and then take my machine
back and get the processor changed while it's still under warranty....
David
--
+--------------------------------------------------------------------------+
| David Hedley (David....@bris.ac.uk) | All programmers are playwrights |
| Computer Graphics Group | and all computers are lousy |
| University of Bristol | actors |
| England | - Anon |
| *** All opinions expressed are mine and mine alone *** |
+--------------------------------------------------------------------------+
Joseph Stanley (Joe) Wisniewski
|> "MK" == Mike Kenney <mi...@wavelet.apl.washington.edu> writes:
|>
|> MK> The only solution is a replacement CPU from Intel. I haven't heard what
|> MK> their official policy is on replacements ... I think it would be a PR
|> MK> disaster for them to not offer free replacements.
|>
|> Remember the great Tylenol-cyanide scare of the early 80's? It cost
|> them millions, but the only way that the manufacturers could get
|> consumer confidence back was to pull _every bottle_ of extra-strength
|> Tylenol capsules from the shelves. Tylenol sales eventually rebounded
|> and the long-term effect of this policy was very positive.
|>
|> Intel will be cutting its own throat if they don't offer free
|> replacements.
Intel has a long history of system killing bugs, and it's generally worse
than pulling teeth to get them to replace a buggy processor. I've personally
been the victem of the 80286 that had extended flag bits that didn't work.
It ran DOS fine, but crashed XENIX. I had a 386 that was also fine with DOS,
but couldn't do a 32 bit multiply when I got a 32 bit C compiler. And, I've
run into 386's that couldn't switch into and out of protected mode. That's
about the time that Intel stopped putting date codes (that humans could
read) on their processors, and started using an encrypted serial number, to
keep customers from knowing that they had chips with bugs that may not be
giving them problems right now, but could turn nasty with the next new
operating system or application.
486 and Pentium both have their share of bugs. I don't use Pettiums, and
my 486's have not had a bug that killed anything I'm currently running.
Tomorrow may bring all sorts of happy suprises. ;-)
|> Then again...does Microsoft offer a free replacement every time somebody
|> figures out how to tickle a bug in Windows? And look how much they are
|> "trusted" by the consumers.
There are many of free software bug fixes on Microsoft's BBS and FTP site.
It's much more difficult to patch a buggy processor.
|> Go figure...
--
Joseph S. Wisniewski | The views expressed are purely my own, and do not
Ford Motor Company | reflect those of the Ford Motor Company, or any of
Project Sapphire | its affiliates.
w...@rcsg30.eld.ford.com | "any color you want -- as long as it's black"
Van Zandt
>486 and Pentium both have their share of bugs. I don't use Pettiums, and
>my 486's have not had a bug that killed anything I'm currently running.
I wasn't aware of bugs in the 486. What are they? Is there a test
program?
- Jim Van Zandt
Markus Kuhn
>like they wanted. It has been said, the bug strikes rarely. In some
>ways thats worse, an occasional error goes unnoticed far longer. Lord
>only knows how many scientifc calculations have been hosed by the
>drop in precision.
>Many scientific users are not in a position to fix or even
>understand the bug, they'll just know something is broken.
>They program in FORTRAN, for heaven's sake! :) :)
If you do real scientific calculation for critical things, then you should
ALWAYS include checks. There are much more serious problems in
scientific computations (namely round-off and instability) than
the FDIV bug, and for these, you already have to include double-checks.
If you just solved A * x = b, then testing the equation with the result
doesn't hurt, right?
This isn't the first serious bug a Intel processor had, it is just the first
bug that was discovered by a user (a scientist who coded carefully and
included numeric checks). Intel itself has published lots of bugs of
the i386 versions, and AMD has found many more while reverse engineering
the chip. But it will be the first bug which will cost Intel a LOT of
reputation, because this will go through the press ... ;-)
Markus
---
Markus Kuhn, Computer Science student -- University of Erlangen,
Internet Mail: <msk...@cip.informatik.uni-erlangen.de> - Germany
WWW Home: <http://wwwcip.informatik.uni-erlangen.de/user/mskuhn>
Arnt Gulbrandsen
I don't know about 486 bugs either, but my linux kernel tells me that
This processor honours the WP bit even when in supervisor mode. Good.
and
Checking 'hlt' instruction... Ok.
so I assume that at least some [345]86 processors have bugs relating
to the MMU and the HLP instruction.
--Arnt
Michael Blair Mathers
: and the long-term effect of this policy was very positive.
: Intel will be cutting its own throat if they don't offer free
: replacements.
uhh, perhaps, but I think the competition in the microprocessor market is a
bit more heated.. Intel is already falling behind. I think the amount
of money that it would cost them would be fatal in the long run.. From what
I've heard, they don't plan on any kind of replacement plan. (except for
Ford who just bought a load of Pentiums) They plan on playing down the
significance of the bug.. (which for the home PC user will not be too much
of a problem, but for the workstation and scientific communities it could be
disastrous)
-Mike
Mark D. Roth
>uhh, perhaps, but I think the competition in the microprocessor market is a
>bit more heated.. Intel is already falling behind. I think the amount
>of money that it would cost them would be fatal in the long run.. From what
>I've heard, they don't plan on any kind of replacement plan. (except for
>Ford who just bought a load of Pentiums) They plan on playing down the
>significance of the bug.. (which for the home PC user will not be too much
>of a problem, but for the workstation and scientific communities it could be
>disastrous)
I just saw an article on clarinet that said that Intel announced their
intentions to fully warranty any Pentium processor with this bug.
They even established a special 1-800 number for people to talk to
them about it.
--
ro...@uiuc.edu | Mark D. Roth | http://www.cen.uiuc.edu/~mr4342/
(GEEK CODE 2.1) GCS d-- H+ s++:- g+ p1>4+ !au a-- w++@ v-(*)
C++>$ UL+>++++ P--- L++>+++ 3 E(-) N++ K++ W--- M-- V-
po Y+ t++@ 5+ !j R-- G tv b+ D+ B--- e+(*) u+@ h>++ f+ r@ n+@ y?
Tim Smith
> BTW, in the Linux Journal I think they listed a LILO option
>which caused the floating point emulator to be used even in favor
>of a coprocessor... which could help here.
Any floating point wizards out there willing to make a hacked version
of the floating point emulator that includes the FDIV bug? That would
be great for those of us with 486s who want to play with the bug!
--Tim Smith
S. Lee
Mark D. Roth <ro...@ux4.cso.uiuc.edu> wrote:
>
>I just saw an article on clarinet that said that Intel announced their
>intentions to fully warranty any Pentium processor with this bug.
>They even established a special 1-800 number for people to talk to
>them about it.
Read more closely. It's only for those "heavily involved in
engineering..." (or some such). I've seen the Andy Grove message and it
doesn't look good, either. You'd better check out comp.sys.intel...
Stephen
Marco van den Boogaard
>"MK" == Mike Kenney <mi...@wavelet.apl.washington.edu> writes:
>MK> The only solution is a replacement CPU from Intel. I haven't heard what
>MK> their official policy is on replacements ... I think it would be a PR
>MK> disaster for them to not offer free replacements.
>Remember the great Tylenol-cyanide scare of the early 80's? It cost
>them millions, but the only way that the manufacturers could get
>consumer confidence back was to pull _every bottle_ of extra-strength
>Tylenol capsules from the shelves. Tylenol sales eventually rebounded
>and the long-term effect of this policy was very positive.
>Intel will be cutting its own throat if they don't offer free
>replacements.
>Then again...does Microsoft offer a free replacement every time somebody
>figures out how to tickle a bug in Windows? And look how much they are
>"trusted" by the consumers.
That's because most of _their_ consumers don't know what a real OS should or should not do correctly,
but then, Windows isn't even an OS, it still needs DOS.......
People who know more about computers and OS's really _don't_ trust MS. Myself I wouldn't give them a
penny.
>Go figure...
>--
>Jeff Uphoff -- "Uppie" | jup...@nrao.edu
>National Radio Astronomy Observatory | jeff....@linux.org
>520 Edgemont Road | http://tarsier.cv.nrao.edu/~juphoff/
>Charlottesville, VA 22903, USA | (804) 296-0208
--
|\/| Marco van den Boogaard | It's nice to be
_| _| marc...@sci.kun.nl | slightly crazy
|/|), University of Nijmegen | (== weird)
|) |
Marco van den Boogaard
>Linus Torvalds (torv...@cc.Helsinki.FI) wrote:
>> It wouldn't be impossible, but it's not something I will do: this isn't
>> a problem to be solved by the OS, but by Intel or the user. The fdiv
>> bug isn't a problem for most people, and for those that it is, it's more
>> efficient to make the compiler do the bug work-around instead.
>I just read, that Intel is refusing to replace chips unless you
>*really, really, really* need a chip that can perform math
>that correctly.
I guess they will behave like insurance people: "Well, you don't _really_ need it, you can do this
very significant calculation with FPU emulation, so why should we give you a brand new Pentium?",
thus turning down (almost) all claims that are not made by powerful institutions (I guess they would
be very polite to the Pentagon for example (if they are stupid enough to buy Intel there)).
>Greetings,
>Michael.
Greetings,
Marco
>--
>Michael Stroucken stro...@lm.com mstr...@nox.cs.du.edu MUD+IRC: Stroucki
Marco van den Boogaard
[stuff deleted]
>If you do real scientific calculation for critical things, then you should
>ALWAYS include checks. There are much more serious problems in
>scientific computations (namely round-off and instability) than
>the FDIV bug, and for these, you already have to include double-checks.
>If you just solved A * x = b, then testing the equation with the result
>doesn't hurt, right?
>This isn't the first serious bug a Intel processor had, it is just the first
>bug that was discovered by a user (a scientist who coded carefully and
>included numeric checks). Intel itself has published lots of bugs of
>the i386 versions, and AMD has found many more while reverse engineering
>the chip. But it will be the first bug which will cost Intel a LOT of
>reputation, because this will go through the press ... ;-)
If they go on like this, they will never get big on the scientifical market, which I believe is one
of the things they want most. Guess they will be making processors only for private,
not-world-shocking purposes.
>Markus
Marco (actually the same name ;-) )
>---
>Markus Kuhn, Computer Science student -- University of Erlangen,
>Internet Mail: <msk...@cip.informatik.uni-erlangen.de> - Germany
>WWW Home: <http://wwwcip.informatik.uni-erlangen.de/user/mskuhn>
Ulrich Kunitz
I wouldn't call the handling of the WP bit in supervisor mode a bug of
the 386. It's just a thing that is handled in the 486 more reasonable.
There is a flag in the 486 controlling compability. Linux doesn't use
it because the verify_area() routines can be programmed faster with the new
behaviour. I never dealt with the halt instruction.
I remember reading a interview with Intel developers in Byte. They
stated that they find a bug in the layout of the 386 during software
simulation of the 486 where they get different behaviour.
Bugs in Microprocessors wasn't a problem as long there was only
manufacturer marketing one processor at the time. Nowadays things are
more difficult at the PC market: several manufacturers and a lot of
compatible but different processors. Manufacturers are running expensive
simulation tests to boot DOS/Windows or a PC-UNIX. In the mentioned
interview is has been said that it takes 2 weeks to get the DOS prompt
in a 486 software simulation.
Uli
--
I know tha >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> t in my
heart I f >>>> Ulrich Kunitz >>>> kun...@informatik.hu-berlin.de >>>> eel like
going ho >>>> >>>> Voice: (030) 513 11 52 >>>> me again
But I k <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< now ...
Constantine Triantafillou
>-Mike
Well, I don't think an ordinary PC is a good solution for solving
scientific, problems..A workstation is a better choice....
Constantine
--
*******************************************************************
*Constantine Triantafillou e-mail: tri...@pegasus.montclair.edu*
*"HELLAS=Science,Arts,Civilization,Democracy" *
*******************************************************************
Jim Nance
> In <3bfhs...@uni-erlangen.de> msk...@cip.informatik.uni-erlangen.de (Markus Kuhn) writes:
>
> If they go on like this, they will never get big on the scientifical market, which I believe is one
> of the things they want most. Guess they will be making processors only for private,
> not-world-shocking purposes.
I doubt they really care. The scientific/engineering market is tiny compared to
the nontechnical computer market. It always amazes me when I walk into a computer
store and almost all the computers have 486/SX processors, but I guess that most
people really do not use applications that require that much math.
Jim
Niranjan Perera
>math...@cps.msu.edu (Michael Blair Mathers) writes:
>
>>uhh, perhaps, but I think the competition in the microprocessor market is a
>>bit more heated.. Intel is already falling behind. I think the amount
>>of money that it would cost them would be fatal in the long run.. From what
>>I've heard, they don't plan on any kind of replacement plan. (except for
>>Ford who just bought a load of Pentiums) They plan on playing down the
>>significance of the bug.. (which for the home PC user will not be too much
>>of a problem, but for the workstation and scientific communities it could be
>>disastrous)
>
>I just saw an article on clarinet that said that Intel announced their
>intentions to fully warranty any Pentium processor with this bug.
>They even established a special 1-800 number for people to talk to
>them about it.
Intel has no plans to replace the chip. If you ask them to replace the
chip be prepared to justify why it needs to replaced for you..., in
general if you are using your pentium to play games, and other stuff
INTEL will not replace it for you.
-- Niranjan
--
+----------------------------------------------------------------------~~~-----+
| Niranjan Perera. per...@gis.lislab.uga.edu INTEL: GARBAGE INSIDE (o O ) |
+-----------------------------------------------------------------ooO-(_)-Ooo--+
Jeff Uphoff
CT> Well, I don't think an ordinary PC is a good solution for solving
CT> scientific, problems..A workstation is a better choice....
Discounting all the current FDIV hubbub, this is not a true statement
IMHO--it all depends on what you call a "good solution." The
Astronomical Image Processing System, a massive scientific and
mathematically intensive package, gets comparable or superior
performance (time-wise) for identical moderately-sized tasks on a
Pentium-90, compared to a Sun SPARCstation 2 or IPX. (This is the
backbone package for Radio Astronomy.)
That's workstation performance, and a good solution for those that don't
want to buy a workstation or that already have a decent PC sitting
around.
--
Jeff Uphoff -- "Uppie" | jup...@nrao.edu
National Radio Astronomy Observatory | jeff....@linux.org
520 Edgemont Road | http://linux.nrao.edu/~juphoff/
John R. Campbell
>"MK" == Mike Kenney <mi...@wavelet.apl.washington.edu> writes:
>MK> The only solution is a replacement CPU from Intel. I haven't heard what
>Intel will be cutting its own throat if they don't offer free
>replacements.
I liked your commentary equating this to tylenol.
>Then again...does Microsoft offer a free replacement every time somebody
>figures out how to tickle a bug in Windows? And look how much they are
>"trusted" by the consumers.
Maybe it's because we *expect* such S/W to be buggy. If you don't expect
something that works right, you don't complain too much when you get a
turkey.
--
------------------------------------------------------------------------------
John R. Campbell, Speaker to Machines | Grace is sufficient;
so...@penrij.UUCP, soup%pen...@kd3bj.ampr.org | Joy is now unemployed.
so...@sonosam.wisdom.bubble.org <-- not anymore! | - Heather Campbell
Christopher K. St. John
>Years ago I ran DOS on an 8086 simulator on my Atari ST, and it took
>significantly less than 2 weeks to get a DOS prompt :-)
I think they simulate individual gates, not individual instructions...
--
----------------------------------------------------------------------
- christopher kelly st. john - c...@crl.com -
----------------------------------------------------------------------
S. Joel Katz
>jup...@tarsier.cv.nrao.edu (Jeff Uphoff) writes:
>>"MK" == Mike Kenney <mi...@wavelet.apl.washington.edu> writes:
>>MK> The only solution is a replacement CPU from Intel. I haven't heard what
>>Intel will be cutting its own throat if they don't offer free
>>replacements.
>I liked your commentary equating this to tylenol.
>>Then again...does Microsoft offer a free replacement every time somebody
>>figures out how to tickle a bug in Windows? And look how much they are
>>"trusted" by the consumers.
>Maybe it's because we *expect* such S/W to be buggy. If you don't expect
>something that works right, you don't complain too much when you get a
>turkey.
I love this theory. So Intel is refusing to replace the chips so
people will learn to _expect_ their chipps to be buggy in the future?
--
S. Joel Katz Information on Objectivism, Linux, 8031s, and more
Stim...@Panix.COM is available at http://www.panix.com/stimpson/
Time flies like an arrow -- fruit flies like a banana.
Joseph Stanley (Joe) Wisniewski
The Apple, Motorola, and IBM marketing people should be looking at this
as a golden opportunity. How about some PowerPC adds that show a PowerPC
delivering right answers faster that a Pentium can deliver wrong ones?
Or some scare tactic commercials where a Pentium math error casues a
major disaster that could have been averted by a PowerPC. (They would
probably not be able to reference the Pentium, or Intel, by name, but
that shouldn't be a problem for a truely clever ad exec). Apple could
even offer a "trade in" special for Intel users that want to switch to
Power Mac. Of course, Apple, IBM, or Motorola could partially sponsor a
horror movie where the Pentium causes a disaster. Jurrasic Park II,
anyone?
Joseph Stanley (Joe) Wisniewski
|> In <3bi69d$n...@hahn.informatik.hu-berlin.de> kun...@informatik.hu-berlin.de (Ulrich Kunitz) writes:
|>
|> >compatible but different processors. Manufacturers are running expensive
|> >simulation tests to boot DOS/Windows or a PC-UNIX. In the mentioned
|> >interview is has been said that it takes 2 weeks to get the DOS prompt
|> >in a 486 software simulation.
|>
|>
|> Years ago I ran DOS on an 8086 simulator on my Atari ST, and it took
|> significantly less than 2 weeks to get a DOS prompt :-)
Wrong kind of simulator. When you simulate a chip down at the transistor
level, and the chip has millions of transistors, the simulation is going
to be amazingly slow. You may have to do millions of calculations for each
nanosecond of simulated time, and even large networks of workstations,
supercomputers, or custom simulation hardware cannot approach real time.
Dan Newcombe
>The Apple, Motorola, and IBM marketing people should be looking at this
>as a golden opportunity. How about some PowerPC adds that show a PowerPC
>delivering right answers faster that a Pentium can deliver wrong ones?
>Or some scare tactic commercials where a Pentium math error casues a
>major disaster that could have been averted by a PowerPC. (They would
>probably not be able to reference the Pentium, or Intel, by name, but
>that shouldn't be a problem for a truely clever ad exec). Apple could
>even offer a "trade in" special for Intel users that want to switch to
>Power Mac. Of course, Apple, IBM, or Motorola could partially sponsor a
>horror movie where the Pentium causes a disaster. Jurrasic Park II,
>anyone?
Yes...we could have the girl from the first one ("It's a Unix system, I know
this.") make a re-appearence:
"Aw..shit...it's an Intel Pentium system...I'll take my chances
with the Raptors."
Seriously, I wonder how many computer companies (ie. Dell, Gateway) have been
called about returns. Are they taking the machines back because of this, or
telling customers to call Intel?
-Dan
--
Dan Newcombe newc...@aa.csc.peachnet.edu
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
"And the man in the mirror has sad eyes." -Marillion
Jonathan I. Kamens
|> Seriously, I wonder how many computer companies (ie. Dell, Gateway) have been
|> called about returns. Are they taking the machines back because of this, or
|> telling customers to call Intel?
The short answer is that Dell's chip replacement policy is currently no
different from Intel's (but see my comment about IBM's policy, near the end of
this message). Here's the long answer, which describes my dealings with Dell
since I found out about the Pentium bug....
I bought a Dell Dimension XPS P90 last month; it arrived on November 7 (which
means that theoretically, my 30-day money-back guarantee extends until
December 7).
When I first heard about the FDIV bug, I had an E-mail exchange with
sup...@dell.com (I've deleted some irrelevant text):
Date: Tue, 22 Nov 1994 00:04:40 -0500
From: "Jonathan I. Kamens" <j...@cam.ov.com>
To: sup...@dell.com
Subject: Technical support call
...
I just heard that a floating-point bug was discovered in the Pentium
CPU, including the P90. Is this true? Is Dell or Intel going to
offer upgrades of fixed CPU chips to people who have CPUs with the
bug?
...
To: "Jonathan I. Kamens" <j...@cam.ov.com>
From: sup...@us.dell.com (Kerry Harrison)
Date: Tue, 22 Nov 1994 10:41:43 Central
...
For the few users actually affected by this problem Intel will be replacing
the CPUs.
...
Date: Tue, 22 Nov 1994 11:47:14 -0500
From: "Jonathan I. Kamens" <j...@cam.ov.com>
To: sup...@us.dell.com
...
How do I know whether or not I'm affected by this problem? Am I
supposed to wait until my software starts giving erratic,
nondeterministic results :-)? Seriously, if I'm doing math stuff that
is affected by this, I might not ever know it, because I'll have no
correct results to compare against.
...
To: "Jonathan I. Kamens" <j...@cam.ov.com>
From: sup...@us.dell.com (Kerry Harrison)
Date: Tue, 22 Nov 1994 11:01:09 Central
...
The problem only shows up in precision mathematic operations in the 9th to
14th decimal places and the chances of it occuring are like 1 in 9 billion.
If you feel that you might be affected by it give tech support a call
(1-800-624-9896).
...
This was before I realized that my machine was still under it's 30-day
guarantee. I subsequently realized that, and sent them this message on
November 27:
Date: Sun, 27 Nov 1994 15:13:53 -0500
From: "Jonathan I. Kamens" <j...@cam.ov.com>
To: sup...@dell.com
Subject: More about my buggy Pentium CPU
...
I realized over the weekend something which didn't occur to me before,
i.e., that my machine is still under its 30-day money-back guarantee
period.
What that means to me is that one of two things can happen at this
point:
1) You can replace my CPU, or
2) I can back up the data I've got on my machine, return it to you for
a refund sans shipping, and then order the same model machine, this
time demanding one with a fixed CPU, now that the problem is known.
In case (1), you're out one CPU, which you'll probably be able to pawn
off on Intel by returning it to them along with the other faulty CPUs
you're returning to them.
In case (2), you can no longer sell my old machine as new, which means
that you have to sell it as reconditioned, so you lose money. I lose
the time it takes to back up this machine, return it, and get a new
one, as well as the cost of shipping this machine, but I'm willing to
do all that in order to get a fixed CPU.
Incidentally, despite Intel's claim, that problem does not only affect
the "9th to 14th decimal places." Someone posted at least one
division on the net which is correct only to the third decimal place
on a buggy Pentium. If it were really true that operations were still
correct up to the 9th decimal place, I probably wouldn't be doing
this.
It may be true that I'm not doing anything on my machine right now
that would be affected by the bug, but I don't know that for a fact,
and I'm not convinced Intel dose either, especially since what they've
been saying about how bad the bug is is a lie. Furthermore, I plan to
have this machine for many years, and I have no idea if I'll be doing
anything in the future that will require precise mathematical
calculations. Therefore, I'm willing to go to some lengths to get a
fixed CPU.
So, what's it going to be? A new CPU or a whole new machine with a
fixed CPU?
...
I have not yet received a response to my message, despite the fact that they
promise in the auto-response to mail to sup...@dell.com a response within 24
hours. I've resent it to them several times, asking when I can expect a
response. My subsequent messages looked like this (each one had the previous
message appended to the bottom of it):
Date: Mon, 28 Nov 1994 21:25:35 -0500
From: "Jonathan I. Kamens" <j...@cam.ov.com>
To: sup...@dell.com
It has been over 24 hours since I sent this message, and I still have
received no response. When can I expect a response?
...
Date: Tue, 29 Nov 1994 19:29:40 -0500
From: "Jonathan I. Kamens" <j...@cam.ov.com>
To: sup...@dell.com
It has now been over 48 hours since I sent my original message, and I
still have received no response.
I was promised 24-hour technical support when I purchased my system.
Why am I not receiving it?
If you cannot either authorize a replacement CPU for me or tell me
that I'm not going to get one (and, as a result, force me to return my
system and ask for a refund), then please give me the E-mail address
or phone number of someone who *can* make that decision.
...
Date: Wed, 30 Nov 1994 23:08:56 -0500
From: "Jonathan I. Kamens" <j...@cam.ov.com>
To: sup...@dell.com
It has now been over 72 hours since I sent the original message below,
and I still haven't received a response.
Furthermore, I just waited in the queue for technical support for over
50 minutes, and didn't get to speak to a human being. I ended up
hanging up to go to sleep. This is a totally unacceptable delay.
I tried to get support via E-mail because I didn't want to sit on hold
for ridiculous amounts of time, but it seems that you are not
responding in a timely manner to either telephone calls or E-mail.
In any case, I ask once again for answers to the following questions:
1) Are you, or are you not, planning on replacing the defective
Pentium CPUs of machines that are still covered by a 30-day
money-back warrantee?
2) Are you, or are you not, planning on replacing the defective
Pentium CPUs of machines that are still covered by a one-year
warrantee?
3) Why have I not received a response to my E-mail in over three days?
4) What is the name and telephone number or E-mail address of the
person to whom I can complain about not receiving a timely response
to my E-mail?
5) Why did I not get to talk to a human being after waiting on
hold for over 50 minutes?
6) What is the name and telephone number or E-mail address of the
person to whom I can complain about waiting over 50 minutes on hold
and still not getting to speak to technical support?
If, when I finally get an answer from you to question (1) above, my
30-day warrantee period has elapsed, and I decide to return the
machine based on your answer, and you refuse to refund my money, I
will sue you for my refund. I have given you more than adequate time
within the warrantee period to respond to my questions. I cannot make
an informed decision about whether or not to return the machine until
I get answers from you, so the ball's in your court.
If you wish to discuss this by telephone, you can reach me at
XXX-XXX-XXXX or XXX-XXX-XXXX.
...
Date: Thu, 1 Dec 1994 09:31:01 -0500
From: "Jonathan I. Kamens" <j...@cam.ov.com>
To: sup...@dell.com
In addition to the points raised in my messages below, to which I have
not yet received a single response, I would like to add one more
point: I just read in the newspaper that IBM is planning on replacing
all flawed Pentium chips in machines they've sold. So, is Dell, which
prides itself on its customer service, going to match IBM's offer, or
not?
Also, last night, before I called technical support and got put on hold for 50
minutes, I called and listened to the recording that Dell has set up for
people who call about the Pentium bug. The one piece of new information I
learned from it is that according to Dell, Intel hasn't yet shipped any fixed
chips to any vendor, despite media reports to the contrary.
Needless to say, I'm mighty ticked off at Dell for not responding to my
E-mail. Does anybody know how I can get in touch with a real human being
inside Dell who can give me a response or get someone else to give me a
response?
Incidentally, is not getting responses to support E-mail and/or waiting on
hold for 50 minutes normal when dealing with Dell? I thought (based on what
I've heard) that their support was better than that, but this is the first
time I've dealt with them directly, because this is the first Dell I've bought.
--
Jonathan Kamens | OpenVision Technologies, Inc. | j...@cam.ov.com
Hank Oxford
: Wonder what is exactly simulated there... a 486 on an 8008? a 4004?
: Years ago I ran DOS on an 8086 simulator on my Atari ST, and it took
: significantly less than 2 weeks to get a DOS prompt :-)
You weren't simulating that 8086 at the gate level.
----------------------------------------------------------------------
Hank Oxford ha...@clark.net
James Ivey
>Seriously, I wonder how many computer companies (ie. Dell, Gateway) have been
>called about returns. Are they taking the machines back because of this, or
>telling customers to call Intel?
I have been unable to reach Comtrade, as of yet.. however, this is
the warranty policy delivered to me with my system. Note the 'free of
defective parts' and 'correct any defects at no charge for labor or
materials' phrases. Three years is a nice period, too.
: Comtrade warrants to the original purchaser that this system hardware
: will be free of defective parts for three (3) year from the date of
: invoice. During this warranty period, Comtrade will correct any
: defects at no charge for labor or materials. Shipping costs must be
: prepaid. The warranty period is not extended as a result of purchasing
: any additional product from us or upgrading an existing Comtrade
: computer. This three year warranty only applies to Comtrade products.
: The standard supplied CTX monitor & hard drive only carry 18-month
: parts warranty by the manutacturers. For CTX monitor support in the
: first 3 months of purchase, contact Comtrade technical support.
: Beyond 3 months, contact CTX directly at (800) 289-2189. Any special
: ordered items such as printers and other brand monitor are warranted
: directly by their original manufacturers and may carry only one year
: warranty. On shipment of replacements products, the customer must
: provide a credit card number and expiration date before the products
: are shipped. If the defective products are not returned within 7 days,
: Comtrade has the authorization to charge your card for the full
: replacement cost. You understanding in this matter is appreciated.
Tom Lynch
> In <3b4ca9$3...@homesick.cs.unlv.edu> ftlo...@unlv.edu (Frank Lofaro) writes:
>
> > >This may be a stupid question (since I haven't seen 1.1.66 yet).
> > >Supposedly a patch has come out for GCC working around the bug
> > >in the Pentinum chip. If we compile the kernel with that patch, isn't
> > >there the possibility that the test will be optimized out/worked
> > >around by the compiler? If so, that would defeat the testing for the
> > >FDIV bug.
>
> > Probably not, since Linus' test almost certainly uses inline assembly
> > to make sure fdiv is done. I don't think GCC will mess with inline
> > assembly, and probably even less likely since the inline assembly
> > used in the kernel has a volatile tag, which often means don't optimize.
>
>
> and i think (and hope) that there never will be such an official gcc
> version since it would habe to check *every* FDIV result to catch an error
> which occurs ~1 or 1000000 times. thats a performace hog.
>
> get your pentium fixed or live with the bug!
> Harald Koenig, \/\/\/\/\/\/\/\/\/
> Inst.f.Theoret.Astrophysik // / \\ \
> koe...@tat.physik.uni-tuebingen.de ^^^^^ ^^^^^
What is needed is to have a gcc switch that would use a Newton-Raphson
divide instead of the fdiv instruction. One could then recompile any
critical libraries and code and to be free of risk from this bug (hey
we do what we can). This would not be much of a performance issue
since NR is pretty fast, and divides are purposely made rare because
they are slow even with the Pentium hardware.
Marek Michalkiewicz
: In <3b8a45$4...@africa.lm.com> stro...@telerama.lm.com (Michael Stroucken) writes:
: >I just read, that Intel is refusing to replace chips unless you
: >*really, really, really* need a chip that can perform math
: >that correctly.
: I guess they will behave like insurance people: "Well, you don't _really_ need it, you can do this
: very significant calculation with FPU emulation, so why should we give you a brand new Pentium?",
: thus turning down (almost) all claims that are not made by powerful institutions (I guess they would
: be very polite to the Pentagon for example (if they are stupid enough to buy Intel there)).
"Well, you don't _really_ need it, you can do this very significant
calculation on an AMD 486DX2-80."
Faster and cheaper than FPU emulation on a Pentium. :-)
Regards,
--
Marek Michalkiewicz
mar...@i17linuxa.ists.pwr.wroc.pl || in...@ci3ux.ci.pwr.wroc.pl
Bryn Paul Arnold Jones
PENTIUM, get together and sue intel until they agree to compensate us or
replace these processors, i'm shore that we could get them to under some
law or other (like goods not as advitised, or selling defective goods,
especially for the units sold after they discovered the bug and decided
to sit on it).
Bryn Jones
Delbert Matlock
>
> I just thought, why don't all the people with the FDIV bug in the
> PENTIUM, get together and sue intel until they agree to compensate us or
> replace these processors, i'm shore that we could get them to under some
Great, then the price for a Pentium would double. Intel would have to
make up the money somewhere.
--dkm
Darin Johnson
> >: significantly less than 2 weeks to get a DOS prompt :-)
>
> >You weren't simulating that 8086 at the gate level.
>
But the thing I don't get is why, when doing a gate level or
lower simulation, that they simulated booting DOS?? It hardly
exercises all, or even a majority of instructions, and the
bugs that are most critical to find are those that would show
up long after there's a large installed base.
--
Darin Johnson
djoh...@ucsd.edu
Gravity is a harsh mistress - The Tick
b...@svusenet.ubs.ch
: "CT" == Constantine Triantafillou <tri...@pegasus.montclair.edu> writes:
: CT> Well, I don't think an ordinary PC is a good solution for solving
: CT> scientific, problems..A workstation is a better choice....
: Discounting all the current FDIV hubbub, this is not a true statement
: IMHO--it all depends on what you call a "good solution." The
: Astronomical Image Processing System, a massive scientific and
: mathematically intensive package, gets comparable or superior
: performance (time-wise) for identical moderately-sized tasks on a
: Pentium-90, compared to a Sun SPARCstation 2 or IPX. (This is the
: backbone package for Radio Astronomy.)
Why do people always compare apples and oranges? The SparcStation 2 and IPX
are old (obsolete machines , they aren't in the SUN price book anymore.
Compare todays Pentiums with todays workstations(eg. SparcStation 5 or 20, or a PowerPc ).
: That's workstation performance, and a good solution for those that don't
Daniel Garcia
>Followup to: <3b5lh5$2...@senator-bedfellow.MIT.EDU>
>> Actually.... how about?
>> Testing FDIV... Bug found! Disabling FPU, using FPU emulator....
>idea). If you are running numerical code, it is too damn slow to use
>the emulator (it means that if you have a buggy chip you're SOL, since
>Intel refuse to fix it). This way, the kernel with let you know about
You really should check things before blurting them like that. Intel HAS
ALREADY FIXED IT! It's in the new masks - and they are in the process
of trying to come up with an easy way to replace chips that are out there,
but for now - if you are working in a situation where you feel you need
the bug fixed - then you can call intel up about a replacement. I've already
got mine working through the pipeline.
D
--
___________________________________________________________________________
/Daniel Garcia/Soon to be PhD Student/dga...@cohl.llnl.gov/ken...@esu.edu /
/Linux Hacker/C Programmer for Hire /#include <disclaimer>/The Answer's 42/|
,-------------+----------------------+---------------------+-------------- + |
|We fool ourselves into believing, that the words of the net carry meaning | |
| more than words on paper - and yet, when no one reads them, words on the | /
| net are 1's and 0's, while the words on paper are still... words. |/
`--------------------------------------------------------------------------'
Jonathan I. Kamens
|> Slaving away in a dark room, h...@nwu.edu (H. Peter Anvin) produced:
|> >the emulator (it means that if you have a buggy chip you're SOL, since
|> >Intel refuse to fix it). This way, the kernel with let you know about
|>
|> You really should check things before blurting them like that. Intel HAS
|> ALREADY FIXED IT!
You really should avoid insulting people for no good reason, when you haven't
tried hard enough to understand what they're trying to say.
I believe Anvin is fully aware that Intel has fixed the bug and is fabricating
new chips as we speak. His point is that Intel's stubbornness about replacing
people's chips is likely to lead to some people who are doing numerical
calculations not meriting a new chip, according to Intel. Hence, for those
people, Intel will "refuse to fix it."
I fully agree with him there -- it seems impossible to me that a policy which
says, "If you think you might have a problem, call us and talk about it with
our `experts,' and we'll give you a new chip if we agree," is going to be able
to replace the chips in all cases where they're actually needed. Some people
are unavoidably going to fall through the cracks.
Jeff Uphoff
b> Why do people always compare apples and oranges? The SparcStation 2 and IPX
b> are old (obsolete machines , they aren't in the SUN price book anymore.
b> Compare todays Pentiums with todays workstations(eg. SparcStation 5 or 20, or a PowerPc ).
I would if I could, but the SPARC 2's and IPX's are the only
*single-processor* Suns we have here that we have AIPS benchmark numbers
for (not counting even older models). I can't very well compare the
Pentium to our SPARC 10/514 or anything of that caliber.
Karl Keyte
>b> Compare todays Pentiums with todays workstations(eg. SparcStation 5 or 20, or a PowerPc ).
>
>I would if I could, but the SPARC 2's and IPX's are the only
>*single-processor* Suns we have here that we have AIPS benchmark numbers
>for (not counting even older models). I can't very well compare the
>Pentium to our SPARC 10/514 or anything of that caliber.
Why not? I did. I was very pleased with my Pentium's performance!
Karl
-------------------------------------------------------------------------
Vitrociset S.p.A. Tel : +(49) 6151 902041
European Space Agency Fax : +(49) 6151 904041
Jeff Uphoff
KK> In article 94DEC5...@TARSIER.CV.NRAO.EDU, jup...@tarsier.cv.nrao.edu (Jeff Uphoff) writes:
>> [...] I can't very well compare the
>> Pentium to our SPARC 10/514 or anything of that caliber.
KK> Why not? I did. I was very pleased with my Pentium's performance!
I'm very pleased with my Pentium's performance too, but it just doesn't
scale as well on these tests as our 4-processor SPARC-10/514 with 176MB
RAM. That's why I said that I couldn't do a decent comparison between
it and the Pentium (which has a piddly 32MB RAM).
--Up.
Karl Runge
> "KK" == Karl Keyte <kke...@esoc.bitnet> writes:
> KK> In article 94DEC5...@TARSIER.CV.NRAO.EDU, jup...@tarsier.cv.nrao.edu (Jeff Uphoff) writes:
> >> [...] I can't very well compare the
> >> Pentium to our SPARC 10/514 or anything of that caliber.
>
> KK> Why not? I did. I was very pleased with my Pentium's performance!
>
> I'm very pleased with my Pentium's performance too, but it just doesn't
> scale as well on these tests as our 4-processor SPARC-10/514 with 176MB
> RAM. That's why I said that I couldn't do a decent comparison between
> it and the Pentium (which has a piddly 32MB RAM).
The Pentium 90 processor is about the same as a SPARC-10/40 (single
processor), at least it is for our floating point dominated sci. computing
codes (our benchmarks are at ftp://redhook.llnl.gov/pub/runge/Bench.out
for a wide range of machines, your mileage will vary though). Don't
know what to say about RAM or other device dominated programs...
Cheers,
Karl
Henry Ware
BogoMips included (bogus^2? After all, they are different
versions of BogoMip). Specin92/specfp92 are from
comp.benchmarks and from www.cern.ch
Lots of stuff from ftp.nosc.mil/pub/aburto/. BogoMips
from the portable BogoMips program and the BogoMips howto.
Pick your favorite meaningless comparision:
Machine specin92 specfp92
SUN/SPARC/5/70 57 47.3
SUN/SPARC/5/85 64 54.6
Pentium 60 65.9 52.4
Pentium 90 86.0 68.3
SUN/SPARC/20/50 69.2 78.3
SUN/SPARC/20/51 65.2 83
SUN/SPARC/20/61 88.9 102.8
The following test are publicly available at ftp.nosc.mil/pub/aburto/
(except for BogoMips).
Drystones:
CPU MIPS MIPS
System OS/Compiler CPU (MHz) V1.1 V2.1 REF
### ---------------------- ------------ ----------- ----- ------------ ---
037 Sun SPARCserver 20/612 Solaris 2.3 SuperSPARC 60.0 93.6 82.2 58
039 Gateway Pentium P5-90 LINUX 1.1.35 Pentium 90.0 80.6 75.9 5
054 SPARCstation Voyager Solaris 2.3 uSPARC II 60.0 61.5 54.8 50
086 Cornell EISA/ISA/VLB LINUX 1.1.23 80486DX2 66.7 35.3 32.2 57
087 LIJN 486DX2/66 LINUX0.99pl6 80486DX2 66.7 ------ 31.3 22
088 Gateway 486DX2/66 LINUX 0.99 80486DX2 66.7 ------ 30.9 3
Heapsort:
CPU HIGH
System OS CPU (MHz) MIPS REF
### ---------------------- ------------------ ---------- ----- ----------
019 Gateway Pentium P5-90 LINUX 1.1.35 Pentium 90.0 52.21 58
035 Sun SPARCserver 20/612 Solaris 2.3 SuperSPARC 60.0 39.79 57
038 ALR Pentium/60 MS DOS 5.0 Pentium 60.0 37.61 35
100 DTK 486DX/50 LINUX 0.99 80486DX 50.0 17.96 11
101 SPARCstation 2 (50) SunOS 4.1.3 SPARC 50.0 17.88 47
nseive: [ this shows cache flaws well. ]
Array Size: 8,191 Bytes ---- generally yields the High MIPS Rating.
Array Size: 2,560,000 Bytes ---- generally yields the Low MIPS Rating.
CPU High Low
System OS CPU (MHz) MIPS MIPS REF
013 Gateway Pentium LINUX 1.1.35 Pentium 90.0 91.0 38.0 78
020 SPARCserver 20/612 Solaris 2.3 SSPARC 60.0 86.7 19.5 77
Tower of Hanoi puzzle:
CPU Moves in
System OS, Compiler CPU (MHz) 25 usec REF
014 Gateway Pentium P5-90 LINUX 1.1.35 Pentium 90.0 66.975 82
017 SPARCserver 20/612 Solaris 2.3 SSPARC 60.0 61.647 81
066 SPARCstation 2 (50) SunOS 4.1.3 SPARC 50.0 29.052 70
112 Gateway 486DX2/66 Linux 0.99 80486DX2 66.7 18.654 29
154 Sun 4/330 SunOS 4.1.1 SPARC 25.0 13.465 2
161 AMI 486DX/33 Linux .99pl7-38 80486DX 33. 13.240 45
194 Sun 4/60 ------------------- SPARC 0 10.8 10
238 Cyrix486slc/33 LINUX 1.0.8 486SLC 33. 6.412 80
253 Sun 3/260 ------------------- 68020 25.0 2.4 10
260 Intel 386SX/16 LINUX 1.0.8 80386SX 16.0 1.312 80
BogoMIPS!!!! from sunsite:
Machine BogoMIPs
------- --------
386DX/25 3.91
Sun-3/80 4.00
Cyrix486slc 13.31
Sun IPC 24.00
486DX/50 24.48
Sun SS10 34.00
Pentium/90 36
486DX2/80 40.0
I am typing on the 486slc. It gets the same value in both portable and
non-portable BogoMips.
Cheers,
Henry
--
"There is only one basic human right, the right | There are three types of
to do as you damn well please. And with it comes | people: those who can
the only basic human duty, the duty to take the | count and those who can't.
consequences" -P.J. O'Rourke | Linux: the choice of a GNU generation | PGP-ok
Glenn Crocker
Are dlopen and friends available for Linux? If not, where should I
start writing? 0x62f00000 (Which is what ld.so calls LDSO_ADDR)?
-glenn
Glenn Crocker
Peter Mutsaers
>> said:
GC> Are dlopen and friends available for Linux? If not, where should I
GC> start writing? 0x62f00000 (Which is what ld.so calls LDSO_ADDR)?
Yes, they are. They are in the standard libc (4.5.25 is the latest)
but *only* in the ELF versions. I think it is useless to try to make
such a thing for a.out, since that is going away anyway.
--
Peter Mutsaers | AT Computing bv, P.O. Box 1428,
p...@atcmp.nl | 6501 BK Nijmegen, The Netherlands
tel. work: +31 (0)80 527248 |
tel. home: +31 (0)3405 71093 | "... En..., doet ie het al?"
Andi Kleen
>In <3bi69d$n...@hahn.informatik.hu-berlin.de> kun...@informatik.hu-berlin.de (Ulrich Kunitz) writes:
>>compatible but different processors. Manufacturers are running expensive
>>simulation tests to boot DOS/Windows or a PC-UNIX. In the mentioned
>>interview is has been said that it takes 2 weeks to get the DOS prompt
>>in a 486 software simulation.
>Wonder what is exactly simulated there... a 486 on an 8008? a 4004?
>Years ago I ran DOS on an 8086 simulator on my Atari ST, and it took
>significantly less than 2 weeks to get a DOS prompt :-)
I think a transistor-level emulation is a very different thing than a
machine language interpreter.
-Andi
--
|an...@golem.greenie.muc.de Nonsense is better than no sense at all.
|Andi Kleen@2:2480/440.12 -NoMeansNo, 0+2=1
Keith Smith
Jonathan I. Kamens <j...@cam.ov.com> wrote:
>In article <3bjen6$m...@ccnet.ccnet.com>, ken...@leviathan.ccnet.com (Daniel Garcia) writes:
>|> Slaving away in a dark room, h...@nwu.edu (H. Peter Anvin) produced:
>|> >idea). If you are running numerical code, it is too damn slow to use
>|> >the emulator (it means that if you have a buggy chip you're SOL, since
>|> >Intel refuse to fix it). This way, the kernel with let you know about
>|>
>|> You really should check things before blurting them like that. Intel HAS
>|> ALREADY FIXED IT!
>
>You really should avoid insulting people for no good reason, when you haven't
>tried hard enough to understand what they're trying to say.
>
>I believe Anvin is fully aware that Intel has fixed the bug and is fabricating
>new chips as we speak. His point is that Intel's stubbornness about replacing
Actually according to INFO World, and net.sources, INTEL plans on
continuing to ship broken product "Well into 1995". Caveat Emptor.
--
Keith Smith Digital Designs ke...@ksmith.com
5719 Archer Rd. PO Box 85 Free Usenet News and Internet Mail Services
Hope Mills, NC 28348-0085 All 28K/14K Modems (910) 423-4216/7389/7391
Somewhere in the Styx of North Carolina ... 14K-V.32/28K-V.34/28K-V.34
Jonathan I. Kamens
|> In article <3bv6lo$k...@pad-thai.cam.ov.com>,
|> Jonathan I. Kamens <j...@cam.ov.com> wrote:
|> >I believe Anvin is fully aware that Intel has fixed the bug and is fabricating
|> >new chips as we speak. His point is that Intel's stubbornness about replacing
|>
|> Actually according to INFO World, and net.sources, INTEL plans on
|> continuing to ship broken product "Well into 1995". Caveat Emptor.
Um, yes. No one has said otherwise, so I do not understand your "actually"
above. I didn't say that Intel is *shipping* fixed chips, I said that they're
*fabricating* them. We know, for a fact, that they have fabricated some fixed
chips, because they gave at least a few of them to Nicely after he went public
about the bug.