SCSI tape drive in SCO XENIX 2.3.4
Richard Ivey
I have a machine with the following:
SCO XENIX 2.3.4
Adaptec 1542CP SCSI controller with Plug and play, FDD disabled; base
address
is 330.
Archive 2150S SCSI tape drive
HDD is IDE, not SCSI
The only device attached to the SCSI card is the tape drive.
The tape drive is set to ID = 2
The 1542CP is set to ID = 7
When the computer boots, I get the standard Adaptec <<ctrl-A>> message.
It recognizes the tape drive and shows the correct ID
I logged in and ran "mkdev tape"
I chose "1" to install
I chose "4" to install SCSI
I chose "2" for the tape ID
I chose "1" for the host adapter (it's the only one in the computer)
It installs the drivers and creates /dev/rct0
Then I relinked the kernel and rebooted
No tape drive.
I tried numerous variations on this procedure with no luck. Does anybody
have any idea why it would not recognize the drive at bootup time.
I have been without a backup for over a month now trying to get this fixed
and am in desperate need of a fix. Any help or suggestions of any kind
would be greatly appreciated. Thank you.
Michael Krzepkowski
I don't have a Xenix machine anymore, but for the only controller
the id should be zero not one (I think).
HTH
Michael
Can you use some of Adaptec utilities (DOS) to verify that the controller can
see the tape?
MK
Dan
About 3 years ago, I was installing
a Pentium system to replace a 486 running
Xenix 2.3.4.
The Xenix box had a 1542 and SCSI hard
disk, but no SCSI tape.
The new SCO 5.0.0 had a SCSI DAT.
I thought I'd take along an old
Tandberg 525 drive, slap it into Xenix
for a backup, then use the same drive
on the SCO 5 machine to restore.
Nothing I did would wake up the Tandberg
under Xenix, but I was able to install
the DAT under Xenix and get it working.
If you have a different SCSI tape drive
available, give it a try.
Are you trying to move data to a different
box? If yes, you might want to simply use
something like Lone-tar or Backup Edge with
diskettes.
The Xenix box is most likely light on
disk space. When disk 1 finishes on Xenix,
pop it into your new machine to extract,
while disk 2 is being created. With compression
from the supertar of your choice, this may
go pretty quickly.
Good Luck.
In article <382B1CC0...@sqlcanada.com>,
Sent via Deja.com http://www.deja.com/
Before you buy.
Barry O. Andalman
The settings I am using are:
Base IO=330h
IRQ=11
DMA=5
SCSI ID = 7
DMA Transfer rate=5 MB/sec
Host adapter BIOS = Enabled
System Boot controlled by Host adapter BIOS = Enabled
I have also made the controller you are using work, but I don't have the
settings handy. I do know that you must disable the PNP setting.
Also, in each case I have used a SCSI HDD -- haven't tried with a mixed IDE /
SCSI environment.
Richard Ivey wrote:
--
Barry
_______________________________________________________________________
Barry O. Andalman <taft...@accesscom.net>
_____/ _____/ ____/ TAFT PARK DATA CO.
/ / / / / 2101 Taft Park
/ /__/ / / Metairie, LA 70001
_/ _/ _/___/ TEL: (504) 455-0022 / FAX: (504) 888-9664
_______________________________________________________________________
Richard K. Witte
SCSI IDs are backwards. Use ID-0 for the controller and ID-5 for the tape
drive. If it is not an IBM machine, use ID-7 for the controller and ID-5 for
the tape drive. Notice in both cases, assign ID-5 to the tape drive. ID-2 is
usually associated with a hard disk. Depending on your controller and bios
chip, that could be the source of the problem. And of course, check the SCSI
chain an make sure it is properly terminated.
Hope this helped.
L Janda
Richard K. Witte <rkw...@mail.mchr.state.md.us> wrote in message
news:38342D18...@mail.mchr.state.md.us...
Bill Vermillion
Richard K. Witte <rkw...@mail.mchr.state.md.us> wrote:
>Here is a thought: What kind of machine are you using? If it is an
>IBM, the SCSI IDs are backwards. Use ID-0 for the controller and
>ID-5 for the tape drive. If it is not an IBM machine, use ID-7 for
>the controller and ID-5 for the tape drive.
This is just an FYI. IBM's design follows the standard
implementation of the SCSI specifications. This has to do with
prioritization. ID 7 is highest, and then down to ID 0, then
15 thru 8, and then 23 thru 16, and 32 thru 24 (if you want all the
details). They are not backwards but are following the original
standards, not the de facto standards.
All of the SCSIs implementations I've seen (working in the *ix
INTEL environment primarily) all have the SCSI adapator (often
mis-named a SCSI controller) as the initiator. The original
designed allowed any device to the be the initiator and the
priority of the ID's set that devices level, and that left ID6 as
the ID with the highest priority.
The reason that ID6 was chosen for HD by IBM (and any others
following the specs exactly) was that if what is typically called
a target (any ID other than 7), was an initiator, then you could
have something like a slow CDROM capture the bus and the faster hard
drives would have to wait. Not a good thing.
I've seen no implementation of this - though it is in the
specifications - and is how IBM implemented things - they are one
of the better companies for following (and setting) standards.
I would think that SCSI systems where the ID's other than ID7 were
initiators would be in non-HD environments, such as SCSI terminal
adaptors or printers. (such beasts have existed and I have NO
experience with them).
The strangest SCSI configuration I've seen is in the SGI line.
Through an error in design ( I know not whether it was a software
or hardware design error), their adaptor sites on ID0, with useable
ID's for targets up through ID7. From my understanding it was
just accidentally inverted logic. Something which has plagued
both SW and HW manufactures in the past, and will continue to
do so in the future as long as we live in a binary world.
--
Bill Vermillion bv @ wjv.com
Jeff Liebermann
1. Do you think you'll get any better answers if you massively crosspost
to every SCO newsgroup, and also invent one of your own?
2. You need to turn OFF all the Plug-n-Play enhancements to get the 1542CP
to work. The 1542CF will work out of the box, the the Plug-n-Play stuff
gets in the way. Xenix doesn't have any Plug-n-Play support. Pop up the
ctrl-A stuff and turn off all the sector translation >1GB, and MSDOS
specific junk.
See:
BTLD for Adaptec AHA-1540CP/1542CP for SCO UNIX
Version 4.2 and ODT 3.0
http://www.sco.com/cgi-bin/ssl_reference?104881
This refers to a later version of SCO Unix, but the problems with
Plug-n-Play are the same. Follow the settings at the bottom and it should
work.
--
Jeff Liebermann je...@comix.santa-cruz.ca.us
150 Felker St #D Santa Cruz CA 95060
831-421-6491 pager 831-429-1240 fax
http://www.cruzio.com/~jeffl/sco/ SCO stuff
Jeff Liebermann
wrote:
>From my understanding it was
>just accidentally inverted logic. Something which has plagued
>both SW and HW manufactures in the past, and will continue to
>do so in the future as long as we live in a binary world.
How do you tell if someone is a programmer? Ask them to count to ten. The
programmer will start counting at zero. Everyone else will start at one.
Pat Welch
Why - that means us programming types are the ONLY ones CORRECTLY
celebrating 01312D65 as the REAL start of the next millennium ... :)
--
---------------------------------------------
Pat Welch, UBB Computer Services
SCO Authorized Reseller
Unix/Hardware/BB Sales & Support
Year 2000: Consulting and Repairs
*** 43 Days left 'til 1/1/2000 **
(209) 745-1401 Fax: (209) 745-5640
Nationwide pager: (800) 608-7122
E-mail: pat...@inreach.com
----------------------------------------------
Bill Vermillion
Jeff Liebermann <je...@comix.santa-cruz.ca.us> wrote:
>On Fri, 19 Nov 1999 00:29:43 GMT, bi...@wjv.com.REMOVEME (Bill Vermillion)
>wrote:
>>From my understanding it was
>>just accidentally inverted logic. Something which has plagued
>>both SW and HW manufactures in the past, and will continue to
>>do so in the future as long as we live in a binary world.
>How do you tell if someone is a programmer? Ask them to count to
>ten. The programmer will start counting at zero. Everyone else will
>start at one.
Reversed logic bit Western Digital back in the floppy days,
as the code in the 179X series differed from that in 177x series
so that certain 177x (single density) marks could not be read in
the 179x series.
Not starting a zero is why the 'picket fence error' traps so many.
For those who haven't heard that term, it basically comes
from not thinking of items which occupty the zeroeth position.
It comes from the question "If you wanted to build a fence 100 feet
long with posts 10 feet apart, how much wire and how many posts
would you need". The typical common answer is 10 posts which will
only give you a 90 foot fence.
Peter da Silva
Pat Welch <pat...@inreach.com> wrote:
> Why - that means us programming types are the ONLY ones CORRECTLY
> celebrating 01312D65 as the REAL start of the next millennium ... :)
Actually, Y2K starts 01388065.
--
In hoc signo hack, Peter da Silva <pe...@baileynm.com>
`-_-' Ar rug tú barróg ar do mhactíre inniu?
'U` "And now, little kittens, we're going to run across red-hot
motherboards, with our bare feet." -- Buzh.