Path: utzoo!mnetor!uunet!husc6!bbn!oberon!cit-vax!mangler
From: mangler@cit-vax.Caltech.Edu (Don Speck)
Newsgroups: comp.periphs
Subject: Re: Verdict:  avoid Emulex TC7000 + Cip
Message-ID: <5054@cit-vax.Caltech.Edu>
Date: 27 Dec 87 05:21:51 GMT
References: <7544@elsie.UUCP> <165900002@uiucdcsb> <9901@mimsy.UUCP>
Organization: California Institute of Technology
Lines: 23
Summary: no in-house Unix system

In article <9901@mimsy.UUCP>, chris@mimsy.UUCP (Chris Torek) writes:
> (I have various war stories that, I think, support my assertion that
> Emulex believes `if they do not show under VMS, bugs in our hardware
> do not exist'.  Unix tends to put more stress on hardware than most
> other O/Ses, hence we find the bugs first :-/ ....)

Generally, it is almost impossible to track down a firmware bug
unless they can reproduce the problem on their own machines; but
if the bug only shows under Unix, they can't reproduce it, because
Emulex has no in-house Unix systems.  That's the real problem.

The "Rev A" TC13 had a bug which made it fail to init when used
with the GENERIC kernel on the 4.2bsd distribution tape.  This,
of course, is a useless description for Emulex, since they have
no 4.2bsd distribution tape.  So what I gave them instead was a
page from the console Decwriter which demonstrated, with console
examine and deposit commands, that the TC13 failed to init if the
cmd buffer crossed a 256-byte boundary.  THAT they could understand.

Let's say that customer pressure convinced Emulex to get an in-house
Unix system.  Which Unix?  System V?  4.2bsd?  4.3bsd?	Ultrix?

Don Speck   speck@vlsi.caltech.edu  {amdahl,scgvaxd}!cit-vax!speck