| Message ID | 1247191145.28322.10.camel@chandra-ubuntu (mailing list archive) |
|---|---|
| State | Not Applicable, archived |
| Headers | show |
I had taken the patches you sent earlier and tried them on the SLES 11. There were a couple of collisions but not much. I am able to set the parameters in hardware handler with the patches. This also now allows multipath to handle path failures correctly where reservations are involved, aka honor reservations set on trespass command. I will do more testing but so far so good. I made one type cast change in scsi_dh_emc.c to avoid a warning char *p = (char *)params; I will look at your patches to make sure I reconciled the conflicts correctly. Eddie On Thu, 2009-07-09 at 18:59 -0700, Chandra Seetharaman wrote: > Eddie, > > Here is the set of patches ported to sles11. > > It applies cleanly on linux-2.6.27.23-0.1 > > Anyways, you have to test the mainline version for it to be pushed > upstream. (this patch is just for verification purposes). > > series: > sles11_scsi_dh_params > sles11_emc_parameters > sles11_parameters_fix_for_dmmpath > > chandra > On Thu, 2009-07-09 at 17:16 -0400, Eddie Williams wrote: > > I have not tried to patch the 2.6.27-23 kernel. Given that the patches > > were against 31-RC1 I assumed that there would be other changes I would > > need to pull in. I have been looking at why the 31-RC1 was panicing as > > well as working with my EMC contacts to see if they already had a > > working 31-RC1 environment they could verify the patch in. > > Unfortunately I have been mostly in meetings... > > > > I will give it a try. I should have results in the morning. > > > > Eddie > > > > On Thu, 2009-07-09 at 12:55 -0700, Chandra Seetharaman wrote: > > > Did you try to port/apply my patches to the SLES11 tree and see if it > > > works ? > > > > > > On Tue, 2009-07-07 at 08:34 -0400, Eddie Williams wrote: > > > > I was testing with the SLES 11 kernel. Initially I was using > > > > 2.6.27.19-5 and also verified the same issue with their errata kernel > > > > 2.6.27.23-0.1. > > > > > > > > Eddie > > > > On Thu, 2009-07-02 at 13:47 -0700, Chandra Seetharaman wrote: > > > > > On Thu, 2009-07-02 at 16:29 -0400, Eddie Williams wrote: > > > > > > On Thu, 2009-07-02 at 15:34 -0400, Eddie Williams wrote: > > > > > > > I have tried to set this up but have run into a problem probably due to > > > > > > > my error. It has been a while since I have had to build kernels... > > > > > > > > > > > > > > I pulled 2.6.31-rc1, applied the two patches below and then applied the > > > > > > > 3 patches for the interface. The new kernel loads fine but when a > > > > > > > trespass command is sent I get an panic. I am looking though how I > > > > > > > built the kernel and perhaps build with your 3 patches to see if it > > > > > > > happened before. > > > > > > > > > > > > I backed out the 3 patches with the same panic. > > > > > > > > > > > Which version of the kernel were you originally testing with ? (when you > > > > > found the feature was gone). > > > > > > > > > > > > > -- > > > > 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 > > > > > > > -- > > dm-devel mailing list > > dm-devel@redhat.com > > https://www.redhat.com/mailman/listinfo/dm-devel -- dm-devel mailing list dm-devel@redhat.com https://www.redhat.com/mailman/listinfo/dm-devel
Index: linux/drivers/scsi/device_handler/scsi_dh_emc.c =================================================================== --- linux.orig/drivers/scsi/device_handler/scsi_dh_emc.c +++ linux/drivers/scsi/device_handler/scsi_dh_emc.c @@ -563,6 +563,61 @@ done: return result; } +/* + * params - parameters in the following format + * "no_of_params\0param1\0param2\0param3\0...\0" + * for example, string for 2 parameters with value 10 and 21 + * is specified as "2\010\021\0". + */ +static int clariion_set_params(struct scsi_device *sdev, const char *params) +{ + struct clariion_dh_data *csdev = get_clariion_data(sdev); + unsigned int hr = 0, st = 0, argc; + char *p = params; + int result = SCSI_DH_OK; + + if ((sscanf(params, "%u", &argc) != 1) || (argc != 2)) + return -EINVAL; + + while (*p++) + ; + if ((sscanf(p, "%u", &st) != 1) || (st > 1)) + return -EINVAL; + + while (*p++) + ; + if ((sscanf(p, "%u", &hr) != 1) || (hr > 1)) + return -EINVAL; + + if (st) + csdev->flags |= CLARIION_SHORT_TRESPASS; + else + csdev->flags &= ~CLARIION_SHORT_TRESPASS; + + if (hr) + csdev->flags |= CLARIION_HONOR_RESERVATIONS; + else + csdev->flags &= ~CLARIION_HONOR_RESERVATIONS; + + /* + * If this path is owned, we have to send a trespass command + * with the new parameters. If not, simply return. Next trespass + * command would use the parameters. + */ + if (csdev->lun_state != CLARIION_LUN_OWNED) + goto done; + + csdev->lun_state = CLARIION_LUN_UNINITIALIZED; + result = send_trespass_cmd(sdev, csdev); + if (result != SCSI_DH_OK) + goto done; + + /* Update status */ + result = clariion_send_inquiry(sdev, csdev); + +done: + return result; +} static const struct scsi_dh_devlist clariion_dev_list[] = { {"DGC", "RAID", 0}, @@ -583,6 +638,7 @@ static struct scsi_device_handler clarii .check_sense = clariion_check_sense, .activate = clariion_activate, .prep_fn = clariion_prep_fn, + .set_params = clariion_set_params, }; /*