On 10/18/2016, 09:27 AM, Juerg Haefliger wrote:
> From: Don Brace <don.brace@xxxxxxxxxxxxx>
>
> commit 64ce60cab24603ac0fcd59c9fbc3be78f4c4d229 upstream.
>
> The SA controller spins down RAID drive spares.
>
> A REGNEWD event causes an inquiry to be sent to all physical
> drives. This causes the SA controller to spin up the spare.
>
> The controller suspends all I/O to a logical volume until
> the spare is spun up. The spin-up can take over 50 seconds.
>
> This can result in one or both of the following:
> - SML sends down aborts and resets to the logical volume
> and can cause the logical volume to be off-lined.
> - a negative impact on the logical volume's I/O performance
> each time a REGNEWD is triggered.
...
> --- a/drivers/scsi/hpsa.c
> +++ b/drivers/scsi/hpsa.c
> @@ -3930,6 +3930,70 @@ static int hpsa_set_local_logical_count(struct ctlr_info *h,
...
> +static bool hpsa_skip_device(struct ctlr_info *h, u8 *lunaddrbytes,
> + struct ext_report_lun_entry *rle)
> +{
> + u8 device_flags;
> + u8 device_type;
> +
> + if (!MASKED_DEVICE(lunaddrbytes))
> + return false;
> +
> + device_flags = rle->device_flags;
> + device_type = rle->device_type;
> +
> + if (device_flags & RPL_DEV_FLAG_NON_DISK) {
> + if (device_type == BMIC_DEVICE_TYPE_ENCLOSURE)
> + return false;
Is this correct in 4.4 indeed, given we do not test 6 (TYPE_ENCLOSURE)
in the code below?
> @@ -4030,10 +4095,15 @@ static void hpsa_update_scsi_devices(struct ctlr_info *h)
> lunaddrbytes = figure_lunaddrbytes(h, raid_ctlr_position,
> i, nphysicals, nlogicals, physdev_list, logdev_list);
>
> - /* skip masked non-disk devices */
> - if (MASKED_DEVICE(lunaddrbytes) && physical_device &&
> - (physdev_list->LUN[phys_dev_index].device_flags & 0x01))
> - continue;
That was added only later (4.5) by:
commit cca8f13b4fdaf3583e103ae7f96fda948839b265
Author: Don Brace <don.brace@xxxxxxxx>
Date: Tue Dec 22 10:36:48 2015 -0600
hpsa: Add box and bay information for enclosure devices
thanks,
--
js
suse labs
--
To unsubscribe from this list: send the line "unsubscribe stable" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html