[PATCH] 2.4.19 scsi_rescan patch (2nd pass)

[PATCH] 2.4.19 scsi_rescan patch (2nd pass)

[Cress, Andrew R]

Folks,

Here is a 2nd pass at a patch to do a scsi rescan so that hot-inserted scsi
disks can automatically be recognized.  It includes some recommended
changes/cleanup from Patrick and Mike.

Andy Cress

---------------
--- linux-2.4.19-orig/drivers/scsi/hosts.h	Mon Feb 25 14:38:04 2002
+++ linux-2.4.19/drivers/scsi/hosts.h	Wed Oct  2 09:33:02 2002
@@ -418,6 +418,8 @@
      */
     unsigned some_device_starved:1;
    
+    unsigned init_done:1;
+    unsigned char need_scan; 
     void (*select_queue_depths)(struct Scsi_Host *, Scsi_Device *);
 
     /*
--- linux-2.4.19-orig/drivers/scsi/scsi.c	Fri Aug  2 20:39:44 2002
+++ linux-2.4.19/drivers/scsi/scsi.c	Wed Oct  2 09:33:02 2002
@@ -1980,8 +1980,10 @@
 			for (SDpnt = shpnt->host_queue; SDpnt; SDpnt =
SDpnt->next)
 				if (SDpnt->host->hostt == tpnt) {
 					for (sdtpnt = scsi_devicelist;
sdtpnt; sdtpnt = sdtpnt->next)
-						if (sdtpnt->attach)
+						if (sdtpnt->attach) {
 							(*sdtpnt->attach)
(SDpnt);
+							SDpnt->need_attach =
FALSE;
+						}
 					if (SDpnt->attached) {
 
scsi_build_commandblocks(SDpnt);
 						if (0 ==
SDpnt->has_cmdblocks)
@@ -2003,6 +2005,9 @@
 				(*sdtpnt->finish) ();
 			}
 		}
+		for (shpnt = scsi_hostlist; shpnt; shpnt = shpnt->next) {
+			shpnt->init_done = 1;
+		}
 	}
 #if defined(USE_STATIC_SCSI_MEMORY)
 	printk("SCSI memory: total %ldKb, used %ldKb, free %ldKb.\n",
@@ -2296,8 +2301,10 @@
 		     SDpnt = SDpnt->next) {
 			SDpnt->attached += SDpnt->detected;
 			SDpnt->detected = 0;
-			if (tpnt->attach)
+			if (tpnt->attach) {
 				(*tpnt->attach) (SDpnt);
+				SDpnt->need_attach = FALSE;
+			}
 			/*
 			 * If this driver attached to the device, and don't
have any
 			 * command blocks for this device, allocate some.
--- linux-2.4.19-orig/drivers/scsi/scsi.h	Fri Aug  2 20:39:44 2002
+++ linux-2.4.19/drivers/scsi/scsi.h	Wed Oct  2 09:33:02 2002
@@ -617,6 +617,7 @@
 	unsigned remap:1;	/* support remapping  */
 	unsigned starved:1;	/* unable to process commands because
 				   host busy */
+	unsigned need_attach:1; /* newly rescanned, need to attach device */
 
 	// Flag to allow revalidate to succeed in sd_open
 	int allow_revalidate;
--- linux-2.4.19-orig/drivers/scsi/scsi_lib.c	Fri Aug  2 20:39:44 2002
+++ linux-2.4.19/drivers/scsi/scsi_lib.c	Wed Oct  2 09:40:15 2002
@@ -5,6 +5,8 @@
  *      Initial versions: Eric Youngdale (eric@andante.org).
  *                        Based upon conversations with large numbers
  *                        of people at Linux Expo.
+ *      10/02/2002 - Andrew.R.Cress@intel.com, added scsi_rescan to
+ *                     automatically recognize hot-inserted disks
  */
 
 /*
@@ -819,6 +821,68 @@
 	return NULL;
 }
 
+void scsi_rescan(struct Scsi_Host *SHpnt, unsigned int channel)
+{
+	Scsi_Device *SDpnt;
+	struct Scsi_Device_Template *sdtpnt;
+	int out_of_space = 0;
+	int new_dev = 0;
+	int fdidattach;
+
+	/* 
+	 * Do scan_scsis here.  This generates the Scsi_Devices entries.
+	 * Since SHpnt->init_done, if devices already exist, skip them. 
+	 */
+	scan_scsis(SHpnt, 0, channel, 0, 0);
+
+	for (sdtpnt = scsi_devicelist; sdtpnt; sdtpnt = sdtpnt->next) {
+		if (sdtpnt->init && sdtpnt->dev_noticed)
+			(*sdtpnt->init) ();
+	}
+
+	/* Next we create the Scsi_Cmnd structures for new devices */
+	for (SDpnt = SHpnt->host_queue; SDpnt; SDpnt = SDpnt->next) {
+		fdidattach = 0;
+		if (SDpnt->host->host_no == SHpnt->host_no) {
+			for (sdtpnt = scsi_devicelist; sdtpnt; sdtpnt =
sdtpnt->next) {
+				/* 
+				 * attached can be set here for the new one,
+				 * so also check if queue_depth has been 
+				 * set to a normal value yet (> 2).
+				 */
+				if (SDpnt->need_attach && sdtpnt->attach) {
+					/*Note /dev/sd* maj=8, /dev/sg*
maj=21*/
+					(*sdtpnt->attach) (SDpnt);
+					fdidattach = 1;
+			  	} /*endif need_attach*/
+			} /*end sdtpnt loop*/
+			if (fdidattach) {
+			    fdidattach = 0;
+			    new_dev++;
+                	    if (SHpnt->select_queue_depths != NULL) {
+				(SHpnt->select_queue_depths) (SHpnt,
SHpnt->host_queue);
+			    }
+			    if (SDpnt->need_attach && SDpnt->attached) {
+				SDpnt->need_attach = FALSE;
+				scsi_build_commandblocks(SDpnt);
+				if (0 == SDpnt->has_cmdblocks)
+					out_of_space = 1;
+			    }
+			}
+		} /*endif match host_no */
+	}  /*end SDpnt loop*/
+
+	/* May have added some devices, so resize the DMA pool. */
+	if (new_dev > 0 && !out_of_space) scsi_resize_dma_pool();
+
+	for (sdtpnt = scsi_devicelist; sdtpnt; sdtpnt = sdtpnt->next) {
+		if (sdtpnt->finish && sdtpnt->nr_dev) 
+			(*sdtpnt->finish) (); 
+	}
+	printk("scsi_rescan: %d new devices added\n",new_dev);
+
+} /*end scsi_rescan*/
+
 /*
  * Function:    scsi_request_fn()
  *
@@ -919,6 +983,17 @@
 				spin_lock_irq(&io_request_lock);
 				continue;
 			}
+
+			if (!in_interrupt()) {
+			   /* Check if we need to rescan after a reset.
ARC*/
+			   if (SDpnt->host->need_scan == 1) {
+				SDpnt->host->need_scan = 2;
+				spin_unlock_irq(&io_request_lock);
+				scsi_rescan(SDpnt->host,SDpnt->channel);
+				spin_lock_irq(&io_request_lock);
+				SDpnt->host->need_scan = 0;
+			   }
+			}
 		}
 
 		/*
@@ -1176,6 +1251,11 @@
 			SDloop->was_reset = 1;
 			SDloop->expecting_cc_ua = 1;
 		}
+	}
+	if (SHpnt->init_done == 1 && SHpnt->need_scan == 0) {
+		SHpnt->need_scan = 1; 
+		printk("scsi_report_bus_reset: scsi%d, channel %d
need_scan\n",
+			SHpnt->host_no,channel);
 	}
 }
 
--- linux-2.4.19-orig/drivers/scsi/scsi_scan.c	Fri Aug  2 20:39:44 2002
+++ linux-2.4.19/drivers/scsi/scsi_scan.c	Wed Oct  2 09:33:02 2002
@@ -287,6 +287,28 @@
 }
 
 /*
+ * scsi_dev_skip
+ * Returns 1 if there was already a device on this host at the same
+ * channel/dev/lun, indicating that the caller should skip this one.
+ * Make sure to not match the new/temp device created for the scan 
+ * (sdnew).  sdpnt->attached is often already set here on the new 
+ * device(s), so we can't use that. 
+ */
+static int
+scsi_dev_skip(struct Scsi_Host *shpnt, uint channel, uint dev, uint lun,
+              Scsi_Device *sdnew)
+{
+	Scsi_Device *sdpnt;
+	for (sdpnt = shpnt->host_queue; sdpnt; sdpnt = sdpnt->next)
+		if (sdpnt != sdnew && (sdpnt->host == shpnt) &&  
+		    (sdpnt->id == dev) && (sdpnt->lun == lun) &&
+		    (sdpnt->channel == channel)) {
+			return 1;
+		}
+	return 0;
+}  /*end scsi_dev_skip*/
+
+/*
  *  Detecting SCSI devices :
  *  We scan all present host adapter's busses,  from ID 0 to ID (max_id).
  *  We use the INQUIRY command, determine device type, and pass the ID /
@@ -380,6 +402,8 @@
 		lun = hlun;
 		if (lun >= shpnt->max_lun)
 			goto leave;
+		if (shpnt->init_done && 
+		    scsi_dev_skip(shpnt,hchannel,hid,hlun,SDpnt)) goto
leave;
 		if ((0 == lun) || (lun > 7))
 			lun0_sl = SCSI_3; /* actually don't care for 0 ==
lun */
 		else
@@ -402,6 +426,7 @@
 			for (sdtpnt = scsi_devicelist; sdtpnt; sdtpnt =
sdtpnt->next) {
 				if (sdtpnt->attach) {
 					(*sdtpnt->attach) (oldSDpnt);
+					oldSDpnt->need_attach = FALSE;
 					if (oldSDpnt->attached) {
 
scsi_build_commandblocks(oldSDpnt);
 						if (0 ==
oldSDpnt->has_cmdblocks) {
@@ -445,6 +470,9 @@
 						/* don't probe further for
luns > 7 for targets <= SCSI_2 */
 						if ((lun0_sl < SCSI_3) &&
(lun > 7))
 							break;
+						if (shpnt->init_done &&
+
scsi_dev_skip(shpnt,channel,dev,lun, SDpnt)) 
+                                                	continue; /* ARC*/
 
 						if
(!scan_scsis_single(channel, order_dev, lun, lun0_sl,
 
&max_dev_lun, &sparse_lun, &SDpnt, shpnt,
@@ -528,6 +556,10 @@
 	extern devfs_handle_t scsi_devfs_handle;
 	int scsi_level;
 
+	if (SDpnt == NULL) {
+		printk("scan_scsis_single: SDpnt = NULL\n");
+		return 0;
+	}
 	SDpnt->host = shpnt;
 	SDpnt->id = dev;
 	SDpnt->lun = lun;
@@ -559,7 +591,8 @@
 	 * devices (and TEST_UNIT_READY to poll for media change). - Paul G.
 	 */
 
-	SCSI_LOG_SCAN_BUS(3, printk("scsi: performing INQUIRY\n"));
+	SCSI_LOG_SCAN_BUS(3, printk("scsi_scan: [%d:%d:%d:%d] performing
INQUIRY\n",
+				shpnt->host_no, channel, dev, lun));
 	/*
 	 * Build an INQUIRY command block.
 	 */
@@ -587,12 +620,19 @@
 	 * for media change conditions here, so cannot require zero result.
 	 */
 	if (SRpnt->sr_result) {
+		int attn_ok = 0;
 		if ((driver_byte(SRpnt->sr_result) & DRIVER_SENSE) != 0 &&
-		    (SRpnt->sr_sense_buffer[2] & 0xf) == UNIT_ATTENTION &&
-		    SRpnt->sr_sense_buffer[12] == 0x28 &&
+		    (SRpnt->sr_sense_buffer[2] & 0xf) == UNIT_ATTENTION) {
+		  if (SRpnt->sr_sense_buffer[12] == 0x28 &&
 		    SRpnt->sr_sense_buffer[13] == 0) {
 			/* not-ready to ready transition - good */
-		} else {
+			attn_ok = 1;
+		  } else if (SRpnt->sr_sense_buffer[12] == 0x29) {
+			/* 06/29/xx = reset occurred, but ok now - ARC */
+			attn_ok = 1;
+		  } 
+		}
+		if (!attn_ok) {
 			/* assume no peripheral if any other sort of error
*/
 			scsi_release_request(SRpnt);
 			return 0;
@@ -691,9 +731,12 @@
 
 	for (sdtpnt = scsi_devicelist; sdtpnt;
 	     sdtpnt = sdtpnt->next)
-		if (sdtpnt->detect)
+		if (sdtpnt->detect) {
 			SDpnt->attached +=
 			    (*sdtpnt->detect) (SDpnt);
+			/* did detect, but still need attach */
+			SDpnt->need_attach = TRUE;  
+		}
 
 	SDpnt->scsi_level = scsi_result[2] & 0x07;
 	if (SDpnt->scsi_level >= 2 ||

Re: [PATCH] 2.4.19 scsi_rescan patch (2nd pass)

[James Bottomley]

andrew.r.cress@intel.com said:
> Here is a 2nd pass at a patch to do a scsi rescan so that hot-inserted
> scsi disks can automatically be recognized.  It includes some
> recommended changes/cleanup from Patrick and Mike. 

Is there a really good reason we can't use the hotplug infrastructure for this 
and scan from user level?  I know the 2.4 hotplug is less well developed than 
2.5, but I believe it will work well enough for this.

If you go the hotplug route, all we need is a hook to trigger the SCSI hotplug 
event.

James

RE: [PATCH] 2.4.19 scsi_rescan patch (2nd pass)

[Cress, Andrew R]

James,

I had been trying to do that with a user-level daemon I've written
(sgraidmon at scsirastools.sf.net), but I can't rescan from user level
because the new devices aren't attached to any /dev, so the user-level can't
detect that a new device has been inserted, and it doesn't have any way to
detect which device it might be.  

Previous development has assumed that some administrator "knows" what the
new device is and that it has been inserted, in order to invoke a hotplug
function.  My use case is to make software RAID more like hardware RAID,
where a service tech inserts the disk and walks away, and the software raid
(OS & daemon) detects it and handles it automatically.

Andy

-----Original Message-----
From: James Bottomley [mailto:James.Bottomley@steeleye.com] 
Sent: Wednesday, October 02, 2002 11:35 AM
To: Cress, Andrew R
Cc: linux-scsi@vger.kernel.org
Subject: Re: [PATCH] 2.4.19 scsi_rescan patch (2nd pass) 

andrew.r.cress@intel.com said:
> Here is a 2nd pass at a patch to do a scsi rescan so that hot-inserted
> scsi disks can automatically be recognized.  It includes some
> recommended changes/cleanup from Patrick and Mike. 

Is there a really good reason we can't use the hotplug infrastructure for
this 
and scan from user level?  I know the 2.4 hotplug is less well developed
than 
2.5, but I believe it will work well enough for this.

If you go the hotplug route, all we need is a hook to trigger the SCSI
hotplug 
event.

James

Re: [PATCH] 2.4.19 scsi_rescan patch (2nd pass)

[James Bottomley]

andrew.r.cress@intel.com said:
> I had been trying to do that with a user-level daemon I've written
> (sgraidmon at scsirastools.sf.net), but I can't rescan from user level
> because the new devices aren't attached to any /dev, so the user-level
> can't detect that a new device has been inserted, and it doesn't have
> any way to detect which device it might be.   

Right, that's why the hotplug event has to carry enough information to allow 
the script to identify what needs to be scanned (i.e. SCSI hostadapter number 
and PUN if possible). the scsi add-single-device mechanism can then be used to 
do the attachment (and scanning).

James

RE: [PATCH] 2.4.19 scsi_rescan patch (2nd pass)

[Cress, Andrew R]

James,

A user-space hotplug event can't be guaranteed to have enough information in
all cases.
Possible cases:
  1) Administrator "knows" and manually issues a hot-plug command. 
  2) A daemon detects a SAF-TE or SES event by slot number.  
     Not sure if we can really determine what we need from just a slot
number?
  3) Other external disk enclosure (JBOD) that doesn't expose a 
     SAF-TE or SES interface.
     This case is out in the cold without the kernel-level rescan.

I'm disregarding case (1), since my target customer environment won't
tolerate the manual step.

Andy

-----Original Message-----
From: James Bottomley [mailto:James.Bottomley@steeleye.com] 
Sent: Wednesday, October 02, 2002 12:29 PM
To: Cress, Andrew R
Cc: linux-scsi@vger.kernel.org
Subject: Re: [PATCH] 2.4.19 scsi_rescan patch (2nd pass) 

andrew.r.cress@intel.com said:
> I had been trying to do that with a user-level daemon I've written
> (sgraidmon at scsirastools.sf.net), but I can't rescan from user level
> because the new devices aren't attached to any /dev, so the user-level
> can't detect that a new device has been inserted, and it doesn't have
> any way to detect which device it might be.   

Right, that's why the hotplug event has to carry enough information to allow

the script to identify what needs to be scanned (i.e. SCSI hostadapter
number 
and PUN if possible). the scsi add-single-device mechanism can then be used
to 
do the attachment (and scanning).

James

Re: [PATCH] 2.4.19 scsi_rescan patch (2nd pass)

[Doug Ledford]

On Wed, Oct 02, 2002 at 11:34:43AM -0400, James Bottomley wrote:
> andrew.r.cress@intel.com said:
> > Here is a 2nd pass at a patch to do a scsi rescan so that hot-inserted
> > scsi disks can automatically be recognized.  It includes some
> > recommended changes/cleanup from Patrick and Mike. 
> 
> Is there a really good reason we can't use the hotplug infrastructure for this 
> and scan from user level?  I know the 2.4 hotplug is less well developed than 
> 2.5, but I believe it will work well enough for this.
> 
> If you go the hotplug route, all we need is a hook to trigger the SCSI hotplug 
> event.

Well, I hate to say it because I don't want to be mean or anything, but 
this patch is a waste of time.  It only triggers a rescan on a reset, and 
that's not a valid rescan trigger.  Any sane hot plug hardware interface 
will *not* cause a reset when a new drive is plugged in.  The only hot 
plug scenario this will catch is if someone is hot plugging a drive 
directly into a cable and they manage to momentarily unsettle the bus in 
the process.  That isn't really anything we care about.  Furthermore, a 
scan is time intensive because of selection timeout delays on a SCSI bus 
(FC or other methods aren't so bad).  The last thing we want to do is to 
start scanning all the currently empty slots every time a reset occurs.

Nope, sorry, but this patch is a non-starter.  Interesting idea, but not 
suitable for the kernel at all.

In fact, *all* of the hot plug hardware out there has some facility for 
telling a controller exactly where it is (SES boxes can use mjacob's SES 
user space library to tell us about hot inserts, in which case we know the 
exact target id of the device inserted, and we know the host/bus from the 
host/bus that the SES itself is on, so we just scan that target by itself, 
while FC controllers can check the fiber node database and specifically 
add the new device in their tables and therefore they know where in their 
tables the device is located and consequently only need to scan that 
single device, etc).  So we don't need a "rescan the bus" facility, all we 
really need to do is allow the user space SES code to hot add devices 
(which it can actually just by using the /proc/scsi/scsi interface that 
exists, but that proc code should be cleaned up and made less race prone) 
and we then need to export the scanning functions inside scsi_scan.c so 
that low level device drivers can, when notified of a new device on the 
fabric loop for example, have an approved method by which they call into 
the scsi scan code and trigger a scan of a specific target location (or 
conversely they should be able to call in and tell the mid layer that a 
device has disappeared if they so desire).  That's the correct way to 
handle this stuff IMNSHO.

-- 
  Doug Ledford <dledford@redhat.com>     919-754-3700 x44233
         Red Hat, Inc. 
         1801 Varsity Dr.
         Raleigh, NC 27606
  

Re: [PATCH] 2.4.19 scsi_rescan patch (2nd pass)

[Doug Ledford]

On Wed, Oct 02, 2002 at 09:40:06AM -0700, Cress, Andrew R wrote:
> James,
> 
> A user-space hotplug event can't be guaranteed to have enough information in
> all cases.
> Possible cases:
>   1) Administrator "knows" and manually issues a hot-plug command. 
>   2) A daemon detects a SAF-TE or SES event by slot number.  
>      Not sure if we can really determine what we need from just a slot
> number?
>   3) Other external disk enclosure (JBOD) that doesn't expose a 
>      SAF-TE or SES interface.
>      This case is out in the cold without the kernel-level rescan.
> 
> I'm disregarding case (1), since my target customer environment won't
> tolerate the manual step.

You can forget 3 as well.  It's simply not reasonable to tie up a busy bus 
with very long selection timeouts to "poll scan" a bus for new insertions.  
Not gonna happen.  If the JBOD doesn't expose a reasonable interface, then 
hot plug with it isn't supported in linux.  If it exposes something other 
than SAF-TE or SES then the protocol it does support needs to be added to 
the daemon in #2 in order for it to be supported.


-- 
  Doug Ledford <dledford@redhat.com>     919-754-3700 x44233
         Red Hat, Inc. 
         1801 Varsity Dr.
         Raleigh, NC 27606
  

Re: [PATCH] 2.4.19 scsi_rescan patch (2nd pass)

[Patrick Mansfield]

On Wed, Oct 02, 2002 at 12:56:06PM -0400, Doug Ledford wrote:
> On Wed, Oct 02, 2002 at 09:40:06AM -0700, Cress, Andrew R wrote:

> >   3) Other external disk enclosure (JBOD) that doesn't expose a 
> >      SAF-TE or SES interface.
> >      This case is out in the cold without the kernel-level rescan.
> > 
> > I'm disregarding case (1), since my target customer environment won't
> > tolerate the manual step.
> 
> You can forget 3 as well.  It's simply not reasonable to tie up a busy bus 
> with very long selection timeouts to "poll scan" a bus for new insertions.  
> Not gonna happen.  If the JBOD doesn't expose a reasonable interface, then 
> hot plug with it isn't supported in linux.  If it exposes something other 
> than SAF-TE or SES then the protocol it does support needs to be added to 
> the daemon in #2 in order for it to be supported.

For SCSI parallel yes, but for FCP (at least on a switch, I'm not sure about
loop), scanning won't have such a negative affect. With 2.5.x targets can
invoke a device_register and so a hotplug event (FCP adapter driver
changes required), and then the new target could be scanned (somehow via
user space trigger calling scan_scsis for a single host/channel/target id)
without affecting other targets on the switch.

-- Patrick Mansfield

> 
> 
> -- 
>   Doug Ledford <dledford@redhat.com>     919-754-3700 x44233