Bug 13799

Summary: [PATCH] - Peripheral qualifier field not used
Product: [Retired] Red Hat Linux Reporter: Matt Domsch <matt_domsch>
Component: kernelAssignee: Michael K. Johnson <johnsonm>
Status: CLOSED RAWHIDE QA Contact:
Severity: medium Docs Contact:
Priority: high    
Version: 7.1   
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2000-07-21 19:11:30 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Matt Domsch 2000-07-12 14:48:40 UTC
It seems, upon reading the 2.2.16 and 2.4.0-test1 source, that the 
peripheral qualifier field of a SCSI inquiry isn't really used (except to 
skip LUNs where a physical device is 
not supported).  To refresh, the peripheral qualifier field is the top 3 
bits of byte 0 of the inquiry data, particularly the two values:
	000b - physical device is connected to this LUN
	001b - physical device *can* be connected to this LUN, but is not 
presently

We have a device, part of a storage area network (SAN), that returns 000b 
in this field if there is a disk attached that can be directly accessed by 
this system, or 001b if the LUN would be supported, but is actually being 
handled by a different controller.  This would seem to be the proper use 
of this field.

Since the scsi layer does not read/use these bits, when the LUN shows up 
as TYPE_DISK, a READ_CAPACITY command is issued to the disk.  In the 000b 
case, this is proper.  In the 001b, this is not, as the device isn't 
really there, it's merely a placeholder, and the command returns with a 
check condition, and no further I/Os are performed.  The outcome is 
proper, but there's an error printed that could be avoided by making use 
of the peripheral qualifier bits, which could lead to a customer 
satisfaction issue, tech support calls about SCSI errors, and the like.

I'd like sd.c to be able to ignore 001b devices, so it looks like the 
right thing to do is to set SDp->online = FALSE in scan_scsis_single() in 
this case.  Patches to 2.2.16 and 2.4.0-test1 below.

Thoughts?


Thanks,
Matt Domsch
Dell Enterprise Systems Group
Linux Development Team

--- linux-2.4.0-test1/drivers/scsi/scsi_scan.c.orig	Tue Jul 11 
11:41:56 2000
+++ linux/drivers/scsi/scsi_scan.c	Tue Jul 11 11:44:33 2000
@@ -552,7 +552,8 @@
 	memcpy(SDpnt->rev, scsi_result + 32, 4);
 
 	SDpnt->removable = (0x80 & scsi_result[1]) >> 7;
-	SDpnt->online = TRUE;
+	if (((scsi_result[0] >> 5) & 7) == 1) 	SDpnt->online = FALSE;
+	else SDpnt->online = TRUE;
 	SDpnt->lockable = SDpnt->removable;
 	SDpnt->changed = 0;
 	SDpnt->access_count = 0;

--- linux-2.2.16/drivers/scsi/scsi.c.orig	Tue Jul  4 04:20:59 2000
+++ linux/drivers/scsi/scsi.c scsi.c	Tue Jul 11 06:45:46 2000
@@ -796,7 +796,8 @@
   memcpy (SDpnt->rev, scsi_result + 32, 4);
 
   SDpnt->removable = (0x80 & scsi_result[1]) >> 7;
-  SDpnt->online = TRUE;
+  if (((scsi_result[0] >> 5) & 7) == 1)  SDpnt->online = FALSE;
+  else SDpnt->online = TRUE;
   SDpnt->lockable = SDpnt->removable;
   SDpnt->changed = 0;
   SDpnt->access_count = 0;

Comment 1 Glen Foster 2000-07-18 20:22:19 UTC
This defect is considered MUST-FIX for Winston Beta-5


Comment 2 Matt Domsch 2000-07-21 19:11:08 UTC
Winston Beta 4 includes kernel 2.2.16-12, which includes this patch.

Comment 3 Matt Domsch 2000-07-21 19:52:28 UTC
Patch present in Winston Beta 4, kernel 2.2.16-12.

Comment 4 Glen Foster 2000-07-21 20:33:28 UTC
This defect has been re-classified as MUST-FIX for Winston Gold-release