AT&T Sys V R 4 - SCSI Solution.

[jrd at cc.usu.edu]

In article <P12o21w164w at gantz.bowlgreen.oh.us>, gantzm at gantz.bowlgreen.oh.us (gantzm) writes:
>         This is mainly directed to people who work for AT&T or
> have "AWESOME" knowledge about AT&T programmer & management types.
> I have purchased AT&T System V Release 4.0 (2.1) for use with
> SCSI drives.  Well guess what,, this system will only work with
> AT&T SCSI controllers and AT&T hard drives.  Does anybody know
> why this is??  My dealer has been spending much time on the phone
> with AT&T reps.  He has received two responses from AT&T:
> 
>         1. Yep thats right, and it will only get worse.
>         2. And I quote... "That's Bullshit."
> 
> Well it seems even AT&T can't decide what to do here.  Well if you
> know what the future outcome of this situation might be, please
> let me know.  Or, if you work for AT&T and are working on the code
> what is going on here???  I know the AT&T contoller is basically a
> Western Digital(which I currently have) controller with AT&T mods.
> For a few specific reasons I would like to run the AT&T code, but
> if they can't fix this, well, who knows then.  I realize that if
> I can get my hands on some ST-506 boot disks I can rebuild the
> kernel using the Columbia Data Products drivers.  This would work
> but it costs more money and is a real pain in the ass.  Don't really
> mean to waste bandwidth with my personal AT&T complaints, but my 
> dealer doesn't know what to do either.  
> 
> Thanks in advance...
> BTW:  I don't know for sure if I can get a set of ST-506 boot disks.
> 2nd BTW: Just so you don't think I'm really stupid here the AT&T manual
> does not say anywhere that you need AT&T equipment.  As a metter of fact
> it tells you to get a Western Digital controller..  I give up...
> 
> ----
> 
> Michael L. Gantz         | gantzm at gantz.bowlgreen.oh.us
> 213 Napoleon Rd.         | osu-cis!bgsuvax!gantz!gantzm
> Bowling Green, Oh 43402  | Mellon!  I had only to speak the Elvish word for 
> (419) 353-5029           | friend and the doors opened.  - J.R.R. Tolkien
---------------------------------------------------

Michael and others in the same situation:

	I was in your place a few weeks ago and finally emerged victorious
a couple of days ago, with scars to prove it.
	I bought a large CDC SCSI drive (ST4766N aka CDC 94191-766) and a WD
7000 FASST2 board to use with AT&T SVR4 v2.1 on a 386-33 box. I pleaded for
help on the net, with a couple of very helpful responses, beat my head against
the stone wall, took some constructive action, and weeks later arrived at a
solution.
	The above incoming remark #1 is accurate about AT&T hardwiring their
particular SCSI solution. The controller board AT&T uses is NOT the 7000 FASST
but a similar looking unit. Booting from the SCSI floppies yields a rejection
if that particular AT&T board is not present; I checked with a real one, and
no, swapping rom chips on the board won't do the trick. Then there is the
business of the SCSI ident string sitting in a table in the driver/kernel.
That's patchable if you have the right tools (just text), but I understand
that Intel is smart enough to say "Oh, that's interesting" and keep on going.
Then I understand a signature is required on the disk, a blessing of a sort;
no direct knowledge here.
	What I finally did was pester Columbia Data Products. They were very
helpful. After much talk I called Microport to get some hints. They were also
very nice, really. Back at CDP I signed a non-disclosure form to obtain a
beta device driver which would work, I hoped, with Release 4, and they sent a
prebuild small-sized SCSI boot Unix on the floppy. These were the critical
items. I had build SCSI systems on a spare 43MB ST-506 drive but for the
life of me I could not squeeze out enough drivers to make a "unix" image
small enough to fit onto the first, vital, boot floppy. And there were 
problems selecting the right flags in file mdevice to match the original
v3.2 drivers of CDP with the v4.0 other modules; trial and error territory.
	So, I took that supplied small (600+KB) SCSI "unix", put in over top
of "unix" on a copy of the regular ST-506/ESDI first boot disk, and booted
with the SCSI drive available. It worked! The disk partitioned and files
loaded and so on through all 10 install disks. Oh joy!
	Next step. Don't boot from that newly idbuild'd SCSI based unix on
the harddisk: you can zap it. Instead boot again from the first two ST-506
floppies (the first has the SCSI based kernel) and push the DEL key when
disk #2 asks to install a new system. This loads all the basic routines into
the ram disk based primative unix. Then  mount -f bfs /dev/dsk/0s10 /mnt.
This mounts the SCSI drive /stand bfs partition onto the temp directory /mnt.
Copy the floppy unix to the hard disk: cp /unix /mnt/stand/unix. Reboot.
At this level cat and ls are unavailable. I use   echo *  and
 dd if=filename of=/dev/tty   to look at things.
	The reason for putting this old unix on top of the freshly built new
one is the new one used the original "hd" driver from the installation set.
	Up comes the machine from the SCSI drive. But be careful. We are
running from the tiny unix without much knowledge of our new configuration.
Rename that /stand/unix to be say /stand/unix.0 to keep it handy: it can be
used to boot after disasters by interrupting the normal boot process with
a CR and then tell the system "unix.0" as the kernel to use for booting.
	Load the new CDP drivers into /usr/sst. Fix the installsst script
to put a TAB between "scsiprim" and "-" which are joined with no space in
the script. Run that script: ./installsst. A new system will be constructed.
Next, cp /usr/sst/unix.scsi /stand/unix. The script puts the newest unix
in the /usr/sst directory, just like manual says. Reboot the machine to now
have a fully usable SCSI based system. Bliss!
	The idea of CDP's stuff is to make driver "hd", normally the ST-506
driver, behave like one to the higher callers but actually run the SCSI drive
via the particular scsiprim driver. Flags for hd in file mdevice are those
simple ones given in the CDP manual, not the extra ones used by AT&T with
their ST-506 hd driver.
	All the AT&T SCSI particular code is left in the grey box. It won't
coexist so far as I am aware because of the calls it makes on it's own driver.
	I want to tell you that this was a very unpleasant and exhausting
experience. AT&T does not tell one about these details (I run a lab full of
their v3.2 machines with a SCSI based AT&T server, and the manuals don't say
boo about these gotcha's). I have yet to discover how one makes a primative
kernel as small as seen on the install floppies; I suspect it takes a special
kernel available only to OEMs. Without that little fellow the prospects are
very bleak. I won't say more about what CDP and Microport have cooking, but
it looks appealing to me. Both outfits get my thanks and appreciation.
	As I have commented before in this news group, this kind of knowledge
is seemingly required when buying things independently. Dell is quite vocal
about saying they provide all the information a user needs before purchase.
Since they wear a white hat in my book I won't say any more than prospective
buyers should explore their system plans in great detail with vendors before
spending money on separate parts.
	Joe Doupnik