lbert359@pallas.athenanet.com (Lee Bertagnolli) (12/05/90)
I received a list of EISA boards from AST last week, and I thought that I
would share it with the net. Which of these items come with Unix drivers
is not specified, but the product list with phone numbers should prove
imminently useful for those who custom-build or hack their own systems.
If anyone out there knows what Unix/Xenix drivers are available for
these boards, please let me know and I will re-publish this list,
showing which boards come with drivers for which versions.
All products listed are supposed to be currently shipping. All these boards
are 32-bit boards. Nearly all the boards listed indicate bus mastering
capabilities. The absence of a "Yes" under the "Bus Master" column merely
notes that bus mastering capabilities were not specified on AST's list.
I have double-checked the phone numbers with AST's list. I can assure
you that the phone numbers are only as accurate as AST has provided them.
Good luck.
Hard Disk Controllers:
Bus
Manufacturer Phone Number Product Master Description
------------ ------------ ------- ------ -----------
Adaptec 714-838-6000 AHA-1740 Yes SCSI Host Adaptor
Always Tech. 818-597-1400 AL-4000 Yes SCSI controller
Bustek 408-492-9090 BT-742A Yes SCSI Host Adaptor
Data Technology 714-863-0304 DTC-3190E Yes SCSI Host Adaptor
DTC-6190E Yes ESDI controller
DPT 407-830-5522 PM2012/90 Yes SCSI without floppy
PM2012/95 Yes SCSI with floppy
Interphase 214-919-9000 E/SCSI 4810 Lynx
Yes SCSI Host Adaptor
Mylex 415-683-4600 DCE376 Yes SCSI Host Adaptor
Ultrastor 415-623-8955 Ultra22 EISA Yes ESDI Cache control'r
Western Digital 714-863-7903 WD7000EX SCSI Host Adaptor
Network Adaptors:
Bus
Manufacturer Phone Number Product Master Description
------------ ------------ ------- ------ -----------
Codenoll Tech. 914-965-6300 8300/8301 Yes Fiber Ethernet Adaptor
9500/9300 Yes FDDI Adaptor
Madge Networks 408-441-1300 Smart 16/4 Yes Token Ring Adaptor
Mylex 415-683-4600 LNE390 Ethernet Adaptor
Novell 801-379-5900 NE3200 Yes Ethernet Adaptor
Proteon 508-898-2800 ProNET 4/16 Yes Token Ring Adaptor
Racal Interlan 508-263-9929 ES3210 Ethernet Adaptor
Standard Microsystems
516-273-3100 EISA3200 Yes Arcnet Adaptor (Coax/TP)
Torus Networks 223423131 TNP 32 Ethernet Adaptor
Video Adaptors:
Bus
Manufacturer Phone Number Product Master Description
------------ ------------ ------- ------ -----------
Mylex 415-683-4600 GXE020B Yes Hi-Res Graphics Adaptor
Sigma Designs 415-770-0100 L-View EISA Hi-Res Graphics Adaptor
Multiuser Adaptors:
Bus
Manufacturer Phone Number Product Master Description
------------ ------------ ------- ------ -----------
Chase Research 44-246-52260 EISA 16 Yes multiports board
Computone 215-964-0652 ALC EISA Yes Async ports board
Digiboard 612-922-4287 Digichannel C/X multiports board
Specialix 011-44-9323-54254 SI/EISA mulitports board
--
+ Lee Bertagnolli + Voice: (217) 544-0270 +
+ Athenanet, Inc. + Data: (217) 525-9019 +
+ 630 South Pasfield + UUCP: {uunet}!pallas!lbert359 +
+ Springfield, Illinois 62704 + Internet: lbert359@athenanet.com +evan@telly.on.ca (Evan Leibovitch) (12/12/90)
I must say my first expreience with an EISA system has been a nightmare,
and the perceived improvements certainly don't outweigh the pain.
HARDWARE:
ALR PowerCache 4e (486)
600Meg disk,
24 Meg RAM,
Corollory 8x4 multiplexed serial board (32 ports),
Western Digital EtherPlus 16.
Wangtek 150Meg Tape
SOFTWARE:
ESIX Rev D
PROBLEM:
The systems (two identical ones) crash sporadically when reading or
writing the tape drives. Sometimes it works fine, sometimes it causes
kernel panics (the lovely kind that try to dump system RAM into swap).
The problem was not repeatable at will, but frequent enough to make the
systems useless for their intended applications.
SOLUTION:
Moving the Wangtek tape controllers from EISA slots to the 16-bit ISA
"compatability" slots resolved that problem. The tapes now work just fine.
SIDE-EFFECT:
Now the system panics sometimes, with the same error messages, when
reading from or writing to ... the floppy!
If indeed the EISA slots are supposed to, by definition, be backwards
compatible with ISA slots, why would moving a board from an EISA slot to
an ISA slot change the machine's behavior?
Or is this a "standard" that each manufacturer implements differently? :-(
--
Evan Leibovitch, Sound Software, located in beautiful Brampton, Ontario
evan@telly.on.ca / uunet!attcan!telly!evan / (416) 452-0504
Keep an open mind -- you'll never know what might fall in.jca@pnet01.cts.com (John C. Archambeau) (12/14/90)
evan@telly.on.ca (Evan Leibovitch) writes: >I must say my first expreience with an EISA system has been a nightmare, >and the perceived improvements certainly don't outweigh the pain. > >HARDWARE: > ALR PowerCache 4e (486) > 600Meg disk, > 24 Meg RAM, > Corollory 8x4 multiplexed serial board (32 ports), > Western Digital EtherPlus 16. > Wangtek 150Meg Tape > >SOFTWARE: > ESIX Rev D > >PROBLEM: > >The systems (two identical ones) crash sporadically when reading or >writing the tape drives. Sometimes it works fine, sometimes it causes >kernel panics (the lovely kind that try to dump system RAM into swap). >The problem was not repeatable at will, but frequent enough to make the >systems useless for their intended applications. > >SOLUTION: > >Moving the Wangtek tape controllers from EISA slots to the 16-bit ISA >"compatability" slots resolved that problem. The tapes now work just fine. > >SIDE-EFFECT: > >Now the system panics sometimes, with the same error messages, when >reading from or writing to ... the floppy! > >If indeed the EISA slots are supposed to, by definition, be backwards >compatible with ISA slots, why would moving a board from an EISA slot to >an ISA slot change the machine's behavior? > >Or is this a "standard" that each manufacturer implements differently? :-( This is the precise reason that I want to avoid EISA. If you all thought I was screaming because of the recommendations of EISA over MCA I got. You ain't seen nothing, if I would have gone EISA (haven't bought the system yet) over MCA and something like this would have happened, I would have screamed a hell of a lot more. :) Such behavior is no where near acceptable for a Unix box. Of course, WangTek tape drives (save their DAT's) aren't that great of a machine. I remember adding one to a customer's Sun SPARCstation 1+ and it never quite did work 100% of the time. Finally, it died completely a couple of weeks ago. I called up MicroNet for the RMA and found out they don't bundle WangTek tape drives with their storage systems anymore. Too many problems with them. So I ended up replacing the WangTek with what MicroNet supports now; a Tandberg. Never had a problem with it again. Since MicroNet hasn't given me anything but acceptable service for me and my customers, I will side with them on matters concerning the reliability of a given manufacturer. // JCA /* **--------------------------------------------------------------------------* ** Flames : /dev/null | What to buy? ** ARPANET : crash!pnet01!jca@nosc.mil | EISA or MCA? ** INTERNET: jca@pnet01.cts.com | When will the bus wars end? ** UUCP : {nosc ucsd hplabs!hp-sdd}!crash!pnet01!jca **--------------------------------------------------------------------------* */
cpcahil@virtech.uucp (Conor P. Cahill) (12/14/90)
In article <6316@crash.cts.com> jca@pnet01.cts.com (John C. Archambeau) writes: >This is the precise reason that I want to avoid EISA. If you all thought I >was screaming because of the recommendations of EISA over MCA I got. You >ain't seen nothing, if I would have gone EISA (haven't bought the system yet) >over MCA and something like this would have happened, I would have screamed a >hell of a lot more. :) One example of some hardware incompatibility (and there was no obvious explanation for the problem) and you are sure that EISA is terrible? Some things to remember with EISA at this time: 1. It is fairly new, so there may be problems with some implementations (the same kinds of problems that exist with some ISA implementations). 2. Most OSs have not yet been tested/modified to work correctly with EISA (don't know if this is true for ESIX, but ISC2.2 requires a fix disk to work correctly with EISA). I'm not saying EISA is "the" way to go, just that like any new toy, you can't expect to run at the cutting edge of technology and not experience some problems. >Such behavior is no where near acceptable for a Unix box. Yup. But if the Unix vendor does not say thier product will work with an EISA board, you are on your own. The same goes for unknown ISA boards. >Of course, WangTek tape drives (save their DAT's) aren't that great of a >machine. I remember adding one to a customer's Sun SPARCstation 1+ and it >never quite did work 100% of the time. Finally, it died completely a couple Oh my god, the VME bus must be the problem (if they still use VME?) :-) (this is what you sound like when you sound off about EISA with the slightest hint that someone had a problem.) -- Conor P. Cahill (703)430-9247 Virtual Technologies, Inc., uunet!virtech!cpcahil 46030 Manekin Plaza, Suite 160 Sterling, VA 22170
jca@pnet01.cts.com (John C. Archambeau) (12/15/90)
cpcahil@virtech.uucp (Conor P. Cahill) writes: >In article <6316@crash.cts.com> jca@pnet01.cts.com (John C. Archambeau) writes: >>This is the precise reason that I want to avoid EISA. If you all thought I >>was screaming because of the recommendations of EISA over MCA I got. You >>ain't seen nothing, if I would have gone EISA (haven't bought the system yet) >>over MCA and something like this would have happened, I would have screamed a >>hell of a lot more. :) > >One example of some hardware incompatibility (and there was no obvious >explanation for the problem) and you are sure that EISA is terrible? Actually, no, I may consider EISA, but I want to eliminate all potential problems before they happen. One of which, I don't want to be a lab rat for X's implementation of EISA on Y's flavor of Unix. >Some things to remember with EISA at this time: > > 1. It is fairly new, so there may be problems with some > implementations (the same kinds of problems that exist with > some ISA implementations). The main problem is that with the new wave of EISA machines is that you are going to be a lab rat. Why be a lab rat? Also, the problems with ISA have been, for the most part, ironed out. > 2. Most OSs have not yet been tested/modified to work correctly with > EISA (don't know if this is true for ESIX, but ISC2.2 requires > a fix disk to work correctly with EISA). True, but shouldn't EISA be backwards compatable to ISA? Put the EISA slots in ISA mode and they should work fine, right? Well, they don't seem to, do they? The one problem that I have is that the problem machine posted is an ALR PowerCache 4e which is Novell and SCO certified. Ok, barring that in mind, if you don't take advantage of the special capabilities of EISA, your ISA cards should work fine, right? Wrong, this poor soul's tape drive controller bombs his system. >I'm not saying EISA is "the" way to go, just that like any new toy, you can't >expect to run at the cutting edge of technology and not experience some >problems. > >>Such behavior is no where near acceptable for a Unix box. > >Yup. But if the Unix vendor does not say thier product will work with >an EISA board, you are on your own. The same goes for unknown ISA boards. I read between the lines on that statement. If a vendor doesn't support EISA, I read that to be "our product doesn't support the full capabilities of the EISA bus." All of the EISA hype is that it is backwards compatable with ISA, correct? And this isn't some generic EISA board, but from a major 80x86 system vendor that has the seal of approval from Novell and SCO. Should work, based on all of what EISA is supposed to do. Enough of the third degree. Do you now see my point about why one should be weary of EISA and why I am seriously considering MCA as opposed to EISA? EISA may be just perfect for someone else, but I don't want to be a lab rat. Why be a lab rat when I can get a 386 or 486 machine with a system bus that has seen the light of day longer than EISA? I will admit that the tape drive controller may not be the problem with the Powercache 4e and the WangTek tape controller, but it looks awfully suspicious to me when the controller is pulled out of the EISA slot and works better in the ISA slot. The only real way to isolate if it's the Powercache's EISA bus is to build an identical system on an ISA machine. If it works on the ISA machine, then you know it's the EISA bus on the Powercache. // JCA /* **--------------------------------------------------------------------------* ** Flames : /dev/null | What to buy? ** ARPANET : crash!pnet01!jca@nosc.mil | EISA or MCA? ** INTERNET: jca@pnet01.cts.com | When will the bus wars end? ** UUCP : {nosc ucsd hplabs!hp-sdd}!crash!pnet01!jca **--------------------------------------------------------------------------* */
davidsen@sixhub.UUCP (Wm E. Davidsen Jr) (12/19/90)
In article <6316@crash.cts.com> jca@pnet01.cts.com (John C. Archambeau) writes: | Of course, WangTek tape drives (save their DAT's) aren't that great of a | machine. I remember adding one to a customer's Sun SPARCstation 1+ and it | never quite did work 100% of the time. Finally, it died completely a couple | of weeks ago. I called up MicroNet for the RMA and found out they don't | bundle WangTek tape drives with their storage systems anymore. Too many | problems with them. So I ended up replacing the WangTek with what MicroNet | supports now; a Tandberg. Never had a problem with it again. We have a lot of Wanteks in Suns, and they seem reasonably reliable. I don't know what your dataset is (more than the one machine I assume), we have about 400 Suns, with maybe 100 tape equipped. My buddy who sells database applications with a server bundled likes them, and he may have to fly a thousand miles to install a new one in some cases. I can't compare with anything in quantity, but they have always been good to me. -- bill davidsen - davidsen@sixhub.uucp (uunet!crdgw1!sixhub!davidsen) sysop *IX BBS and Public Access UNIX moderator of comp.binaries.ibm.pc and 80386 mailing list "Stupidity, like virtue, is its own reward" -me