[prev in list] [next in list] [prev in thread] [next in thread] 

List:       linux-scsi
Subject:    Re: new ncr/sym53c8xx driver tree at tux
From:       Gerard Roudier <groudier () club-internet ! fr>
Date:       1999-03-31 20:30:06
[Download RAW message or body]


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?

What king of posture are you talking about ? :-))

I just checked how my disks are responding for readyness.
Most told me that the BUS had been reset, which was quite relevant, but 
just a "don't care" since I have been the resetter. :-)

Below is what one of them told me, using both the ncr generic and 
the sym drivers.

<6>sym53c896-0-<0,0>: ERROR: cmd=0 host_status=84 scsi_status=2
<6>sym53c896-0-<0,0>: sense data: 70 0 6 0 0 0 0 a 0 0 0 0 29 2.
<4>  Vendor: SEAGATE   Model: ST39102LW         Rev: 0004
<4>  Type:   Direct-Access                      ANSI SCSI revision: 02
<4>Detected scsi disk sda at scsi0, channel 0, id 0, lun 0

<6>ncr53c896-0-<0,0>: ERROR: cmd=0 host_status=84 scsi_status=2
<6>ncr53c896-0-<0,0>: sense data: 70 0 6 0 0 0 0 a 0 0 0 0 29 2.
<4>  Vendor: SEAGATE   Model: ST39102LW         Rev: 0004
<4>  Type:   Direct-Access                      ANSI SCSI revision: 02
<4>Detected scsi disk sda at scsi1, channel 0, id 0, lun 0

Dont know what may be wrong with your device. At this step, the driver is
not using tags at all, and does not try to negotiate since it does not
know of capabilities of the device yet (INQUIRY hasn't been performed
yet). On the other hand, the scsi driver is nicely queuing 1 command at 
a time.

It would be interesting to check if it is not some lost interrupt problem
as I suggest in my first reply.

Regards,
  Gérard.


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

[prev in list] [next in list] [prev in thread] [next in thread]