Xref: utzoo comp.sys.intel:1468 comp.arch:19116
Path: utzoo!attcan!uunet!crdgw1!rpi!zaphod.mps.ohio-state.edu!usc!elroy.jpl.nasa.gov!decwrl!sgi!vjs@rhyolite.wpd.sgi.com
From: vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
Newsgroups: comp.sys.intel,comp.arch
Subject: Re: Intel bugs / bugged by Intel :-(
Message-ID: <74416@sgi.sgi.com>
Date: 7 Nov 90 23:18:19 GMT
References: <JSP.90Oct25155458@glia.u.washington.edu> <35431@cup.portal.com> <1990Nov5.172110.15994@mozart.amd.com>
Sender: guest@sgi.sgi.com
Organization: Silicon Graphics, Inc., Mountain View, CA
Lines: 51

In article <1990Nov5.172110.15994@mozart.amd.com>, david@neutron.amd.com (David Witt) writes:
> ...[an account of a problem]...

I don't want to get into a flame war about this, but this is what I
remember of the events described:
  -being a software hack but having heard the evils of undriven/unclocked
    inputs to 29Ks and having heard if not understood the "MetaStable"
    incancation, I asked the board vendor and AMD if there might be a
    problem if status values presented as memory values (ie. "memory
    mapped") did not fill an entire word.  That is, I asked if there might
    be a problem if parts of a "status word" were undriven.
  -I convinced the board vendor to be concerned, so we each asked via our
    separate channels.
  -both the board vendor and I were told "no problem" by AMD.
  -this was not consistent with the 29K manual, so the board vendor asked
    again, more forcefully.
  -someone (not AMD or the board vendor) suggested reading a know location
    to "pre-charge the bus" to a known state.
  -AMD told the board vendor again "no problem"
  -I continued to hear via various sources that indeterminate inputs to
    the 29K data bus are a problem, so I adopted "pre-charging the bus"
    as a preventive in my 29K code. (Hey--I'm only a software jock)
  -the silliness of this precharing so enraged the board vendor, that they
    finally got thru to David Witt.  He gave the assurance that all that
    was needed was masking off the bogus bits.  Hearing "there can be a
    problem" after months of "no problem" was not popular.

All of this took many weeks, and almost none of the delay was the fault of
the board vendor.  The reason the initial "no problem" from AMD did not
quiet me was that it was too simple to be consistent with my naive
(mis)understands and the book.  At no time was any observed failure
attributed to the problem.  It was always in the realm of "gee,
indeterminates in --- can cause --- or at best generate indeterminate
results." (sorry for my bad translation from the original hardware-ese.)

If AMD had initially said the two things they said at the end, "all modern
chips have this issue" and "simply mask the bogus bits with AND or use DW=1
and byte loads," everyone on this side of the fence would have said
"Wow!, those great AMD guys are not like the rest of the chip pushers."
Instead I heard unprintable words concerning the likelihood of the board
vendor's future use of AMD parts.  Those words were surely overstatements,
but they reflected real and justifiable irritation at an initial refusual
to acknowledge a known concern.


AMD is no worse than the rest of them, or us.  As I said last time:
> >I think the problem is not a matter corporate nastiness, but of the
> >familiar human reluctance to admit errors.


Vernon Schryver,   vjs@sgi.com