[PATCH] Retry INQUIRY on power-on

[PATCH] Retry INQUIRY on power-on

[Hannes Reinecke]

[-- Attachment #1: Type: text/plain, Size: 594 bytes --]

Hi all,

the current inquiry code in scsi_scan.c:scsi_probe_lun() will retry the
inquiry only for ASC/ASCQ 0x28/0x0 and 0x29/0x0. When I'm hot-plugging a
disk no reset has necessarily happened, so the first rescan will fail.
The disk is found properly on the second rescan.

So we really should loosen that statement to do retry for all ASC 0x29
values as a power-on might well have occured without a reset.

Please apply.

Cheers,

Hannes
-- 
Dr. Hannes Reinecke			hare@suse.de
SuSE Linux Products GmbH		S390 & zSeries
Maxfeldstraße 5				+49 911 74053 688
90409 Nürnberg				http://www.suse.de

[-- Attachment #2: scsi-scan-retry-on-poweron --]
[-- Type: text/plain, Size: 850 bytes --]

From: Hannes Reinecke <hare@suse.de>
Subject: Retry INQUIRY on power-on

The current code retries INQUIRY only for ASC/ASCQ 0x29/0x0
(POWER ON, RESET, OR BUS DEVICE RESET OCCURRED). This means drives
which have been hot-removed (ie without a reset) won't be detected
upon rescan. So we should loose this condition to enable a retry
for the ASC 0x29 in general.

Signed-off-by: Hannes Reinecke

diff --git a/drivers/scsi/scsi_scan.c b/drivers/scsi/scsi_scan.c
index f149459..f6ead5c 100644
--- a/drivers/scsi/scsi_scan.c
+++ b/drivers/scsi/scsi_scan.c
@@ -514,8 +514,7 @@ static int scsi_probe_lun(struct scsi_de
 			    scsi_sense_valid(&sshdr)) {
 				if ((sshdr.sense_key == UNIT_ATTENTION) &&
 				    ((sshdr.asc == 0x28) ||
-				     (sshdr.asc == 0x29)) &&
-				    (sshdr.ascq == 0))
+				     (sshdr.asc == 0x29)))
 					continue;
 			}
 		}

Re: [PATCH] Retry INQUIRY on power-on

[James Bottomley]

On Fri, 2006-03-31 at 15:12 +0200, Hannes Reinecke wrote:
> So we really should loosen that statement to do retry for all ASC 0x29
> values as a power-on might well have occured without a reset.

Actually, there's probably no reason to qualify the UNIT_ATTENTION at
all.  Any device that replies UNIT_ATTENTION to INQUIRY is out of spec,
so it's reasonable to assume that the ASC/ASCQ responses aren't in spec
either.  There doesn't seem to be a disadvantage to just retrying three
times in all unit attention cases.

Did you have time to look at the reset locking issue that turned up in
the aic7xxx backport?

James

Re: [PATCH] Retry INQUIRY on power-on

[Hannes Reinecke]

James Bottomley wrote:
> On Fri, 2006-03-31 at 15:12 +0200, Hannes Reinecke wrote:
>> So we really should loosen that statement to do retry for all ASC 0x29
>> values as a power-on might well have occured without a reset.
> 
> Actually, there's probably no reason to qualify the UNIT_ATTENTION at
> all.  Any device that replies UNIT_ATTENTION to INQUIRY is out of spec,
> so it's reasonable to assume that the ASC/ASCQ responses aren't in spec
> either.  There doesn't seem to be a disadvantage to just retrying three
> times in all unit attention cases.
> 
Well, after looking through the trace I discovered it's not actually a
broken device, but rather more a driver issue:

- SCSI ML sends inquiry
- HBA cannot send message as transport parameters are invalid
- HBA requests sense
- HBA sets the sense code and returns command with code 'ADD_TO_MLQUEUE'
  to inform ML to retry the command

Only the ML fails to honour the ADD_TO_MLQUEUE code as this is
scsi_scan(), which doesn't check for it.
So if anything then rather the code in scsi_scan should been fixed to
retry the command if so advised from the LLD.

> Did you have time to look at the reset locking issue that turned up in
> the aic7xxx backport?
> 
Already sent.

Cheers,

Hannes
-- 
Dr. Hannes Reinecke			hare@suse.de
SuSE Linux Products GmbH		S390 & zSeries
Maxfeldstraße 5				+49 911 74053 688
90409 Nürnberg				http://www.suse.de
---
Excerpt of the trace:

 4:0:10:0: scsi scan: INQUIRY pass 1 length 36
scsi_add_timer: scmd: d6d57e00, time: 1375, (e083d29e)
 4:0:10:0: send 0xd6d57e00                   4:0:10:0:
        command: Inquiry: 12 00 00 00 24 00
buffer = 0xd8baf880, bufflen = 36, done = 0xe083ec8a, queuecommand
0xe0ceeb1c
leaving scsi_dispatch_cmnd()
scsi4:A:10:0: INITIATOR_MSG_OUT byte 0x1
WDTR negotiation rejected busfree.
scsi4: ILLEGAL_PHASE 0x80
 target4:0:10: asynchronous
(scsi4:A:10:0): Unexpected command phase from packetized target
scsi4:A:10:0: Attempt to issue message failed
(scsi4:A:10:0): SCB 1: requests Check Status
(scsi4:A:10:0): Sending Sense
Copied 18 bytes of sense data at 0:
0x70 0x0 0x6 0x0 0x0 0x0 0x0 0xa 0x0 0x0 0x0 0x0 0x29 0x1 0x1 0x0
0x0 0x0
scsi_delete_timer: scmd: d6d57e00, rtn: 1
 4:0:10:0: done 0xd6d57e00 SUCCESS  8000002  4:0:10:0:
        command: Inquiry: 12 00 00 00 24 00
: Current: sense key: Unit Attention
    Additional sense: Power on occurred
scsi scan: INQUIRY failed with code 0x8000002
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] Retry INQUIRY on power-on

[Mike Christie]

Hannes Reinecke wrote:
> James Bottomley wrote:
>> On Fri, 2006-03-31 at 15:12 +0200, Hannes Reinecke wrote:
>>> So we really should loosen that statement to do retry for all ASC 0x29
>>> values as a power-on might well have occured without a reset.
>> Actually, there's probably no reason to qualify the UNIT_ATTENTION at
>> all.  Any device that replies UNIT_ATTENTION to INQUIRY is out of spec,
>> so it's reasonable to assume that the ASC/ASCQ responses aren't in spec
>> either.  There doesn't seem to be a disadvantage to just retrying three
>> times in all unit attention cases.
>>
> Well, after looking through the trace I discovered it's not actually a
> broken device, but rather more a driver issue:
> 
> - SCSI ML sends inquiry
> - HBA cannot send message as transport parameters are invalid
> - HBA requests sense
> - HBA sets the sense code and returns command with code 'ADD_TO_MLQUEUE'
>   to inform ML to retry the command
> 
> Only the ML fails to honour the ADD_TO_MLQUEUE code as this is
> scsi_scan(), which doesn't check for it.
> So if anything then rather the code in scsi_scan should been fixed to
> retry the command if so advised from the LLD.
> 

Normally, a request from the scsi scan code should go through 
scsi_softirq_done which checks for scsi_decide_disposition returning 
ADD_TO_MLQUEUE. Is aic7xxx setting the host byte to DID_REQUEUE?