Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!mips!sgi!shinobu!odin!anchor!olson
From: olson@anchor.esd.sgi.com (Dave Olson)
Newsgroups: comp.sys.sgi
Subject: Re: 4D35 Disks (I'm being bit) with Details!
Message-ID: <1991Jun9.201238.26789@odin.corp.sgi.com>
Date: 9 Jun 91 20:12:38 GMT
References: <1991Jun6.194109.1407@colorado.edu> <1991Jun6.221905.3291@nntp-server.caltech.edu> <1991Jun7.222455.5539@odin.corp.sgi.com> <1991Jun8.054208.18831@nntp-server.caltech.edu>
Sender: news@odin.corp.sgi.com (Net News)
Organization: Silicon Graphics, Inc.  Mountain View, CA
Lines: 48

In <1991Jun8.054208.18831@nntp-server.caltech.edu> woolstar@nntp-server.caltech.edu (John D. Woolverton) writes:


|     I had a nice, quiet, third party hitachi 3 1/2 drive in
| my temporary 4d25, and when they upgraded to the 4d35, it
| stopped working.
|     Someone mentioned that the SCSI controllers changed from
| SCSI1 to SCSI2.

...

| The dirty details of my trials,
|     Upon BOOT UP:
| SCSI device/cable diagnostic		*FAILED*
| Diagnostic failed
| 
|     This unit is in the periferal(sp?) bay with the tape drive.
| Suspecting the mounting bracket, I switch the two, but had the
| same failure with the disk drive again.
|     Telling the machine to boot anyways...

This is probably the senddiag or startunit command failing; if
you boot ide, interrupt it, do 'set report 4', then run 'scsi',
you should be able to tell for sure.


| Jun  7 22:14:34 sgi grcond[190]: In limbo
|  Alive
|   driver error 1
|  dks0d1s0: invalid sense data, can't determine cause of error
|  dks0d1s0: retrying request
|  sc0,2,0: Unexpected info phase 46, state 49.  Resetting SCSI bus

| At this point, I'm wondering if this mess is properly terminated.
| I'll probably go over it with a fine tooth comb again this weekend,
| and maybe I'll be up and working.  It's a problem.

My best guess is indeed that you have termination or cabling 
problems.  phase 46 state 49 means that the scsi chip expected
a status phase because the byte count had dropped to 0, but the
device was sending more data instead.  This is almost always caused
by cabling / termination, although in rare cases it can be drive firmware
or driver bugs; for disk drives it is almost alway cabling/termination.
--

	Dave Olson

Life would be so much easier if we could just look at the source code.