Retry INQUIRY on power-on
PATCH 1/1 Retry INQUIRY on power-on
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
Signature · 4 lines
Dr. Hannes Reinecke [email protected] SuSE Linux Products GmbH S390 & zSeries Maxfeldstraße 5 +49 911 74053 688 90409 Nürnberg http://www.suse.de
From: Hannes Reinecke <[email protected]>
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.
drivers/scsi/scsi_scan.c +1 -2
@@ -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 ; } }
Quoted 2 lines · Hannes Reinecke
So we really should loosen that statement to do retry for all ASC
0x29values 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
Quoted 10 lines · James Bottomley
Quoted 2 lines · Hannes Reinecke
So we really should loosen that statement to do retry for all ASC
0x29values as a power-on might well have occured without a reset.Actually, there's probably no reason to qualify the
UNIT_ATTENTIONat all. Any device that repliesUNIT_ATTENTIONto 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.
Quoted 3 lines
Did you have time to look at the reset locking issue that turned up in the aic7xxx backport?
Already sent.
Cheers,
Hannes
Signature · 35 lines
Dr. Hannes Reinecke [email protected] 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 [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
Quoted 19 lines · Hannes Reinecke
Quoted 9 lines · James Bottomley
Quoted 2 lines · Hannes Reinecke
So we really should loosen that statement to do retry for all ASC
0x29values as a power-on might well have occured without a reset.Actually, there's probably no reason to qualify the
UNIT_ATTENTIONat all. Any device that repliesUNIT_ATTENTIONto 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
Quoted 5 lines
Only the ML fails to honour the
ADD_TO_MLQUEUEcode as this isscsi_scan(), which doesn't check for it.
So if anything then rather the code inscsi_scanshould 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?