Re: QLGC,ISP SCSI driver not finding attached devices

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi all,

Timing does not apear to be an issue. I have checked all the udelay/msleep calls I could find and thoes that get called are delaying by the correct delay (4 to 7us > specified value).

I have added some more debugging info and it looks like somthing is getting corrupted in the INQUIRY command as it is returning:

  Sense Key : Illegal Request [current]
  Add. Sense: Invalid field in cdb

According a of the SCSI2 Std that I have, this equates to one of the following:

	EVPD set and Vital Product Data not supported
	EVPD clear and Page Code non-zero
	Control Field Flag set and Link not set

Looking into the issue a bit further, it turns out the the Sparc32 memset is broaken - it does not always set the last byte. As a result, the Control Field is set to random value (0xE0 in this case). This explains all sorts of odd issues. Next step is to fix memset. I will try again once I am sure memset is working.

Regards
	Mark Fortescue.

On Mon, 23 Jul 2007, James Bottomley wrote:

On Mon, 2007-07-23 at 23:41 +0100, Mark Fortescue wrote:
Hi James,

Can you point me in the direction of any documentation to aid me in
identifing what debugging I need to work out what is going on?

they're all in include/scsi/scsi.h

The code is divided into four bytes (from LSB): status, message, host
and driver.  The status is what the SCSI command actually returned (if
anything) the message is what the transport said (least used of the
status codes).  The host byte signals an error condition with the card
and the driver byte with the driver (plus an optional suggestion of what
to do about it).

For targets without any connected disk, I get scan responses of:
     scsi scan: INQUIRY failed with code 0x40000
after app 417ms.

That's host byte 0x04 which is DID_BAD_TARGET.

For targets with a disk connected, I get scan responses of:
     scsi scan: INQUIRY failed with code 0x8000002
after app 170ms.

Thats SCSI status 0x02 (which is CHECK_CONDITION) and driver byte of
0x08, which is DRIVER_SENSE (as in the device returned a sense code).
This is really strange, because the INQUIRY command isn't supposed to be
allowed to return a sense code for precisely this initial scan reason.
This tends to point to a device failure.

James


-
To unsubscribe from this list: send the line "unsubscribe sparclinux" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [SCSI Target Devel]     [Linux SCSI Target Infrastructure]     [Kernel Newbies]     [IDE]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux ATA RAID]     [Linux IIO]     [Samba]     [Device Mapper]
  Powered by Linux