bronson@mfci.UUCP (Tan Bronson) (10/08/88)
for our '286 machines. A local dealer has recommended the
Future Domain SCSI controller and claims this works with
Xenix/Unix and that someone has this setup using Microport.
Has anyone had any experience with this board ?
Does this imply a special version of Xenix ?
Is this board related in anyway to the Tandy SCSI board ?
(I though the Tandy board was micro channel only)
Is there a better Xenix/SCSI combination ?
Any clues or experiences would be appreciated. I'd love to
use SCSI as my main disk interface, but am I going to have to
run Microport to do this ?
thanks in advance!
Tan Bronson
Multiflow Computer Inc UUCP(work): {yale,uunet}!mfci!bronson
175 N Main St UUCP(home): {yale,mfci}!bronson!tan
Branford, Ct 06405 Phone(work):(203)-488-6090 dyer@spdcc.COM (Steve Dyer) (10/08/88)
In article <522@m3.mfci.UUCP> bronson@mfci.UUCP (Tan Bronson) writes: >for our '286 machines. A local dealer has recommended the >Future Domain SCSI controller and claims this works with >Xenix/Unix and that someone has this setup using Microport. > > Has anyone had any experience with this board ? > Does this imply a special version of Xenix ? > Is this board related in anyway to the Tandy SCSI board ? > (I though the Tandy board was micro channel only) > Is there a better Xenix/SCSI combination ? Future Domain has drivers for XENIX 286 and 386 which were written by Corollary of Irvine CA, the multi-processor XENIX folks. The way it works is a little weird. Apparently the current (< 2.3) versions of XENIX are said to "only support two drives (of any type)". This would mean that if you have a AT floppy/hard disk controller with at least one of the disks in use, you don't have the option of adding another controller of any type. Now, no one can really tell me why that is, since UNIX really doesn't care, and the best explanation I can surmise is that the XENIX "divvy" partitioning software layer makes such a bad assumption, so two drivers for two different controllers which both use the "divvy" partitioning scheme can't coexist. So, how do you get a Future Domain XENIX installed onto a system? Future Domain provides a means by which you insert your installation diskettes on your running XENIX system, and they build a new diskette which has their SCSI driver installed as the hd00 device in place of the AT hard disk controller. Presumably, you back up your AT disks, build a new installation disk, reinstall XENIX on the SCSI drive, and then restore from backup. I didn't want to do that (my cartridge tape was frotzed at the time) and anyway, the SCSI disk was loaned to me. So, I tried to be smart and built a new kernel with the SCSI device as just another set of major/minor devices, keeping the AT controller as the primary device. (I was saying to myself, there's NO WAY that UNIX cares about how many disks there are.) You don't wanna ask what happened when I accessed the SCSI, but I'll tell you anyway. My AT controller activity light went on, I heard a strange sound and lost a block of inodes! Now, I don't blame Future Domain for this, but consider yourself warned. When they say you can't use both controllers, they mean it. I do not believe there is any IO address conflict. Future Domain has a good reputation for its 830 card being a very hot SCSI controller, and that's completely without using DMA. I haven't used the XENIX driver for the reason I mention above, but it's probably worth investigating. -- Steve Dyer dyer@harvard.harvard.edu dyer@spdcc.COM aka {harvard,husc6,linus,ima,bbn,m2c,mipseast}!spdcc!dyer
jbayer@ispi.UUCP (id for use with uunet/usenet) (10/10/88)
In article <1996@spdcc.COM>, dyer@spdcc.COM (Steve Dyer) writes: > > it works is a little weird. Apparently the current (< 2.3) versions > of XENIX are said to "only support two drives (of any type)". This > would mean that if you have a AT floppy/hard disk controller with > at least one of the disks in use, you don't have the option of adding > another controller of any type. Now, no one can really tell me why > that is, since UNIX really doesn't care, and the best explanation I > can surmise is that the XENIX "divvy" partitioning software layer > makes such a bad assumption, so two drivers for two different > controllers which both use the "divvy" partitioning scheme can't coexist. The problem is not Xenix, but the way IBM designed the AT. What happens is that most controllers use the same interrupt. The AT cannot support multiple devices with the same interrupt. Also, they both might be using the same address space. Either or both of these situations will cause problems. Perhaps some of the hardware types will be able to shed some more light on the matter. Jonathan Bayer Intelligent Software Products, Inc.
chip@ateng.ateng.com (Chip Salzenberg) (10/11/88)
Well, this machine (ateng) is a '286 machine with a Future Domain TMC-870
combination SCSI and floppy controller. A summary of my experience is:
1. Installation is a pain and a half.
2. It works.
3. It's slow.
Installation is trouble since A WORKING XENIX SYSTEM IS REQUIRED. That's
right, folks, you need to have Xenix working on another system to create
a kernel with the Future Domain drivers.
It does work; it has been working here, trouble-free, for months.
It's *slow*. I don't know why; perhaps the driver writers didn't know about
the sleep() call. It seems -- not that I know for sure -- that the driver
actually has *wait loops* in it. Gag.
> Is this board related in anyway to the Tandy SCSI board ?
> (I though the Tandy board was micro channel only)
No. The Tandy (actually Adaptec) SCSI board is a *fast* alternative for
the AT bus. But you need Xenix 2.3 to use it.
--
Chip Salzenberg <chip@ateng.com> or <uunet!ateng!chip>
A T Engineering Me? Speak for my company? Surely you jest!
Beware of programmers carrying screwdrivers.dyer@spdcc.COM (Steve Dyer) (10/11/88)
In article <213@ispi.UUCP> jbayer@ispi.UUCP (id for use with uunet/usenet) writes: >The problem is not Xenix, but the way IBM designed the AT. What happens >is that most controllers use the same interrupt. The AT cannot support >multiple devices with the same interrupt. Also, they both might be using >the same address space. Either or both of these situations will cause >problems. Perhaps some of the hardware types will be able to shed some >more light on the matter. Neither is the problem. The IRQ is settable (3 or 5, neither of which is used by the AT disk controller), as is the starting address for the PROM and RAM space. There are no conflicts necessary between the standard AT hard/floppy disk controller and the Future Domain 830 SCSI controller. The problem undoubtedly resides in the software design of systems earlier than XENIX 2.3. I believe that Future Domain is working on a version of their driver which will work under XENIX 2.3. -- Steve Dyer dyer@harvard.harvard.edu dyer@spdcc.COM aka {harvard,husc6,linus,ima,bbn,m2c,mipseast}!spdcc!dyer
sl@van-bc.UUCP (pri=-10 Stuart Lynne) (10/12/88)
In article <213@ispi.UUCP> jbayer@ispi.UUCP (id for use with uunet/usenet) writes: >In article <1996@spdcc.COM>, dyer@spdcc.COM (Steve Dyer) writes: >> it works is a little weird. Apparently the current (< 2.3) versions >> of XENIX are said to "only support two drives (of any type)". This >> would mean that if you have a AT floppy/hard disk controller with >> at least one of the disks in use, you don't have the option of adding >> another controller of any type. Now, no one can really tell me why >The problem is not Xenix, but the way IBM designed the AT. What happens >is that most controllers use the same interrupt. The AT cannot support >multiple devices with the same interrupt. Also, they both might be using Well, yes and no, there are various techniques that can be used both at the hardware and software levels to allow multiple devices to use the same interrupt. Most likely the driver just can't support two controllers. You *can* configure hard disk controllers to an alternate io location, so supporting two boards is at least *theoretically* possible. In point of fact the System V / 386 system actually asks what controller you are adding a disk to, and in the header files there is a bunch of stuff which indicate that the driver might support two boards. Never got a chance to try it though. And that may have been there to support something on the Intel MultiBus 386 machine. -- Stuart.Lynne@wimsey.bc.ca {ubc-cs,uunet}!van-bc!sl Vancouver,BC,604-937-7532
fr@icdi10.uucp (Fred Rump from home) (10/12/88)
In article <1988Oct10.131128.3477@ateng.ateng.com>, chip@ateng.ateng.com (Chip Salzenberg) writes: > Well, this machine (ateng) is a '286 machine with a Future Domain TMC-870 > No. The Tandy (actually Adaptec) SCSI board is a *fast* alternative for > the AT bus. But you need Xenix 2.3 to use it. It was my understanding that Xenix 2.4 (Tandy's own) was required to run SCSI. Inquiries to SCO have indicated that SCSI is not supported by 2.3. So if the 'ateng' system uses SCSI on a 286 - what gives? Does it really look like a ST-506 to the software? Is that why the slowness exists? -- {allegra killer gatech!uflorida decvax!ucf-cs}!ki4pv!cdis-1!cdin-1!icdi10!fr 26 Warren St. or ...{bellcore,rutgers,cbmvax}!bpa!cdin-1!icdi10!fr Beverly, NJ 08010 or...!bikini.cis.ufl.edu!ki4pv!cdis-1!cdin-1!icdi10!fr 609-386-6846 "Freude... Alle Menschen werden Brueder..." - Schiller
clewis@ecicrl.UUCP (Chris Lewis) (10/14/88)
In article <2008@spdcc.COM> dyer@spdcc.COM (Steve Dyer) writes: >In article <213@ispi.UUCP> jbayer@ispi.UUCP (id for use with uunet/usenet) writes: >>The problem is not Xenix, but the way IBM designed the AT. What happens >>is that most controllers use the same interrupt. The AT cannot support >>multiple devices with the same interrupt. Also, they both might be using >>the same address space. Either or both of these situations will cause >>problems. Perhaps some of the hardware types will be able to shed some >>more light on the matter. > >Neither is the problem. The IRQ is settable (3 or 5, neither of which >is used by the AT disk controller), You're right - the 830 doesn't clash with the AT disk controller - it clashes with COM2 (3) or LPT2 (5) respectively. Therefore, you have to somehow disable one or the other in Xenix. It *is* possible to run two devices on the same interrupts, but it requires a little robustness from the two drivers, sometimes a little hacking to the configuration, *and* (gawddamn IBM!) pull down resisters on the interrupt lines on the bus. (you ever heard of upside-down open collector gates?) The main difficulty with the 830 is that it's so darn stupid. The device driver even has to toggle the ACK/NACK bits to transfer a single byte. Gack. Performance is moderately awful compared to other controllers. Recommended: AHA1540 from Adaptec, or make the plunge to ESDI and use the DPT controllers (one of which actually emulates a WD1003, so would use the normal hard disk drivers). -- Chris Lewis {uunet!mnetor,yunexus,utzoo}!lsuc!ecicrl!clewis (or lsuc!gate!eci386!clewis or lsuc!clewis)
dyer@arktouros.MIT.EDU (Steve Dyer) (10/17/88)
In article <122@ecicrl.UUCP> clewis@ecicrl.UUCP (Chris Lewis) writes: >>Neither is the problem. The IRQ is settable (3 or 5, neither of which >>is used by the AT disk controller), >You're right - the 830 doesn't clash with the AT disk controller - it >clashes with COM2 (3) or LPT2 (5) respectively. Therefore, you have to >somehow disable one or the other in Xenix. >It *is* possible to run two devices on the same interrupts, but it >requires a little robustness from the two drivers, sometimes a little... This is *NOT* the issue here. If you don't have COM2 or LPT2 there is no problem. The problem is that XENIX for XENIX < 2.3 *still* won't work if you expect to use both the AT controller and the 830 together, assuming the stock AT disk driver controlling two ST506 drives (and on which reside your root and swap), plus adding SCSI disks using the Corollary FD 830 disk driver. We are discussing a software deficiency, not interrupt conflicts. There is no reason a-priori this should fail, since UNIX in general is happy to support multiple block devices on which will be contained file systems. --- Steve Dyer dyer@arktouros.MIT.EDU dyer@spdcc.COM aka {harvard,husc6,ima,bbn,m2c,mipseast}!spdcc!dyer
chip@ateng.ateng.com (Chip Salzenberg) (10/17/88)
According to fr@icdi10.uucp (Fred Rump from home): >It was my understanding that Xenix 2.4 (Tandy's own) was required to run SCSI. >Inquiries to SCO have indicated that SCSI is not supported by 2.3. >So if the 'ateng' system uses SCSI on a 286 - what gives? Does it really look >like a ST-506 to the software? Is that why the slowness exists? First, realize that when Tandy and SCO talk about SCSI support, they mean built-in support for the Adaptec AHA-1540. They don't mean SCSI in general! After all, anyone can write a device driver. That's what Corollary did at Future Domain's request; ateng is running -- slowly -- using the resulting driver. Perhaps I was mistaken about 2.3 including Adaptec support. My info was second hand. The slowness may be due to the controller or the driver or both. In truth, I don't care; it's just too slow. I'm ditching Future Domain as soon as possible. -- Chip Salzenberg <chip@ateng.com> or <uunet!ateng!chip> A T Engineering Me? Speak for my company? Surely you jest! Beware of programmers carrying screwdrivers.
dyer@arktouros.MIT.EDU (Steve Dyer) (10/18/88)
In article <1988Oct17.113009.8481@ateng.ateng.com> chip@ateng.ateng.com (Chip Salzenberg) writes: >Perhaps I was mistaken about 2.3 including Adaptec support. My info was >second hand. XENIX 386 2.3 has several different versions, not all of which are out yet. There will be a version released which supports the Adaptec card for boot and root devices. >The slowness may be due to the [Future Domain] controller or the driver >or both. In truth, >I don't care; it's just too slow. I'm ditching Future Domain as soon as >possible. This is good and useful information. It's also in direct contradiction to Future Domain's literature, which makes the point that PIO can often be faster than DMA on a 386AT architecture due to its ability to handle arbitrary block transfers into virtual memory versus breaking up a request into 4kb physical DMA transfers. I'd be interested to know what "too slow" is here. How does it compare to your experience with ST506 controllers under XENIX? --- Steve Dyer dyer@arktouros.MIT.EDU dyer@spdcc.COM aka {harvard,husc6,ima,bbn,m2c,mipseast}!spdcc!dyer
eabu110@orion.cf.uci.edu (David O'Shea) (10/19/88)
There has been recent talk on the net about SCSI controllers Xenix.
Many things have been written, some quite acurate, some quite shrewd,
and some totally wrong.
First, Future Domain sells 2 types of controllers. One type is a
multithread capable controller, the TMC-830/840/880 family.
The other type is single threaded, the TMC-870 is this type.
Someone claimed that Future Domain controllers on Xenix were slow. This
person also said he is using a TMC-870. He is correct, Xenix with the
870 is slow, we do not recommend the 870 for use on Xenix or Unix. It is
primarily designed to be a low cost DOS product.
The TMC-830/840/880 performance is very very good on Xenix. Quite on par
with the AHA-1540 Adaptec board which has been mentioned in past letters.
These boards support multi-thread operations, as does the driver. The driver
does not have wait loops in it as someone erroneously conjectured.
End of major advertisement.
Technical Facts:
1) The TMC-830 and TMC-840 can be switched to either interupt 3 or 5.
The TMC-881 can be switch to any one of 6 interupts.
2) There is no hardware related problem with using a Future Domain
board and some type of Western Digital compatible controller. It is
software related.
3) Unix in general does not limit users to a single hard disk driver.
4) SCO Xenix versions 2.2.X do have a single hard disk driver limitation
based on DOS compatibility. Strictly speaking, you can have more than
one hard disk driver, but only one of them can talk to DOS partitions.
We designed our driver to be able to support the DOS features of Xenix,
hence our driver must be the ONE DRIVER, and precludes using the AT driver
simultaneously. This is a limitation due to SCO's treatment of disk
partitioning, which was itself derived from DOS's stupid design.
5) The Future Domain controllers run normal Xenix with our driver linked in
place of the standard AT fixed disk driver. Although installation
procedures are automated so that the user just has to answer questions,
the installation takes some time.
6) The user must have a running AT type fixed disk system running. Thus
a ground zero installation requires building a minimum AT-disk system,
then rebuilding the SCSI system. This limitation is a legal one. It
is illegal for Future Domain to supply a Xenix N1 Boot diskette with our
software kit. So the user is forced to build a new one from the one
supplied by SCO. This process is automated, but adds approximately
30 minutes to the first time installation of Xenix. These 30 minutes
compare to the approximately 3 hours it usually takes to install the
system. 3 hours or 3 1/2 hours does not matter that much.
7) When Xenix 2.3GT comes out, multiple fixed disk drivers will be allowed.
At that time:
a) You will be able to use both your AT-fixed disk and SCSI disks
b) Your installation time will no longer require the 30 extra minutes.
8) Contrary to some previous comments, SCSI disks in conjunction with the
TMC-8340 or TMC-840 are much faster than AT-fixed disks and controllers,
and provide for the very large capacity SCSI disks now on the market.
9) Xenix 2.2.4 has the multi fixed disk driver facilities built into it,
but this release is only available with Tandy 1000's.
I hope that his anwers some of the conjecture with fact. I have tried to
be honest about FDC good and bad points.
David O'Shea
Future Domain Corporation
Tustin, CA. I can be reach at the above address and at the following:
eabu110@orion.cf.uci.edu
!ucbvax!ucivax!eabu110@orion