Bug 13799 - [PATCH] - Peripheral qualifier field not used
Summary: [PATCH] - Peripheral qualifier field not used
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: kernel
Version: 7.1
Hardware: All
OS: Linux
high
medium
Target Milestone: ---
Assignee: Michael K. Johnson
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2000-07-12 14:48 UTC by Matt Domsch
Modified: 2008-05-01 15:37 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2000-07-21 19:11:30 UTC
Embargoed:


Attachments (Terms of Use)

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


Note You need to log in before you can comment on or make changes to this bug.