[comp.periphs.scsi] Wangtek 5150ES SCSI behaviour

als@bohra.cpg.oz (Anthony Shipman) (08/06/90)

I have noticed some odd behaviour with a Wangtek 5150ES. The configuration is
	AHA1542B controller
	XT4380S	 Maxtor disk
	5150ES

The format program in the ROM on the 1542B lists all of the SCSI IDs found.
When only the disk drive is connected it just lists the drive as ID 0. When the
tape is connected it lists the disk as ID 0 and the tape as all the IDs 1-7.

Is this normal behaviour for the tape drive? Is it legal SCSI behaviour? Might
there be a bug in the format program? ID 7 is supposed to be the ID of the
controller so it seems a bit unfriendly for the tape drive to take it.

I found that the tape drive hanged my 386/ix 2.0.2 system whenever it stopped
and started while writing. The SCSI system would just stop completely. This
didn't happen if the tape happened to stream all the way through. Could this be
a result of the tape drive's SCSI behaviour or a bug in 386/ix? (This happened
on two tape drives and I sent them back).
-- 
Anthony Shipman                               ACSnet: als@bohra.cpg.oz.au
Computer Power Group
9th Flr, 616 St. Kilda Rd.,
St. Kilda, Melbourne, Australia
D

jlohmeye@entec.Wichita.NCR.COM (John Lohmeyer) (08/08/90)

In article <450@bohra.cpg.oz> als@bohra.cpg.oz (Anthony Shipman) writes:
>I have noticed some odd behaviour with a Wangtek 5150ES. The configuration is
>	AHA1542B controller
>	XT4380S	 Maxtor disk
>	5150ES
>
>The format program in the ROM on the 1542B lists all of the SCSI IDs found.
>When only the disk drive is connected it just lists the drive as ID 0. When the
>tape is connected it lists the disk as ID 0 and the tape as all the IDs 1-7.
>
This sounds like an ID conflict.  Your 1542B and tape are probably both
using the same SCSI ID.  Assuming the 1542B is at ID 7, when it polls for
SCSI devices it starts at ID 0 and works up through the IDs.  If your tape
is also strapped to ID 7, the 1542B will find it at ALL unoccupied IDs.
(It could also find it at ID 0, if the Maxtor disk was not faster than the
tape.).

Why does this happen?  Because during SELECTION phase the initiator (1542B)
puts out both the ID it is selecting and its own ID (for example, ID bits
7 and 1).  The tape which is also on ID 7 sees its ID bit (7) and the ID
bit of a phantom initiator (1).  Thus the 1542B thinks there are tapes at
all IDs (except those occupied by faster devices) and the tape thinks there
are 1542Bs at all IDs.  Strange, but it actually works fine so long as
there are only 2 devices in the system and they consistently use one set
of IDs.  Try setting your tape to another ID.



-- 
John Lohmeyer         J.Lohmeyer@Wichita.NCR.COM
NCR Corp.             uunet!ncrlnk!ncrwic!entec!jlohmeye
3718 N. Rock Rd.      Voice: 316-636-8703
Wichita, KS 67226     SCSI BBS 316-636-8700 300/1200/2400 24 hours

als@bohra.cpg.oz (Anthony Shipman) (08/14/90)

In article <632@entec.Wichita.NCR.COM>, jlohmeye@entec.Wichita.NCR.COM (John Lohmeyer) writes:
> This sounds like an ID conflict.  Your 1542B and tape are probably both
> using the same SCSI ID.  Assuming the 1542B is at ID 7, when it polls for
> SCSI devices it starts at ID 0 and works up through the IDs.  If your tape
> is also strapped to ID 7, the 1542B will find it at ALL unoccupied IDs.
> (It could also find it at ID 0, if the Maxtor disk was not faster than the
> tape.).

I have tried the tape at different IDs. It made no difference. (I never tried
it without the Maxtor drive as somebody else suggested.)

I thought maybe this behaviour was deliberate to make the tape easier to
install for M*D*S plug and play-type customers. By having the tape respond to 
any ID that no other device responded to the customer would not have to worry 
about getting all the IDs right. This seems like a brain-damaged thing to do but
then with M*D*S who can predict?

I have sent the tape drive back and will try an Archive drive like I should
have in the first place. However since I first posted the article I have
noticed postings from people which seemed to indicate that they are
successfully using the Wangtek drive with an Adaptec controller with UNIX (I
don't know which one), which worries me further - 

    Could there be a problem with the Adaptec controller that could cause these
    symptoms?

    What is the latest firmware rev number for the AHA1542B? I read somewhere
    that the rev level must be up to date for somebody's UNIX.


And a question direct to Adaptec - 
    What is the part number/order ref for the AHA1542B Technical Reference
    manual? I want to do some register level programming of the controller.
-- 
Anthony Shipman                               ACSnet: als@bohra.cpg.oz.au
Computer Power Group
9th Flr, 616 St. Kilda Rd.,
St. Kilda, Melbourne, Australia
D

fnf@fishpond.uucp (Fred Fish) (08/27/90)

In article <450@bohra.cpg.oz> als@bohra.cpg.oz (Anthony Shipman) writes:
>I have noticed some odd behaviour with a Wangtek 5150ES. The configuration is
>...
>The format program in the ROM on the 1542B lists all of the SCSI IDs found.
>When only the disk drive is connected it just lists the drive as ID 0. When the
>tape is connected it lists the disk as ID 0 and the tape as all the IDs 1-7.

I have seen a Wangtek 5150ES that had exactly the same problem.  It was
strapped for ID #4 but answered to all ID's except 0.  It worked fine
with a single disk drive at ID 0, but when a second disk was added at
ID 1 the second disk collided with the tape drive.  Took a while to figure
out what was going on.  The 5150ES that had this problem was serial
number 890843J8, assembly number 30601-201 Rev C.  U32 has the tag
23647-001 EOC4 and U30 has 23646-001 C700.

-Fred
-- 
# Fred Fish, 1835 E. Belmont Drive, Tempe, AZ 85284,  USA
# 1-602-491-0048               asuvax!mcdphx!fishpond!fnf