[6233] in linux-scsi channel archive

home help back first fref pref prev next nref lref last post

Re: new ncr/sym53c8xx driver tree at tux

daemon@ATHENA.MIT.EDU (Gerard Roudier)
Wed Mar 31 15:40:42 1999

Date: 	Wed, 31 Mar 1999 21:25:59 +0200 (MET DST)
From: Gerard Roudier <groudier@club-internet.fr>
To: Matthew Jacob <mjacob@feral.com>
cc: linux-scsi@vger.rutgers.edu, ncr53c810@Colorado.EDU
In-Reply-To: <Pine.LNX.4.04.9903311121570.3363-100000@feral-gw>



On Wed, 31 Mar 1999, Matthew Jacob wrote:

> > > scsi : aborting command due to timeout :
> > > pid 54, scsi2, channel 0, id 0, lun 0 Test Unit Ready 00 00 00 00 00 
> > 
> > The failure occurs on the first TEST_UNIT_READY sent to a device of this
> > SCSI BUS. That is simply strange, since the device should be quick at
> > responding, and this command does not need any DATA PHASE.
> > At this step, the driver does not try to negotiate anything and the SCSI
> > BUS has just been reset, so the failure seems double-strange to me.
> > And The fact that the first 875 just succeeds makes your problem appear
> > triple-strange to me. ;-) 
> 
> It's auto-request sense that's probably failing for post TUR?

May-be. But a SCSI device should only be expected to return a CHECK
CONDITION on TEST_UNIT_READY if something serious may prevent from sending
it other commands, and the drive is probably just ready to operate when it
is asked for readyness. Perhaps some drive want to tell us some don't care
thing at this step, who knows? 
Anyway, the auto-sense, if any, should not fail.
Will check if my devices are returning CHECK CONDITION on TEST UNIT READY 
and how the driver behaves.
(ncr53c8xx=debug:0x10 should help)

Gérard.


-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@vger.rutgers.edu

home help back first fref pref prev next nref lref last post