gantzm@gantz.bowlgreen.oh.us (gantzm) (05/10/91)
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. Tolkienbrando@uicsl.csl.uiuc.edu (Brandon Brown) (05/10/91)
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: Well at a site I do some consulting for, we were really pissed at this also. It seems that AT&T looks for the SCSI ident string on the drive, and that is how it determines whether or not it is a supported device. This also includes all SCSI tape drives too. As for the fix, you might as well forget it. It was obviously hardcoded so f**king AT&T could sell more of their own equipment. I know, I can't believe it either. So much for "open systems"..... +-----------------------------------------------------------------------------+ | Brandon Brown | Internet: brando@uicsl.csl.uiuc.edu | | Coordinated Science Laboratory | UUCP: uiucuxc!addamax!brando!brown | | University of Illinois | CompuServe: 73040,447 | | Urbana, IL 61801 | GEnie: macbrando | +-----------------------------------------------------------------------------+
larry@nstar.rn.com (Larry Snyder) (05/11/91)
brando@uicsl.csl.uiuc.edu (Brandon Brown) writes: >Well at a site I do some consulting for, we were really pissed at this >also. It seems that AT&T looks for the SCSI ident string on the drive, and >that is how it determines whether or not it is a supported device. This also >includes all SCSI tape drives too. As for the fix, you might as well forget >it. It was obviously hardcoded so f**king AT&T could sell more of their own >equipment. we had the same problem originally with Intel SVR4 2.0 now with Dell SVR4 we haven't had this problem -- -- Larry Snyder, NSTAR Public Access Unix 219-289-0287/317-251-7391 HST/PEP/V.32/v.32bis/v.42bis regional UUCP mapping coordinator {larry@nstar.rn.com, ..!uunet!nstar.rn.com!larry}
cpcahil@virtech.uucp (Conor P. Cahill) (05/12/91)
brando@uicsl.csl.uiuc.edu (Brandon Brown) writes: >Well at a site I do some consulting for, we were really pissed at this >also. It seems that AT&T looks for the SCSI ident string on the drive, and >that is how it determines whether or not it is a supported device. This also >includes all SCSI tape drives too. As for the fix, you might as well forget >it. It was obviously hardcoded so f**king AT&T could sell more of their own You can fix this several ways. 1. use a binary editor to replace the AT&T strings on the boot disketttes so that it recognizes your devices. 2. Get the system loaded on a supported device and then change the SCSI id tables in /etc/conf/pack.d/{scsi driver directories}. There are two directories (one for tapes and one for disks). -- Conor P. Cahill (703)430-9247 Virtual Technologies, Inc. uunet!virtech!cpcahil 46030 Manekin Plaza, Suite 160 Sterling, VA 22170
gantzm@gantz.bowlgreen.oh.us (gantzm) (05/13/91)
cpcahil@virtech.uucp (Conor P. Cahill) writes: > brando@uicsl.csl.uiuc.edu (Brandon Brown) writes: > > >also. It seems that AT&T looks for the SCSI ident string on the drive, and > >that is how it determines whether or not it is a supported device. This also [stuff deleted] > You can fix this several ways. > > 1. use a binary editor to replace the AT&T strings on the boot > disketttes so that it recognizes your devices. > > 2. Get the system loaded on a supported device and then change the > SCSI id tables in /etc/conf/pack.d/{scsi driver directories}. There > are two directories (one for tapes and one for disks). > > -- > Conor P. Cahill (703)430-9247 Virtual Technologies, Inc. As the original poster of this wonderful mess, is this modification easy?<Don't laugh too hard> I'm a new system administrator, and sort of know what I'm doing, enough to be dangerous I guess. The saga continues.... --- 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
dcon@cbnewsc.att.com (david.r.connet) (05/14/91)
In article <767u21w164w@gantz.bowlgreen.oh.us> gantzm@gantz.bowlgreen.oh.us (gantzm) writes: >cpcahil@virtech.uucp (Conor P. Cahill) writes: >> brando@uicsl.csl.uiuc.edu (Brandon Brown) writes: >> You can fix this several ways. >> >> 1. use a binary editor to replace the AT&T strings on the boot >> disketttes so that it recognizes your devices. >> >> 2. Get the system loaded on a supported device and then change the >> SCSI id tables in /etc/conf/pack.d/{scsi driver directories}. There >> are two directories (one for tapes and one for disks). >> > As the original poster of this wonderful mess, is this modification >easy?<Don't laugh too hard> I'm a new system administrator, and sort >of know what I'm doing, enough to be dangerous I guess. Quite easy. For #2, edit /etc/conf/pack.d/scsi/space.c and then idbuild and reboot. Also edit /etc/scsi/tc.index (used for mkfs, and other commands). What I do is to copy an entry for a similar device (someone tells me what is similar). Beware, in the tc.index file, there are trailing blanks. These are critical. Dave Connet dcon@iwtng.att.com
dcon@cbnewsc.att.com (david.r.connet) (05/14/91)
In article <1991May13.173321.26626@cbnewsc.att.com> dcon@cbnewsc.att.com (david.r.connet) writes: >In article <767u21w164w@gantz.bowlgreen.oh.us> gantzm@gantz.bowlgreen.oh.us (gantzm) writes: #>cpcahil@virtech.uucp (Conor P. Cahill) writes: #>> brando@uicsl.csl.uiuc.edu (Brandon Brown) writes: #>> You can fix this several ways. #>> #>> 1. use a binary editor to replace the AT&T strings on the boot #>> disketttes so that it recognizes your devices. #>> #>> 2. Get the system loaded on a supported device and then change the #>> SCSI id tables in /etc/conf/pack.d/{scsi driver directories}. There #>> are two directories (one for tapes and one for disks). #>> #> As the original poster of this wonderful mess, is this modification #>easy?<Don't laugh too hard> I'm a new system administrator, and sort #>of know what I'm doing, enough to be dangerous I guess. # #Quite easy. For #2, edit /etc/conf/pack.d/scsi/space.c and then idbuild ^^^^ #and reboot. Also edit /etc/scsi/tc.index (used for mkfs, and other commands). #What I do is to copy an entry for a similar device (someone tells me what #is similar). Beware, in the tc.index file, there are trailing blanks. #These are critical. Oops, I meant sd01. Dave Connet dcon@iwtng.att.com
cpcahil@virtech.uucp (Conor P. Cahill) (05/14/91)
gantzm@gantz.bowlgreen.oh.us (gantzm) writes: > As the original poster of this wonderful mess, is this modification >easy?<Don't laugh too hard> I'm a new system administrator, and sort >of know what I'm doing, enough to be dangerous I guess. Editing the disk requires a binary edit utility. This shouldn't be too hard if you have such a utility. Changing the entries in the real system is a simple change to one (or two if you are changing the tape entry also) space.c file under /etc/conf/pack.d/???? (I don't remember the exact name of the directory but it is something like st?? for the tape driver and sc?? or sd?? for the disk driver). -- Conor P. Cahill (703)430-9247 Virtual Technologies, Inc. uunet!virtech!cpcahil 46030 Manekin Plaza, Suite 160 Sterling, VA 22170