jrd@cc.usu.edu (05/17/91)
In article <P12o21w164w@gantz.bowlgreen.oh.us>, gantzm@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@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