Re: [PATCH 1/3] libata-scsi: Set CmdQue=1 when NCQ is enabled
Btw I wonder if the CmdQue bit should be statically set to 1 instead.
It is not specified in the SAT standard (as of SAT-4 Rev. 05a) that
the bit should be correlated to ATA NCQ. Neither does the kernel care
about the bit (or the 'queue_type' sysfs file), apparently. However,
it seems that there is still an advantage to have the bit set to 1
even when we, for example, need `libata.force=noncq` for some reason:
https://github.com/YanVugenfirer/kvm-guest-drivers-windows/issues/63#issuecomment-216480833
What do you guys think? Is there any concern (with rigid reasoning)
over setting the bit statically to 1?
On 3 May 2016 at 04:13, wrote:
> From: Tom Yan
>
> https://bugzilla.kernel.org/show_bug.cgi?id=105931
>
> This might look trivial at first sight. However, it can be
> important to have the bit set accordingly when the device/SATL is
> SCSI-passthrough'd to a virtual machine with scsi-block in qemu:
>
> https://github.com/YanVugenfirer/kvm-guest-drivers-windows/issues/63#issuecomment-216199929
> Signed-off-by: Tom Yan
>
> diff --git a/drivers/ata/libata-scsi.c b/drivers/ata/libata-scsi.c
> index 567859c..cd30f11 100644
> --- a/drivers/ata/libata-scsi.c
> +++ b/drivers/ata/libata-scsi.c
> @@ -2007,7 +2007,10 @@ static unsigned int ata_scsiop_inq_std(struct
> ata_scsi_args *args, u8 *rbuf)
> 0,
> 0x5,/* claim SPC-3 version compatibility */
> 2,
> - 95 - 4
> + 95 - 4,
> + 0,
> + 0,
> + 0
> };
>
> VPRINTK("ENTER\n");
> @@ -2024,6 +2027,9 @@ static unsigned int ata_scsiop_inq_std(struct
> ata_scsi_args *args, u8 *rbuf)
> hdr[2] = 0x6; /* ZBC is defined in SPC-4 */
> }
>
> + if (ata_ncq_enabled(args->dev))
> + hdr[7] |= (1 << 1);
> +
> memcpy(rbuf, hdr, sizeof(hdr));
> memcpy(&rbuf[8], "ATA ", 8);
> ata_id_string(args->id, &rbuf[16], ATA_ID_PROD, 16);
> --
> 2.8.2
>
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH net-next 4/5] treewide: replace dev->trans_start update with helper
Replace all trans_start updates with netif_trans_update helper. change was done via spatch: struct net_device *d; @@ - d->trans_start = jiffies + netif_trans_update(d) Compile tested only. Cc: user-mode-linux-de...@lists.sourceforge.net Cc: linux-xte...@linux-xtensa.org Cc: linux1394-de...@lists.sourceforge.net Cc: linux-r...@vger.kernel.org Cc: net...@vger.kernel.org Cc: mpt-fusionlinux@broadcom.com Cc: linux-scsi@vger.kernel.org Cc: linux-...@vger.kernel.org Cc: linux-par...@vger.kernel.org Cc: linux-o...@vger.kernel.org Cc: linux-h...@vger.kernel.org Cc: linux-...@vger.kernel.org Cc: linux-wirel...@vger.kernel.org Cc: linux-s...@vger.kernel.org Cc: de...@driverdev.osuosl.org Cc: b.a.t.m@lists.open-mesh.org Cc: linux-blueto...@vger.kernel.org Signed-off-by: Florian Westphal --- Checkpatch complains about whitespace damage, but this extra whitespace already exists before this patch. arch/um/drivers/net_kern.c | 4 ++-- arch/xtensa/platforms/iss/network.c| 2 +- drivers/char/pcmcia/synclink_cs.c | 4 ++-- drivers/firewire/net.c | 2 +- drivers/infiniband/hw/nes/nes_nic.c| 2 +- drivers/infiniband/ulp/ipoib/ipoib_cm.c| 2 +- drivers/infiniband/ulp/ipoib/ipoib_ib.c| 2 +- drivers/isdn/hysdn/hysdn_net.c | 2 +- drivers/isdn/i4l/isdn_net.c| 4 ++-- drivers/isdn/i4l/isdn_x25iface.c | 2 +- drivers/message/fusion/mptlan.c| 2 +- drivers/net/appletalk/cops.c | 2 +- drivers/net/can/mscan/mscan.c | 4 ++-- drivers/net/can/usb/ems_usb.c | 4 ++-- drivers/net/can/usb/esd_usb2.c | 4 ++-- drivers/net/can/usb/peak_usb/pcan_usb_core.c | 4 ++-- drivers/net/cris/eth_v10.c | 2 +- drivers/net/ethernet/3com/3c509.c | 2 +- drivers/net/ethernet/3com/3c515.c | 2 +- drivers/net/ethernet/3com/3c574_cs.c | 2 +- drivers/net/ethernet/3com/3c589_cs.c | 2 +- drivers/net/ethernet/3com/3c59x.c | 2 +- drivers/net/ethernet/8390/axnet_cs.c | 6 +++--- drivers/net/ethernet/8390/lib8390.c| 4 ++-- drivers/net/ethernet/adaptec/starfire.c| 2 +- drivers/net/ethernet/adi/bfin_mac.c| 2 +- drivers/net/ethernet/agere/et131x.c| 4 ++-- drivers/net/ethernet/allwinner/sun4i-emac.c| 6 +++--- drivers/net/ethernet/amd/7990.c| 4 ++-- drivers/net/ethernet/amd/a2065.c | 2 +- drivers/net/ethernet/amd/atarilance.c | 2 +- drivers/net/ethernet/amd/au1000_eth.c | 2 +- drivers/net/ethernet/amd/declance.c| 2 +- drivers/net/ethernet/amd/lance.c | 2 +- drivers/net/ethernet/amd/ni65.c| 4 ++-- drivers/net/ethernet/amd/nmclan_cs.c | 2 +- drivers/net/ethernet/amd/pcnet32.c | 4 ++-- drivers/net/ethernet/amd/sunlance.c| 2 +- drivers/net/ethernet/atheros/alx/main.c| 2 +- drivers/net/ethernet/broadcom/bcmsysport.c | 2 +- drivers/net/ethernet/broadcom/genet/bcmgenet.c | 2 +- drivers/net/ethernet/broadcom/sb1250-mac.c | 2 +- drivers/net/ethernet/broadcom/tg3.c| 2 +- drivers/net/ethernet/cavium/liquidio/lio_main.c| 4 ++-- drivers/net/ethernet/cavium/octeon/octeon_mgmt.c | 2 +- drivers/net/ethernet/cavium/thunder/nicvf_main.c | 2 +- drivers/net/ethernet/chelsio/cxgb4vf/sge.c | 2 +- drivers/net/ethernet/davicom/dm9000.c | 4 ++-- drivers/net/ethernet/dec/tulip/de4x5.c | 4 ++-- drivers/net/ethernet/dec/tulip/dmfe.c | 6 +++--- drivers/net/ethernet/dec/tulip/pnic.c | 6 +++--- drivers/net/ethernet/dec/tulip/tulip_core.c| 2 +- drivers/net/ethernet/dec/tulip/uli526x.c | 4 ++-- drivers/net/ethernet/dec/tulip/winbond-840.c | 2 +- drivers/net/ethernet/dlink/dl2k.c | 2 +- drivers/net/ethernet/dlink/sundance.c | 2 +- drivers/net/ethernet/fealnx.c | 2 +- drivers/net/ethernet/freescale/gianfar.c | 2 +- drivers/net/ethernet/fujitsu/fmvj18x_cs.c | 2 +- drivers/net/ethernet/hisilicon/hix5hd2_gmac.c | 2 +- drivers/net/ethernet/hisilicon/hns/hns_enet.c | 6 +++--- drivers/net/ethernet/hp/hp100.c| 2 +- drivers/net/ethernet/i825xx/82596.c| 2 +- drivers/net/ethernet/i825xx/lib82596.c | 2 +- dr
[PATCH 0/1] cxlflash: Fix in EEH recovery
This patch addresses a deadlock issue seen during EEH recovery and is intended for 4.7. Manoj N. Kumar (1): cxlflash: Fix to resolve dead-lock during EEH recovery drivers/scsi/cxlflash/superpipe.c | 15 +++ 1 file changed, 15 insertions(+) -- 2.1.0 -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/1] cxlflash: Fix to resolve dead-lock during EEH recovery
From: "Manoj N. Kumar"
When a cxlflash adapter goes into EEH recovery and multiple processes
(each having established its own context) are active, the EEH recovery
can hang if the processes attempt to recover in parallel. The symptom
logged after a couple of minutes is:
INFO: task eehd:48 blocked for more than 120 seconds.
Not tainted 4.5.0-491-26f710d+ #1
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
eehd048 2
Call Trace:
__switch_to+0x2f0/0x410
__schedule+0x300/0x980
schedule+0x48/0xc0
rwsem_down_write_failed+0x294/0x410
down_write+0x88/0xb0
cxlflash_pci_error_detected+0x100/0x1c0 [cxlflash]
cxl_vphb_error_detected+0x88/0x110 [cxl]
cxl_pci_error_detected+0xb0/0x1d0 [cxl]
eeh_report_error+0xbc/0x130
eeh_pe_dev_traverse+0x94/0x160
eeh_handle_normal_event+0x17c/0x450
eeh_handle_event+0x184/0x370
eeh_event_handler+0x1c8/0x1d0
kthread+0x110/0x130
ret_from_kernel_thread+0x5c/0xa4
INFO: task blockio:33215 blocked for more than 120 seconds.
Not tainted 4.5.0-491-26f710d+ #1
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
blockio 0 33215 33213
Call Trace:
0x1 (unreliable)
__switch_to+0x2f0/0x410
__schedule+0x300/0x980
schedule+0x48/0xc0
rwsem_down_read_failed+0x124/0x1d0
down_read+0x68/0x80
cxlflash_ioctl+0x70/0x6f0 [cxlflash]
scsi_ioctl+0x3b0/0x4c0
sg_ioctl+0x960/0x1010
do_vfs_ioctl+0xd8/0x8c0
SyS_ioctl+0xd4/0xf0
system_call+0x38/0xb4
INFO: task eehd:48 blocked for more than 120 seconds.
The hang is because of a 3 way dead-lock:
Process A holds the recovery mutex, and waits for eehd to complete.
Process B holds the semaphore and waits for the recovery mutex.
eehd waits for semaphore.
The fix is to have Process B above release the semaphore before
attempting to acquire the recovery mutex. This will allow
eehd to proceed to completion.
Signed-off-by: Manoj N. Kumar
---
drivers/scsi/cxlflash/superpipe.c | 15 +++
1 file changed, 15 insertions(+)
diff --git a/drivers/scsi/cxlflash/superpipe.c
b/drivers/scsi/cxlflash/superpipe.c
index d8a5cb3..ce15070 100644
--- a/drivers/scsi/cxlflash/superpipe.c
+++ b/drivers/scsi/cxlflash/superpipe.c
@@ -1615,6 +1615,13 @@ err1:
* place at the same time and the failure was due to CXL services being
* unable to keep up.
*
+ * As this routine is called on ioctl context, it holds the ioctl r/w
+ * semaphore that is used to drain ioctls in recovery scenarios. The
+ * implementation to achieve the pacing described above (a local mutex)
+ * requires that the ioctl r/w semaphore be dropped and reacquired to
+ * avoid a 3-way deadlock when multiple process recoveries operate in
+ * parallel.
+ *
* Because a user can detect an error condition before the kernel, it is
* quite possible for this routine to act as the kernel's EEH detection
* source (MMIO read of mbox_r). Because of this, there is a window of
@@ -1642,9 +1649,17 @@ static int cxlflash_afu_recover(struct scsi_device *sdev,
int rc = 0;
atomic_inc(&cfg->recovery_threads);
+ up_read(&cfg->ioctl_rwsem);
rc = mutex_lock_interruptible(mutex);
+ down_read(&cfg->ioctl_rwsem);
if (rc)
goto out;
+ rc = check_state(cfg);
+ if (rc) {
+ dev_err(dev, "%s: Failed state! rc=%d\n", __func__, rc);
+ rc = -ENODEV;
+ goto out;
+ }
dev_dbg(dev, "%s: reason 0x%016llX rctxid=%016llX\n",
__func__, recover->reason, rctxid);
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] megaraid: Downgrade two success messages to info
I actually read the error messages in my logs, and successful
initialization is not an error.
Arguably these log lines could be deleted entirely.
Signed-off-by: Andy Lutomirski
---
drivers/scsi/megaraid/megaraid_sas_base.c | 2 +-
drivers/scsi/megaraid/megaraid_sas_fusion.c | 2 +-
include/uapi/linux/signal.h | 2 +-
tools/testing/selftests/sigaltstack/sas.c | 2 +-
4 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/scsi/megaraid/megaraid_sas_base.c
b/drivers/scsi/megaraid/megaraid_sas_base.c
index e6ebc7ae2df1..d020919e8085 100644
--- a/drivers/scsi/megaraid/megaraid_sas_base.c
+++ b/drivers/scsi/megaraid/megaraid_sas_base.c
@@ -5152,7 +5152,7 @@ static int megasas_init_fw(struct megasas_instance
*instance)
instance->instancet->enable_intr(instance);
- dev_err(&instance->pdev->dev, "INIT adapter done\n");
+ dev_info(&instance->pdev->dev, "INIT adapter done\n");
megasas_setup_jbod_map(instance);
diff --git a/drivers/scsi/megaraid/megaraid_sas_fusion.c
b/drivers/scsi/megaraid/megaraid_sas_fusion.c
index 98a848bdfdc2..9375805670a9 100644
--- a/drivers/scsi/megaraid/megaraid_sas_fusion.c
+++ b/drivers/scsi/megaraid/megaraid_sas_fusion.c
@@ -851,7 +851,7 @@ megasas_ioc_init_fusion(struct megasas_instance *instance)
ret = 1;
goto fail_fw_init;
}
- dev_err(&instance->pdev->dev, "Init cmd success\n");
+ dev_info(&instance->pdev->dev, "Init cmd success\n");
ret = 0;
diff --git a/include/uapi/linux/signal.h b/include/uapi/linux/signal.h
index 738826048af2..cd0804b6bfa2 100644
--- a/include/uapi/linux/signal.h
+++ b/include/uapi/linux/signal.h
@@ -8,7 +8,7 @@
#define SS_DISABLE 2
/* bit-flags */
-#define SS_AUTODISARM (1 << 4)/* disable sas during sighandling */
+#define SS_AUTODISARM (1U << 31) /* disable sas during sighandling */
/* mask for all SS_xxx flags */
#define SS_FLAG_BITS SS_AUTODISARM
diff --git a/tools/testing/selftests/sigaltstack/sas.c
b/tools/testing/selftests/sigaltstack/sas.c
index ec6c99fac303..bbd0f22704b7 100644
--- a/tools/testing/selftests/sigaltstack/sas.c
+++ b/tools/testing/selftests/sigaltstack/sas.c
@@ -169,7 +169,7 @@ int main(void)
stk.ss_flags);
exit(EXIT_FAILURE);
}
- printf("[OK]\tsigaltstack is enabled after signal\n");
+ printf("[OK]\tsigaltstack is still SS_AUTODISARM after signal\n");
printf("[OK]\tTest passed\n");
return 0;
--
2.5.5
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
spolupráce
odpovezte mi na tento e-mail nize na dulezitou transakci. email: fnin...@gmx.com -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] megaraid: Downgrade two success messages to info
On Tue, May 3, 2016 at 10:06 AM, Andy Lutomirski wrote: > I actually read the error messages in my logs, and successful > initialization is not an error. I failed at using git here. v2 coming... -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2] megaraid: Downgrade two success messages to info
I actually read the error messages in my logs, and successful initialization is not an error. Arguably these log lines could be deleted entirely. Signed-off-by: Andy Lutomirski --- Changes from v2: Remove hunk that didn't belong drivers/scsi/megaraid/megaraid_sas_base.c | 2 +- drivers/scsi/megaraid/megaraid_sas_fusion.c | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/scsi/megaraid/megaraid_sas_base.c b/drivers/scsi/megaraid/megaraid_sas_base.c index e6ebc7ae2df1..d020919e8085 100644 --- a/drivers/scsi/megaraid/megaraid_sas_base.c +++ b/drivers/scsi/megaraid/megaraid_sas_base.c @@ -5152,7 +5152,7 @@ static int megasas_init_fw(struct megasas_instance *instance) instance->instancet->enable_intr(instance); - dev_err(&instance->pdev->dev, "INIT adapter done\n"); + dev_info(&instance->pdev->dev, "INIT adapter done\n"); megasas_setup_jbod_map(instance); diff --git a/drivers/scsi/megaraid/megaraid_sas_fusion.c b/drivers/scsi/megaraid/megaraid_sas_fusion.c index 98a848bdfdc2..9375805670a9 100644 --- a/drivers/scsi/megaraid/megaraid_sas_fusion.c +++ b/drivers/scsi/megaraid/megaraid_sas_fusion.c @@ -851,7 +851,7 @@ megasas_ioc_init_fusion(struct megasas_instance *instance) ret = 1; goto fail_fw_init; } - dev_err(&instance->pdev->dev, "Init cmd success\n"); + dev_info(&instance->pdev->dev, "Init cmd success\n"); ret = 0; -- 2.5.5 -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] md: raid10: add prerequisite to run underneath dm-raid
From: Heinz Mauelshagen
In case md runs underneath the dm-raid target, the mddev does not have
a request queue or gendisk, thus avoid accesses to it.
This patch adds two missing conditionals to the raid10 personality.
Signed-of-by: Heinz Mauelshagen
---
drivers/md/raid10.c | 12
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/drivers/md/raid10.c b/drivers/md/raid10.c
index e3fd725..84e24e6 100644
--- a/drivers/md/raid10.c
+++ b/drivers/md/raid10.c
@@ -3782,8 +3782,10 @@ static int raid10_resize(struct mddev *mddev, sector_t
sectors)
return ret;
}
md_set_array_sectors(mddev, size);
- set_capacity(mddev->gendisk, mddev->array_sectors);
- revalidate_disk(mddev->gendisk);
+ if (mddev->queue) {
+ set_capacity(mddev->gendisk, mddev->array_sectors);
+ revalidate_disk(mddev->gendisk);
+ }
if (sectors > mddev->dev_sectors &&
mddev->recovery_cp > oldsize) {
mddev->recovery_cp = oldsize;
@@ -4593,8 +4595,10 @@ static void raid10_finish_reshape(struct mddev *mddev)
set_bit(MD_RECOVERY_NEEDED, &mddev->recovery);
}
mddev->resync_max_sectors = size;
- set_capacity(mddev->gendisk, mddev->array_sectors);
- revalidate_disk(mddev->gendisk);
+ if (mddev->queue) {
+ set_capacity(mddev->gendisk, mddev->array_sectors);
+ revalidate_disk(mddev->gendisk);
+ }
} else {
int d;
for (d = conf->geo.raid_disks ;
--
2.5.5
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [dm-devel] [Lsf] Notes from the four separate IO track sessions at LSF/MM
- Original Message - From: "Bart Van Assche" To: "Laurence Oberman" Cc: "James Bottomley" , "linux-scsi" , "Mike Snitzer" , linux-bl...@vger.kernel.org, "device-mapper development" , l...@lists.linux-foundation.org Sent: Monday, May 2, 2016 6:28:16 PM Subject: Re: [dm-devel] [Lsf] Notes from the four separate IO track sessions at LSF/MM On 05/02/2016 12:28 PM, Laurence Oberman wrote: > Even in the case of the ib_srp, don't we also have to still run the > eh_timeout for each of the devices that has inflight requiring error > handling serially. This means we will still have to wait to get a > path failover until all are through the timeout. Hello Laurence, It depends. If a transport layer error (e.g. a cable pull) has been observed by the ib_srp driver then fast_io_fail_tmo seconds later the ib_srp driver will terminate all outstanding SCSI commands without waiting for the error handler to finish. If no transport layer error has been observed then at most (SCSI timeout) + (number of pending commands + 1) * 5 seconds later srp_reset_device() will have finished terminating all pending SCSI commands. Bart. -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Hello Bart OK, Yes, that lines up with my testing here with Qlogic and Emulex. I am about to test srp but I need to add some jammer code first. The link down and other interruptions will always be fast. Its always going to be the black-hole events that are troublesome. Thanks Laurence -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] md: raid10: add prerequisite to run underneath dm-raid
On Tue, 2016-05-03 at 19:42 +0200, hei...@redhat.com wrote:
> From: Heinz Mauelshagen
>
> In case md runs underneath the dm-raid target, the mddev does not
> have a request queue or gendisk, thus avoid accesses to it.
>
> This patch adds two missing conditionals to the raid10 personality.
-EWRONGLIST. drivers/md is handled by linux-r...@vger.kernel.org
James
>
> Signed-of-by: Heinz Mauelshagen
>
> ---
> drivers/md/raid10.c | 12
> 1 file changed, 8 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/md/raid10.c b/drivers/md/raid10.c
> index e3fd725..84e24e6 100644
> --- a/drivers/md/raid10.c
> +++ b/drivers/md/raid10.c
> @@ -3782,8 +3782,10 @@ static int raid10_resize(struct mddev *mddev,
> sector_t sectors)
> return ret;
> }
> md_set_array_sectors(mddev, size);
> - set_capacity(mddev->gendisk, mddev->array_sectors);
> - revalidate_disk(mddev->gendisk);
> + if (mddev->queue) {
> + set_capacity(mddev->gendisk, mddev->array_sectors);
> + revalidate_disk(mddev->gendisk);
> + }
> if (sectors > mddev->dev_sectors &&
> mddev->recovery_cp > oldsize) {
> mddev->recovery_cp = oldsize;
> @@ -4593,8 +4595,10 @@ static void raid10_finish_reshape(struct mddev
> *mddev)
> set_bit(MD_RECOVERY_NEEDED, &mddev
> ->recovery);
> }
> mddev->resync_max_sectors = size;
> - set_capacity(mddev->gendisk, mddev->array_sectors);
> - revalidate_disk(mddev->gendisk);
> + if (mddev->queue) {
> + set_capacity(mddev->gendisk, mddev
> ->array_sectors);
> + revalidate_disk(mddev->gendisk);
> + }
> } else {
> int d;
> for (d = conf->geo.raid_disks ;
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] md: raid10: add prerequisite to run underneath dm-raid
On 05/03/2016 07:51 PM, James Bottomley wrote:
On Tue, 2016-05-03 at 19:42 +0200, hei...@redhat.com wrote:
From: Heinz Mauelshagen
In case md runs underneath the dm-raid target, the mddev does not
have a request queue or gendisk, thus avoid accesses to it.
This patch adds two missing conditionals to the raid10 personality.
-EWRONGLIST. drivers/md is handled by linux-r...@vger.kernel.org
Sorry for the noise...
James
Signed-of-by: Heinz Mauelshagen
---
drivers/md/raid10.c | 12
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/drivers/md/raid10.c b/drivers/md/raid10.c
index e3fd725..84e24e6 100644
--- a/drivers/md/raid10.c
+++ b/drivers/md/raid10.c
@@ -3782,8 +3782,10 @@ static int raid10_resize(struct mddev *mddev,
sector_t sectors)
return ret;
}
md_set_array_sectors(mddev, size);
- set_capacity(mddev->gendisk, mddev->array_sectors);
- revalidate_disk(mddev->gendisk);
+ if (mddev->queue) {
+ set_capacity(mddev->gendisk, mddev->array_sectors);
+ revalidate_disk(mddev->gendisk);
+ }
if (sectors > mddev->dev_sectors &&
mddev->recovery_cp > oldsize) {
mddev->recovery_cp = oldsize;
@@ -4593,8 +4595,10 @@ static void raid10_finish_reshape(struct mddev
*mddev)
set_bit(MD_RECOVERY_NEEDED, &mddev
->recovery);
}
mddev->resync_max_sectors = size;
- set_capacity(mddev->gendisk, mddev->array_sectors);
- revalidate_disk(mddev->gendisk);
+ if (mddev->queue) {
+ set_capacity(mddev->gendisk, mddev
->array_sectors);
+ revalidate_disk(mddev->gendisk);
+ }
} else {
int d;
for (d = conf->geo.raid_disks ;
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] [REGRESSION] md: md.c: fix oops in mddev_suspend for raid0
From: Heinz Mauelshagen
Introduced by upstream commit 70d9798b95562abac005d4ba71d28820f9a201eb
The raid0 personality does not create mddev->thread as oposed to
other personalities leading to its unconditional access in
mddev_suspend() causing an oops.
Patch checks for mddev->thread in order to keep the
intention of aforementioned commit.
Signed-off-by: Heinz Mauelshagen
---
drivers/md/md.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/md/md.c b/drivers/md/md.c
index 194580f..d91920d 100644
--- a/drivers/md/md.c
+++ b/drivers/md/md.c
@@ -305,7 +305,7 @@ static blk_qc_t md_make_request(struct request_queue *q,
struct bio *bio)
*/
void mddev_suspend(struct mddev *mddev)
{
- WARN_ON_ONCE(current == mddev->thread->tsk);
+ WARN_ON_ONCE(mddev->thread && current == mddev->thread->tsk);
if (mddev->suspended++)
return;
synchronize_rcu();
--
2.5.5
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/3] libata-scsi: Fix SCSI INQUIRY version descriptor
On 2016-05-02 04:13 PM, tom.t...@gmail.com wrote:
From: Tom Yan
https://bugzilla.kernel.org/show_bug.cgi?id=106931
Signed-off-by: Tom Yan
diff --git a/drivers/ata/libata-scsi.c b/drivers/ata/libata-scsi.c
index cd30f11..0295c38 100644
--- a/drivers/ata/libata-scsi.c
+++ b/drivers/ata/libata-scsi.c
@@ -1985,8 +1985,8 @@ static unsigned int ata_scsiop_inq_std(struct
ata_scsi_args *args, u8 *rbuf)
0x03,
0x20, /* SBC-2 (no version claimed) */
- 0x02,
- 0x60/* SPC-3 (no version claimed) */
+ 0x03,
+ 0x00/* SPC-3 (no version claimed) */
};
const u8 versions_zbc[] = {
0x00,
SPC-3 was standardized in 2005 (ANSI INCITS 408-2005) and there
is a more recent standard: SPC-4 (ANSI INCITS 513-2015). And
my guess is that libata-scsi supports many things introduced
in SPC-4 . If you switch to SPC-4 then the "version" field in
the standard INQUIRY response (byte 2) should be changed to 6.
Also SBC-2 is old (ANSI INCITS 405-2005) and should be updated
to SBC-3 (ANSI INCITS 514-2014). Again many features supported
by libata-scsi didn't exist in SBC-2.
And libata-scsi is a SCSI to ATA Translation (SAT) layer and
there are standards for that, take your pick: SAT (ANSI INCITS
431-2007), SAT-2 (ANSI INCITS 465-2010) or SAT-3 (ANSI INCITS
517-2015).
Suggestion:
Version descriptors value
SAM-5 (no version claimed)0x00a0
SPC-4 (no version claimed)0x0460
SBC-3 (no version claimed)0x04c0
SAT-3 (no version claimed)0x1ee0
Plus byte 2 of INQUIRY response: 0x6
Doug Gilbert
BTW in lk 4.6.0-rc5 I see this for a directly connected SATA SSD:
# sg_inq -d /dev/sg0
standard INQUIRY:
PQual=0 Device_type=0 RMB=0 LU_CONG=0 version=0x05 [SPC-3]
[AERC=0] [TrmTsk=0] NormACA=0 HiSUP=0 Resp_data_format=2
SCCS=0 ACC=0 TPGS=0 3PC=0 Protect=0 [BQue=0]
EncServ=0 MultiP=0 [MChngr=0] [ACKREQQ=0] Addr16=0
[RelAdr=0] WBus16=0 Sync=0 [Linked=0] [TranDis=0] CmdQue=0
[SPI: Clocking=0x0 QAS=0 IUS=0]
length=96 (0x60) Peripheral device type: disk
Vendor identification: ATA
Product identification: INTEL SSDSC2BW18
Product revision level: DC32
Unit serial number:
Version descriptors:
SAM-3 (no version claimed)
SBC-2 (no version claimed)
SPC-2 (no version claimed)
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/42] v7: separate operations from flags in the bio/request structs
mchri...@redhat.com writes: > The following patches begin to cleanup the request->cmd_flags and > bio->bi_rw mess. We currently use cmd_flags to specify the operation, > attributes and state of the request. For bi_rw we use it for similar > info and also the priority but then also have another bi_flags field > for state. At some point, we abused them so much we just made cmd_flags > 64 bits, so we could add more. > > The following patches seperate the operation (read, write discard, > flush, etc) from cmd_flags/bi_rw. > > This patchset was made against linux-next from today April 15 > (git tag next-20160415). > > I put a git tree here: > https://github.com/mikechristie/linux-kernel.git > The patches are in the op branch. Hi, Mike, That git tree doesn't seem to exist. I did manage to apply your patch set on top of next-20160415, though. So... what testing did you do? ;-) I ran into the following problems: - git clone fails - yum segfaults - many blktrace/blkparse issues, including incorrect cpu recorded in traces, null task names, and blkparse outputting nothing for a trace file several gigabytes in size. After that, I decided to back out your patches and test the base linux-next kernel. That kernel has none of those issues. So, either I'm missing some dependencies, or I think we've got some issues to iron out before this thing goes in. Before I dig any further, am I missing something? Cheers, Jeff -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2.5 1/6] scsi_debug: use pdt constants
On 04/30/2016 07:44 PM, Douglas Gilbert wrote: Use TYPE_* constants for SCSI peripheral device types instead of numbers. Further cleanups requested by checkpatch.pl . Signed-off-by: Douglas Gilbert Reviewed-by: Bart Van Assche -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2.5 2/6] scsi_debug: rework resp_report_luns
On 04/30/2016 07:44 PM, Douglas Gilbert wrote: Based on "[PATH V2] scsi_debug: rework resp_report_luns" patch sent by Tomas Winkler on Thursday, 26 Feb 2015. His notes: 1. Remove duplicated boundary checks which simplify the fill-in loop 2. Use more of scsi generic API Replace fixed length response array a with heap allocation allowing up to 256 normal LUNs per target. Signed-off-by: Douglas Gilbert Reviewed-by: Bart Van Assche -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
re: aha1542: Stop using scsi_module.c
Hello Ondrej Zary,
The patch 643a7c43f11e: "aha1542: Stop using scsi_module.c" from Feb
6, 2015, leads to the following static checker warning:
drivers/scsi/aha1542.c:703 aha1542_hw_init()
error: buffer overflow 'io' 4 <= 4
drivers/scsi/aha1542.c
995 static int aha1542_pnp_probe(struct pnp_dev *pdev, const struct
pnp_device_id *id)
996 {
997 int indx;
998 struct Scsi_Host *sh;
999
1000 for (indx = 0; indx < ARRAY_SIZE(io); indx++) {
^
Let's assume we exit the loop with indx == ARRAY_SIZE(io). Actually,
that's the only way we can exit the loop.
1001 if (io[indx])
1002 continue;
1003
1004 if (pnp_activate_dev(pdev) < 0)
1005 continue;
1006
1007 io[indx] = pnp_port_start(pdev, 0);
1008
1009 /* The card can be queried for its DMA, we have
1010 the DMA set up that is enough */
1011
1012 dev_info(&pdev->dev, "ISAPnP found an AHA1535 at I/O
0x%03X", io[indx]);
1013 }
1014
1015 sh = aha1542_hw_init(&driver_template, &pdev->dev, indx);
Then this is beyond the end of the array. I'm not sure what was
intended.
1016 if (!sh)
1017 return -ENODEV;
1018
1019 pnp_set_drvdata(pdev, sh);
1020 return 0;
1021 }
regards,
dan carpenter
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[patch] [SCSI] eata_pio: missing break statement
This missing break statement bug predates git. It's a very minor thing, it means that we print a '?' instead of a 'z' in dmesg. Signed-off-by: Dan Carpenter diff --git a/drivers/scsi/eata_pio.c b/drivers/scsi/eata_pio.c index ca8003f..4299fa4 100644 --- a/drivers/scsi/eata_pio.c +++ b/drivers/scsi/eata_pio.c @@ -729,6 +729,7 @@ static int register_pio_HBA(long base, struct get_conf *gc, struct pci_dev *pdev break; case 0x24: SD(sh)->EATA_revision = 'z'; + break; default: SD(sh)->EATA_revision = '?'; } -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] megaraid: Downgrade two success messages to info
On 05/03/2016 07:24 PM, Andy Lutomirski wrote: > I actually read the error messages in my logs, and successful > initialization is not an error. > > Arguably these log lines could be deleted entirely. > > Signed-off-by: Andy Lutomirski > --- > > Changes from v2: Remove hunk that didn't belong > Reviewed-by: Hannes Reinecke Cheers, Hannes -- Dr. Hannes ReineckeTeamlead Storage & Networking h...@suse.de +49 911 74053 688 SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: F. Imendörffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton HRB 21284 (AG Nürnberg) -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Regression in v4.6-rc due to SCSI multipath change
Current upstream kernels fail to boot on my POWER8 server with
multipath SCSI disks and IPR host bus adapters. What happens is that
the system finds each disk twice (as normal) and then prints messages
like this:
[2.827761] sd 1:2:4:0: alua: supports implicit TPGS
[2.827875] sd 1:2:4:0: alua: No device descriptors found
[2.827923] sd 1:2:4:0: alua: Attach failed (-22)
[2.827979] device-mapper: table: 253:0: multipath: error attaching hardware
handler
[2.828048] device-mapper: ioctl: error adding target to table
Eventually dracut times out (this is with Fedora 23) enters emergency
mode.
I bisected the problem down to commit 0047220c6c36 ("scsi_dh_alua: use
unique device id", 2016-02-19). It seems that this commit adds the
restriction that we can only do multipath with disks that have stuff
in their VPD page 83 that scsi_vpd_lun_id() can parse. The disks on
my server apparently don't.
I instrumented scsi_vpd_lun_id() to find out what was going on. The
disks on this machine have a vendor-specific designator and a T10
vendor ID based designator, but no designators of types 2, 3 or 8.
An example from one disk is:
02 01 00 20 49 42 4d 20 20 20 20 20 49 50 52 2d 30 20 20 20 35 45 43
34 41 42 30 30 30 30 30 30 30 30 32 30
02 00 00 14 30 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20
I have a patch that extends scsi_vpd_lun_id() to be able to use the
T10 vendor ID based designator, which fixes the problem on my system.
I'll post the patch shortly.
However, was it really intentional that multipath now can't be used
with disks like these, when it worked just fine previously?
Paul.
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
