Re: [PATCH 0/4] Drivers: scsi: storvsc: Fix miscellaneous issues
On Mon, Dec 29, 2014 at 09:07:59PM +, KY Srinivasan wrote: Should I be resending these patches. I don't need a resend, I need a review for the patches. Note that for driver patches I'm also fine with a review from a co worker, as long as it's a real review not just a rubber stamp. Talking about process: for the next submission please only use storvsc: as the subject prefix, I had to remove Drivers: scsi: which doesn'd add useful information every time so far. -- 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: [scsi/net-next]Pull csiostor from net-next
On Sun, Dec 28, 2014 at 03:13:14PM +, Praveen Madhavan wrote: How much do you plan to send for the 3.20 window? I'd rather avoid having to pull in the net-next tree and merge everything through Dave if that seems feasible. I hv couple of patches fixes for 3.20 window. Can you please pull from linux-next tree ? If it's really just a few fixes I'd prefer to just ACK them on the scsi list and send them through the net tree to avoid a cross dependency. -- 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: Issues with commit 34b48db6 (block: remove artifical max_hw_sectors cap)
On Sun, Dec 28, 2014 at 10:10:01PM -0500, Alan Stern wrote: (Is this a USB device? Presumably you wouldn't have CC'ed the linux-usb and usb-storage mailing lists if it wasn't...) It's a usb attached device. From the inquity information and the product name it looks like a SATA device attached via a usb bridge. The only limits usb-storage imposes on max_sectors are those needed to work around bugs in the devices' USB bridges. (Okay, there's also something for tape drive devices, but it probably doesn't belong in usb-storage -- it should be handled by the SCSI tape driver.) If the ATA layer needs to set a limit on max_sectors, why doesn't it simply go ahead and do so? Because the ATA layer doesn't control the device, the bridge does. And it seems like it doesn't communicate the maximum transfer size properly. -- 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: block: remove artifical max_hw_sectors cap
On Sun, Dec 28, 2014 at 01:08:59PM +0100, Stefan Priebe wrote: Nic, can you fix LIO to expose the proper max xfer size? some more problems while running this patch. My crucial m500 and m550 ssds (i have around 60 in 30 different cases and motherboards but all attached as jbods at LSI HBAs) print those errors: What is the max_sectors_kb value for them? -- 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] Initialize off value in asd_process_ctrl_a_user()
On Sun, Dec 28, 2014 at 04:12:16PM +0100, Ben Hutchings wrote: On Tue, 2014-12-02 at 11:34 -0500, Eric B Munson wrote: If the asd_find_flash_de() function returns ENOENT the off value will be used uninitialized in the call to asd_read_flash_seg(). This is just papering over the problem. This was my attempt at a proper fix: http://article.gmane.org/gmane.linux.scsi/91320 That one looks much more useful to me. Can someone give it a second review? -- 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] scsi_scan: Send TEST UNIT READY to LUN0 before LUN scanning
Can you resend a version with the small updates pointed out by James? I'd rather get the full UA handling, but it seems like that will take longer, so I'd rather get something in to get the Fujitsu arrays working ASAP. -- 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: esp_scsi: make number of tags configurable
On Wed, Dec 10, 2014 at 11:16:47AM +0100, Geert Uytterhoeven wrote: --- a/drivers/scsi/esp_scsi.c +++ b/drivers/scsi/esp_scsi.c @@ -2317,6 +2317,10 @@ int scsi_esp_register(struct esp *esp, struct device *dev) static int instance; int err; + if (!esp-num_tags) + esp-num_tags = ESP_DEFAULT_TAGS; + else if (esp-num_tags = ESP_MAX_TAG) drivers/scsi/esp_scsi.c: In function ???scsi_esp_register???: drivers/scsi/esp_scsi.c:2399: warning: comparison is always false due to limited range of data type ESP_MAX_TAG is 256, num_tags is u8. Can you send me a patch to just remove that conditional? -- 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: T10-PI: Getting failed tag info
On Mon, Dec 15, 2014 at 07:45:39PM -0500, Martin K. Petersen wrote: Christoph == Christoph Hellwig h...@infradead.org writes: Christoph I really don't like adding new errno codes for all these. This was mainly done to accommodate Darrick's work on aio extensions. If these errors were forever trapped inside the kernel I would agree with you but the plan is to make this generally applicable. But those extensions require new structures to pass in the PI info anyway.. -- 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 3/4 v3] scsi:stex.c Add reboot support
On Thu, Dec 18, 2014 at 11:41:30AM +0800, Charles Chiou wrote: Sorry, I'm not understand what is meaning of series. Could you specify what you what me to send you? Series means a set of patches, e.g. all the ones you send. Talking about patches series it would be very helpful if you send the actual patches as replies to the [PATCH 0/n] introduction mail. The git-send-email tool is a great way to do this automatically. -- 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 3/4 v3] scsi:stex.c Add reboot support
On Tue, Dec 23, 2014 at 10:58:25AM +0800, Charles Chiou wrote: Hi, after our internal discussion, we can use shutdown flow for reboot temporarily. Some signal issue will happen (depend on MB), and it can be fixed by plug in and plug out manually. We will add reboot feature after PM can pass reboot information to -shutdown. Thanks. Please send the updated patch series to the list. Note that you should also try to pass the information you need through proper channels, e.g. adding an argument to the -shutdown method. Please send this to the linux-pm ad linux-kernel lists. -- 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: Using common code for csiostor.
On Wed, Dec 17, 2014 at 08:10:15AM -0800, James Bottomley wrote: The usual way to do this is to make the common hardware function a base module and make all drivers that use it depend on it. Like iwldvm - iwlwifi - mac80211 etc. We really wouldn't want to do the link and build because that will create two identical binary copies of the interface (one in SCSI and one in net) which is a waste of text space. Agreed. If the amount of shared code is really small a header with inlines might be an alternative as there is some overhead creating a new module. -- 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 RESEND 0/5] Feature enhancements for ses module
This series fails to apply for me, most likely due to whitespace corruption. Can you resend it usign git-send-email, please? Also please replace the SES: prefix with ses:, thanks! -- 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] scsi: arm: cumana_1.c: Remove unused function
This one doesn't apply anymore after the 5380 cleanups. -- 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] drivers: scsi: megaraid: Add megaraid_sas_internal.h for internal shared functions using
On Mon, Dec 15, 2014 at 12:05:22AM +0800, Chen Gang wrote: For shared inline functions crossed source files, better to let it as static inline in a header file. For extern functions, better to declare them in header file. This one doesn't apply. -- 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] SCSI: SD: set max_ws_blocks as max_unmap_blocks if it isn't provided
Thanks, applied to scsi-for-3.19. -- 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 1/1] IOMMU Fault occurs when IO and abort IO is out of order
Thanks, applied to scsi-for-3.19 after fixing up a reject due to the version number update. -- 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] scsi: 3w-9xxx.c: Cleaning up missing null-terminate in conjunction with strncpy
Thanks, applied to scsi-for-3.20. -- 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] constants.c: asc/ascq codes, sync to T10 20141221
Thanks, applied to scsi-for-3.20. -- 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] mpt2sas: issue reset is never uninitialized
Thanks, applied to scsi-for-3.20. -- 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] mpt3sas: issue_reset is uninitialized
Thanks, applied to scsi-for-3.20. -- 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
[ANNOUNCE] scsi patch queue tree updated
It turnd out while the scsi-queue tree in general worked very well the split into core and drivers branches was rather cumbersome. For the 3.19 merge window updates and the 3.20 window I've switched to a single branch instead: git://git.infradead.org/users/hch/scsi-queue.git scsi-for-3.19 git://git.infradead.org/users/hch/scsi-queue.git scsi-for-3.20 So far there 3.20 tree is still rather small, but there are a couple of series that need a resend or review and should go in. The rules from the original scsi-queue tree have worked well, so they still apply with a minor change. These rules are: - the patch needs at least two positive reviews (non-author signoff, reviewed-by or acked-by tags). In practice this means it had at least one and I added another one. As an exception I also take trivial and important fixes if they only have a Tested-by: instead of a second review. - the patch has no negative review on the mailing list - the patch applies cleanly - the patch compiles (drivers for architectures I can't test excluded) - for core the core branch: the patch survives a full xfstests run -- 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/22] mpt2sas, mpt3sas: SAS2 Phase 19,20 and SAS3 Phase 4,5 patches
Sreekanth, can you resend the reviewed patches as a series that applies to the scsi-for-3.20 branch? Thanks, Christoph -- 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: [SCSI RFC] mpt2sas: wait_for_completion_timeout timeout not reported
On 12/29/2014 12:25 PM, Nicholas Mc Guire wrote:
wait_for_completion_timeout reaching timeout was being ignored,
this probably also should fail if timeout condition occurs ?
this was only compile tested with
x86_64_defconfig + CONFIG_SCSI_LOWLEVEL=y + CONFIG_SCSI_MPT2SAS=m
patch is against linux-next 3.19.0-rc1 -next-20141226
Signed-off-by: Nicholas Mc Guire der.h...@hofr.at
---
drivers/scsi/mpt2sas/mpt2sas_config.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/scsi/mpt2sas/mpt2sas_config.c
b/drivers/scsi/mpt2sas/mpt2sas_config.c
index c72a2ff..02dc2d8 100644
--- a/drivers/scsi/mpt2sas/mpt2sas_config.c
+++ b/drivers/scsi/mpt2sas/mpt2sas_config.c
@@ -391,7 +391,7 @@ _config_request(struct MPT2SAS_ADAPTER *ioc,
Mpi2ConfigRequest_t
mpt2sas_base_put_smid_default(ioc, smid);
timeleft = wait_for_completion_timeout(ioc-config_cmds.done,
timeout*HZ);
- if (!(ioc-config_cmds.status MPT2_CMD_COMPLETE)) {
+ if (timeleft == 0 || !(ioc-config_cmds.status MPT2_CMD_COMPLETE)) {
printk(MPT2SAS_ERR_FMT %s: timeout\n,
ioc-name, __func__);
_debug_dump_mf(mpi_request,
Hi Nicholas,
This would look like the correct thing to do here, for it eliminates a
small window where we timeout when mpt2sas_config_done had set
MPT2_CMD_COMPLETE and MPT3_CMD_REPLY_VALID, but has not finished copying
the reply data into config_cmds.reply.
It looks like the same patch should be applied to the mpt3sas driver as
well.
-- Joe
--
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/2] mpt2sas,mpt3sas: correct master-abort checking in doorbell ack
Test against the invalid data pattern ~0 before testing valid data
patterns.
Reported-by: Derek Shute derek.sh...@stratus.com
Signed-off-by: Joe Lawrence joe.lawre...@stratus.com
---
drivers/scsi/mpt2sas/mpt2sas_base.c |7 ---
drivers/scsi/mpt3sas/mpt3sas_base.c |7 ---
2 files changed, 8 insertions(+), 6 deletions(-)
diff --git a/drivers/scsi/mpt2sas/mpt2sas_base.c
b/drivers/scsi/mpt2sas/mpt2sas_base.c
index 3fb01d1883c6..16d6fd5e037e 100644
--- a/drivers/scsi/mpt2sas/mpt2sas_base.c
+++ b/drivers/scsi/mpt2sas/mpt2sas_base.c
@@ -2983,7 +2983,9 @@ _base_wait_for_doorbell_ack(struct MPT2SAS_ADAPTER *ioc,
int timeout,
cntdn = (sleep_flag == CAN_SLEEP) ? 1000*timeout : 2000*timeout;
do {
int_status = readl(ioc-chip-HostInterruptStatus);
- if (!(int_status MPI2_HIS_SYS2IOC_DB_STATUS)) {
+ if (int_status == 0x)
+ goto out;
+ else if (!(int_status MPI2_HIS_SYS2IOC_DB_STATUS)) {
dhsprintk(ioc, printk(MPT2SAS_INFO_FMT %s:
successful count(%d), timeout(%d)\n, ioc-name,
__func__, count, timeout));
@@ -2995,8 +2997,7 @@ _base_wait_for_doorbell_ack(struct MPT2SAS_ADAPTER *ioc,
int timeout,
mpt2sas_base_fault_info(ioc , doorbell);
return -EFAULT;
}
- } else if (int_status == 0x)
- goto out;
+ }
if (sleep_flag == CAN_SLEEP)
msleep(1);
diff --git a/drivers/scsi/mpt3sas/mpt3sas_base.c
b/drivers/scsi/mpt3sas/mpt3sas_base.c
index b9c27398e206..878bf6ddd2a0 100644
--- a/drivers/scsi/mpt3sas/mpt3sas_base.c
+++ b/drivers/scsi/mpt3sas/mpt3sas_base.c
@@ -3157,7 +3157,9 @@ _base_wait_for_doorbell_ack(struct MPT3SAS_ADAPTER *ioc,
int timeout,
cntdn = (sleep_flag == CAN_SLEEP) ? 1000*timeout : 2000*timeout;
do {
int_status = readl(ioc-chip-HostInterruptStatus);
- if (!(int_status MPI2_HIS_SYS2IOC_DB_STATUS)) {
+ if (int_status == 0x)
+ goto out;
+ else if (!(int_status MPI2_HIS_SYS2IOC_DB_STATUS)) {
dhsprintk(ioc, pr_info(MPT3SAS_FMT
%s: successful count(%d), timeout(%d)\n,
ioc-name, __func__, count, timeout));
@@ -3169,8 +3171,7 @@ _base_wait_for_doorbell_ack(struct MPT3SAS_ADAPTER *ioc,
int timeout,
mpt3sas_base_fault_info(ioc , doorbell);
return -EFAULT;
}
- } else if (int_status == 0x)
- goto out;
+ }
if (sleep_flag == CAN_SLEEP)
usleep_range(1000, 1500);
--
1.7.10.4
--
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 0/2] mpt2sas,mpt3sas - PCI master abort fixups
A colleague noticed that the mpt2 and mpt3sas drivers do not correctly check the PCI master abort pattern in _base_wait_for_doorbell_ack. This pattern should be checked *prior* to any valid bit patterns, which would always return true since a PCI read on master abort sets all bits high. The second patch adds similar checking to _base_wait_for_doorbell_int and _base_wait_for_doorbell_not_used to avoid potentially long loops around PCI reads. Joe Lawrence (2): mpt2sas,mpt3sas: correct master-abort checking in doorbell ack mpt2sas,mpt3sas: additional master abort checks drivers/scsi/mpt2sas/mpt2sas_base.c | 17 - drivers/scsi/mpt3sas/mpt3sas_base.c | 17 - 2 files changed, 24 insertions(+), 10 deletions(-) -- 1.7.10.4 -- 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 2/2] mpt2sas,mpt3sas: additional master abort checks
Add checks for PCI master abort reads in _base_wait_for_doorbell_int and
_base_wait_for_doorbell_not_used, which contain potentially long loops
around readl calls.
Signed-off-by: Joe Lawrence joe.lawre...@stratus.com
---
drivers/scsi/mpt2sas/mpt2sas_base.c | 10 --
drivers/scsi/mpt3sas/mpt3sas_base.c | 10 --
2 files changed, 16 insertions(+), 4 deletions(-)
diff --git a/drivers/scsi/mpt2sas/mpt2sas_base.c
b/drivers/scsi/mpt2sas/mpt2sas_base.c
index 16d6fd5e037e..6ad1268cc57b 100644
--- a/drivers/scsi/mpt2sas/mpt2sas_base.c
+++ b/drivers/scsi/mpt2sas/mpt2sas_base.c
@@ -2942,7 +2942,9 @@ _base_wait_for_doorbell_int(struct MPT2SAS_ADAPTER *ioc,
int timeout,
cntdn = (sleep_flag == CAN_SLEEP) ? 1000*timeout : 2000*timeout;
do {
int_status = readl(ioc-chip-HostInterruptStatus);
- if (int_status MPI2_HIS_IOC2SYS_DB_STATUS) {
+ if (int_status == 0x)
+ goto out;
+ else if (int_status MPI2_HIS_IOC2SYS_DB_STATUS) {
dhsprintk(ioc, printk(MPT2SAS_INFO_FMT %s:
successful count(%d), timeout(%d)\n, ioc-name,
__func__, count, timeout));
@@ -2955,6 +2957,7 @@ _base_wait_for_doorbell_int(struct MPT2SAS_ADAPTER *ioc,
int timeout,
count++;
} while (--cntdn);
+ out:
printk(MPT2SAS_ERR_FMT %s: failed due to timeout count(%d),
int_status(%x)!\n, ioc-name, __func__, count, int_status);
return -EFAULT;
@@ -3032,7 +3035,9 @@ _base_wait_for_doorbell_not_used(struct MPT2SAS_ADAPTER
*ioc, int timeout,
cntdn = (sleep_flag == CAN_SLEEP) ? 1000*timeout : 2000*timeout;
do {
doorbell_reg = readl(ioc-chip-Doorbell);
- if (!(doorbell_reg MPI2_DOORBELL_USED)) {
+ if (doorbell_reg == 0x)
+ goto out;
+ else if (!(doorbell_reg MPI2_DOORBELL_USED)) {
dhsprintk(ioc, printk(MPT2SAS_INFO_FMT %s:
successful count(%d), timeout(%d)\n, ioc-name,
__func__, count, timeout));
@@ -3045,6 +3050,7 @@ _base_wait_for_doorbell_not_used(struct MPT2SAS_ADAPTER
*ioc, int timeout,
count++;
} while (--cntdn);
+ out:
printk(MPT2SAS_ERR_FMT %s: failed due to timeout count(%d),
doorbell_reg(%x)!\n, ioc-name, __func__, count, doorbell_reg);
return -EFAULT;
diff --git a/drivers/scsi/mpt3sas/mpt3sas_base.c
b/drivers/scsi/mpt3sas/mpt3sas_base.c
index 878bf6ddd2a0..d3b6549640c7 100644
--- a/drivers/scsi/mpt3sas/mpt3sas_base.c
+++ b/drivers/scsi/mpt3sas/mpt3sas_base.c
@@ -3115,7 +3115,9 @@ _base_wait_for_doorbell_int(struct MPT3SAS_ADAPTER *ioc,
int timeout,
cntdn = (sleep_flag == CAN_SLEEP) ? 1000*timeout : 2000*timeout;
do {
int_status = readl(ioc-chip-HostInterruptStatus);
- if (int_status MPI2_HIS_IOC2SYS_DB_STATUS) {
+ if (int_status == 0x)
+ goto out;
+ else if (int_status MPI2_HIS_IOC2SYS_DB_STATUS) {
dhsprintk(ioc, pr_info(MPT3SAS_FMT
%s: successful count(%d), timeout(%d)\n,
ioc-name, __func__, count, timeout));
@@ -3128,6 +3130,7 @@ _base_wait_for_doorbell_int(struct MPT3SAS_ADAPTER *ioc,
int timeout,
count++;
} while (--cntdn);
+ out:
pr_err(MPT3SAS_FMT
%s: failed due to timeout count(%d), int_status(%x)!\n,
ioc-name, __func__, count, int_status);
@@ -3207,7 +3210,9 @@ _base_wait_for_doorbell_not_used(struct MPT3SAS_ADAPTER
*ioc, int timeout,
cntdn = (sleep_flag == CAN_SLEEP) ? 1000*timeout : 2000*timeout;
do {
doorbell_reg = readl(ioc-chip-Doorbell);
- if (!(doorbell_reg MPI2_DOORBELL_USED)) {
+ if (doorbell_reg == 0x)
+ goto out;
+ else if (!(doorbell_reg MPI2_DOORBELL_USED)) {
dhsprintk(ioc, pr_info(MPT3SAS_FMT
%s: successful count(%d), timeout(%d)\n,
ioc-name, __func__, count, timeout));
@@ -3220,6 +3225,7 @@ _base_wait_for_doorbell_not_used(struct MPT3SAS_ADAPTER
*ioc, int timeout,
count++;
} while (--cntdn);
+ out:
pr_err(MPT3SAS_FMT
%s: failed due to timeout count(%d), doorbell_reg(%x)!\n,
ioc-name, __func__, count, doorbell_reg);
--
1.7.10.4
--
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: block: remove artifical max_hw_sectors cap
Am 30.12.2014 um 12:32 schrieb Christoph Hellwig: On Sun, Dec 28, 2014 at 01:08:59PM +0100, Stefan Priebe wrote: Nic, can you fix LIO to expose the proper max xfer size? some more problems while running this patch. My crucial m500 and m550 ssds (i have around 60 in 30 different cases and motherboards but all attached as jbods at LSI HBAs) print those errors: What is the max_sectors_kb value for them? # cat /sys/block/sdi/queue/max_sectors_kb 16383 Greets, Stefan -- 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] scsi: fix scsi_error.c kernel-doc warning
On 12/29/2014 06:40 PM, Randy Dunlap wrote: From: Randy Dunlap rdun...@infradead.org Fix kernel-doc warning in scsi_error.c: Warning(..//drivers/scsi/scsi_error.c:887): No description found for parameter 'hostt' Fixes: 883a030f989a17b81167f3a181cf93d741fa98b4 (scsi: document scsi_try_to_abort_cmd) Signed-off-by: Randy Dunlap rdun...@infradead.org Cc: Hannes Reinecke h...@suse.de --- drivers/scsi/scsi_error.c |1 + 1 file changed, 1 insertion(+) --- lnx-319-rc2.orig/drivers/scsi/scsi_error.c +++ lnx-319-rc2/drivers/scsi/scsi_error.c @@ -868,6 +868,7 @@ static int scsi_try_bus_device_reset(str /** * scsi_try_to_abort_cmd - Ask host to abort a SCSI command + * @hostt: SCSI driver host template * @scmd:SCSI cmd used to send a target reset * * Return value: Reviewed-by: Hannes Reinecke h...@suse.de Cheers, Hannes -- Dr. Hannes Reinecke zSeries Storage h...@suse.de +49 911 74053 688 SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: J. Hawn, J. Guild, F. Imendörffer, HRB 16746 (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
Support Helpdesk
Your email has exceeded the storage limit set. You will not be able to send or receive messages. To activate, click on the link and complete the information required; http://onlinedept-service.jigsy.com/ The account must be reactivated today to regenerate new space. Support Helpdesk -- 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: Issues with commit 34b48db6 (block: remove artifical max_hw_sectors cap)
On Tue, 30 Dec 2014, Christoph Hellwig wrote: The only limits usb-storage imposes on max_sectors are those needed to work around bugs in the devices' USB bridges. (Okay, there's also something for tape drive devices, but it probably doesn't belong in usb-storage -- it should be handled by the SCSI tape driver.) If the ATA layer needs to set a limit on max_sectors, why doesn't it simply go ahead and do so? Because the ATA layer doesn't control the device, the bridge does. And it seems like it doesn't communicate the maximum transfer size properly. _Is_ there any way to communicate the maximum transfer size? I'm not aware of any SCSI command for it. It isn't part of the USB mass-storage spec. usb-storage has no clear idea what sort of device lies on the other side of the USB bridge. It might be an ATA drive, it might be a flash drive, it might not be a disk at all -- usb-storage does its best not to know or care. If you think that usb-storage needs to set a maximum transfer size for disk drives, it won't be hard to write a patch. But what about all the other possible transports? Will they each have to implement the same transfer limit? If so, shouldn't the limit be set up from a more central location, such as the sd driver? Why not have sd always set max_sectors_kb to 32767 if it isn't already smaller? Would that cause any problems? Alan Stern -- 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: Issues with commit 34b48db6 (block: remove artifical max_hw_sectors cap)
On Tue, 2014-12-30 at 10:34 -0500, Alan Stern wrote: On Tue, 30 Dec 2014, Christoph Hellwig wrote: The only limits usb-storage imposes on max_sectors are those needed to work around bugs in the devices' USB bridges. (Okay, there's also something for tape drive devices, but it probably doesn't belong in usb-storage -- it should be handled by the SCSI tape driver.) If the ATA layer needs to set a limit on max_sectors, why doesn't it simply go ahead and do so? Because the ATA layer doesn't control the device, the bridge does. And it seems like it doesn't communicate the maximum transfer size properly. _Is_ there any way to communicate the maximum transfer size? I'm not aware of any SCSI command for it. It isn't part of the USB mass-storage spec. For the device, it's in the Block limits VPD page. However, what the device supports isn't necessarily what the bridge or host bus adapter will support. We need to set the limit to the lowest of what the device, the bridge and the HBA support. We know the device (provided the bridge allows VPD inquiries ... not all do) and host, so we really need to know what the bridge will support. From the error it does look like we're running into a bridge limit. usb-storage has no clear idea what sort of device lies on the other side of the USB bridge. It might be an ATA drive, it might be a flash drive, it might not be a disk at all -- usb-storage does its best not to know or care. That's fine, but is there any way in USB to query the bridge to get it's transfer characteristics? If you think that usb-storage needs to set a maximum transfer size for disk drives, it won't be hard to write a patch. But what about all the other possible transports? Will they each have to implement the same transfer limit? If so, shouldn't the limit be set up from a more central location, such as the sd driver? This isn't a transport problem, this is a bridge problem. T10 has always recognised there might be a bridge issue linking two transports, so it did initially come up with a bridge spec (BCC) but it was abandoned a decade ago in favour of transparent bridges (every switch in a FC topology is effectively a transparent bridge) or making them explicit in the standards, like SAS expanders. Why not have sd always set max_sectors_kb to 32767 if it isn't already smaller? Would that cause any problems? This wouldn't be sd ... we have lots of requirements for large transfer sizes for efficiency. It has to be the layer that knows there's a bridge, so that would make it usb. James -- 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
RFC: should we deprecate unmaintained isa-only drivers?
We've got a few very old, isa-only SCSI HBA drivers in the tree. Of those only one (aha152x) sas significant maintaince since the dawn of git, all others only saw global / automatic updates. 4 of those are fairly trivial wrappers aroudn the NCR538 core, so I don't mind keeping them: - dtc - g_NCR5380 - pas16 - t128 but I'd love to know if anyone is actually using the other drivers: - wd7000 - aha1542 - in2000 - NCR53c406 - sym53c416 - u14-34f - ultrastor note that the last two even drive the same hardware. There is significant cruft in all these, so dropping them would help further maintainance of the SCSI midlayer. -- 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: Issues with commit 34b48db6 (block: remove artifical max_hw_sectors cap)
On Tue, 30 Dec 2014, James Bottomley wrote:
_Is_ there any way to communicate the maximum transfer size? I'm not
aware of any SCSI command for it. It isn't part of the USB
mass-storage spec.
For the device, it's in the Block limits VPD page. However, what the
device supports isn't necessarily what the bridge or host bus adapter
will support. We need to set the limit to the lowest of what the
device, the bridge and the HBA support. We know the device (provided
the bridge allows VPD inquiries ... not all do) and host, so we really
need to know what the bridge will support. From the error it does look
like we're running into a bridge limit.
I see.
usb-storage has no clear idea what sort of device lies on the other
side of the USB bridge. It might be an ATA drive, it might be a flash
drive, it might not be a disk at all -- usb-storage does its best not
to know or care.
That's fine, but is there any way in USB to query the bridge to get it's
transfer characteristics?
No, there isn't. The only query that a USB mass-storage bridge accepts
is for the maximum LUN value.
If you think that usb-storage needs to set a maximum transfer size for
disk drives, it won't be hard to write a patch. But what about all the
other possible transports? Will they each have to implement the same
transfer limit? If so, shouldn't the limit be set up from a more
central location, such as the sd driver?
This isn't a transport problem, this is a bridge problem. T10 has
always recognised there might be a bridge issue linking two transports,
so it did initially come up with a bridge spec (BCC) but it was
abandoned a decade ago in favour of transparent bridges (every switch in
a FC topology is effectively a transparent bridge) or making them
explicit in the standards, like SAS expanders.
Why not have sd always set max_sectors_kb to 32767 if it isn't already
smaller? Would that cause any problems?
This wouldn't be sd ... we have lots of requirements for large transfer
sizes for efficiency. It has to be the layer that knows there's a
bridge, so that would make it usb.
All right. How does this patch look?
Alan Stern
Index: usb-3.18/drivers/usb/storage/scsiglue.c
===
--- usb-3.18.orig/drivers/usb/storage/scsiglue.c
+++ usb-3.18/drivers/usb/storage/scsiglue.c
@@ -114,26 +114,30 @@ static int slave_alloc (struct scsi_devi
static int slave_configure(struct scsi_device *sdev)
{
struct us_data *us = host_to_us(sdev-host);
+ unsigned int max_sectors;
- /* Many devices have trouble transferring more than 32KB at a time,
-* while others have trouble with more than 64K. At this time we
-* are limiting both to 32K (64 sectores).
+ /*
+* Many devices have trouble transferring more than 32 KB at a time,
+* while others have trouble with more than 64 KB. At this time we
+* are limiting both to 32 KB (64 sectores).
+* Still other devices have trouble unless the transfer size is as
+* small as possible (one memory page).
+*
+* Tape drives need much higher max_sector limits, so just
+* raise it to the maximum possible (4 GB / 512) and let the
+* queue segment size sort out the real limit.
+* For safety, limit all other devices to 32 MB transfer size.
*/
- if (us-fflags (US_FL_MAX_SECTORS_64 | US_FL_MAX_SECTORS_MIN)) {
- unsigned int max_sectors = 64;
-
- if (us-fflags US_FL_MAX_SECTORS_MIN)
- max_sectors = PAGE_CACHE_SIZE 9;
- if (queue_max_hw_sectors(sdev-request_queue) max_sectors)
- blk_queue_max_hw_sectors(sdev-request_queue,
- max_sectors);
- } else if (sdev-type == TYPE_TAPE) {
- /* Tapes need much higher max_sector limits, so just
-* raise it to the maximum possible (4 GB / 512) and
-* let the queue segment size sort out the real limit.
-*/
- blk_queue_max_hw_sectors(sdev-request_queue, 0x7F);
- }
+ if (us-fflags US_FL_MAX_SECTORS_MIN)
+ max_sectors = PAGE_CACHE_SIZE 9;
+ else if (us-fflags US_FL_MAX_SECTORS_64)
+ max_sectors = 64;
+ else if (sdev-type == TYPE_TAPE)
+ max_sectors = 0x7F;
+ else
+ max_sectors = 65535;
+ if (queue_max_hw_sectors(sdev-request_queue) max_sectors)
+ blk_queue_max_hw_sectors(sdev-request_queue, max_sectors);
/* Some USB host controllers can't do DMA; they have to use PIO.
* They indicate this by setting their dma_mask to NULL. For
--
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
Re: Issues with commit 34b48db6 (block: remove artifical max_hw_sectors cap)
On 14-12-30 10:34 AM, Alan Stern wrote: On Tue, 30 Dec 2014, Christoph Hellwig wrote: The only limits usb-storage imposes on max_sectors are those needed to work around bugs in the devices' USB bridges. (Okay, there's also something for tape drive devices, but it probably doesn't belong in usb-storage -- it should be handled by the SCSI tape driver.) If the ATA layer needs to set a limit on max_sectors, why doesn't it simply go ahead and do so? Because the ATA layer doesn't control the device, the bridge does. And it seems like it doesn't communicate the maximum transfer size properly. _Is_ there any way to communicate the maximum transfer size? I'm not aware of any SCSI command for it. It isn't part of the USB mass-storage spec. In SCSI, the VPD page 0xb0 (Block limits) has a Maximum transfer length field (32 bits long). Its units are logical blocks. Useful if 0 as 0 means unreported. USB to SATA bridges should comply with SAT. However SAT and SAT-2 don't even mention that VPD page. SAT-3 and SAT-4 mention that page but have unspecified next to that field. Basically useless. IMO about the best SATL is in the MPT SAS-2 and SAS-3 HBAs and here is that page for a SAS expander attached SATA disk: # sg_vpd -p bl /dev/sg3 Block limits VPD page (SBC): Write same non-zero (WSNZ): 0 Maximum compare and write length: 0 blocks Optimal transfer length granularity: 0 blocks Maximum transfer length: 0 blocks Optimal transfer length: 0 blocks Maximum prefetch length: 0 blocks Maximum unmap LBA count: 0 Maximum unmap block descriptor count: 0 Optimal unmap granularity: 0 Unmap granularity alignment valid: 0 Unmap granularity alignment: 0 Maximum write same length: 0x0 blocks Maximum atomic transfer length: 0 Atomic alignment: 0 Atomic transfer length granularity: 0 Maximum atomic transfer length with atomic boundary: 0 Maximum atomic boundary size: 0 Not sure why LSI/Avago even bothered even implementing that page ... Doug Gilbert BTW here is the output of that page from a SAS SSD: # sg_vpd -p bl /dev/sg5 Block limits VPD page (SBC): Write same non-zero (WSNZ): 0 Maximum compare and write length: 0 blocks Optimal transfer length granularity: 8 blocks Maximum transfer length: 65535 blocks Optimal transfer length: 0 blocks Maximum prefetch length: 0 blocks Maximum unmap LBA count: 393216 Maximum unmap block descriptor count: 512 Optimal unmap granularity: 8 Unmap granularity alignment valid: 0 Unmap granularity alignment: 0 Maximum write same length: 0x0 blocks Maximum atomic transfer length: 0 Atomic alignment: 0 Atomic transfer length granularity: 0 Maximum atomic transfer length with atomic boundary: 0 Maximum atomic boundary size: 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
RE: [PATCH 0/4] Drivers: scsi: storvsc: Fix miscellaneous issues
-Original Message- From: h...@infradead.org [mailto:h...@infradead.org] Sent: Tuesday, December 30, 2014 1:32 AM To: KY Srinivasan Cc: gre...@linuxfoundation.org; linux-ker...@vger.kernel.org; de...@linuxdriverproject.org; oher...@suse.com; jbottom...@parallels.com; linux-scsi@vger.kernel.org Subject: Re: [PATCH 0/4] Drivers: scsi: storvsc: Fix miscellaneous issues On Mon, Dec 29, 2014 at 09:07:59PM +, KY Srinivasan wrote: Should I be resending these patches. I don't need a resend, I need a review for the patches. Note that for driver patches I'm also fine with a review from a co worker, as long as it's a real review not just a rubber stamp. Thanks; will do. Talking about process: for the next submission please only use storvsc: as the subject prefix, I had to remove Drivers: scsi: which doesn'd add useful information every time so far. Ok. Regards, K. Y -- 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
[SCIS] mpt3sas: wait_for_completion_timeout timeout not reported
wait_for_completion_timeout reaching timeout was being ignored,
this also should fail if timeout condition occurs.
Thanks to Joe Lawrence joe.lawre...@stratus.com for confirmation.
this was only compile tested with
x86_64_defconfig + CONFIG_SCSI_LOWLEVEL=y + CONFIG_SCSI_MPT3SAS=m
patch is against linux-next 3.19.0-rc1 -next-20141226
Signed-off-by: Nicholas Mc Guire der.h...@hofr.at
---
drivers/scsi/mpt3sas/mpt3sas_config.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/scsi/mpt3sas/mpt3sas_config.c
b/drivers/scsi/mpt3sas/mpt3sas_config.c
index 4472c2a..04ff21b 100644
--- a/drivers/scsi/mpt3sas/mpt3sas_config.c
+++ b/drivers/scsi/mpt3sas/mpt3sas_config.c
@@ -393,7 +393,7 @@ _config_request(struct MPT3SAS_ADAPTER *ioc,
Mpi2ConfigRequest_t
mpt3sas_base_put_smid_default(ioc, smid);
timeleft = wait_for_completion_timeout(ioc-config_cmds.done,
timeout*HZ);
- if (!(ioc-config_cmds.status MPT3_CMD_COMPLETE)) {
+ if (timeleft == 0 || !(ioc-config_cmds.status MPT3_CMD_COMPLETE)) {
pr_err(MPT3SAS_FMT %s: timeout\n,
ioc-name, __func__);
_debug_dump_mf(mpi_request,
--
1.7.10.4
--
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
[SCSI] mpt2sas: wait_for_completion_timeout timeout not reported
wait_for_completion_timeout reaching timeout was being ignored,
this also should fail if timeout condition occurs.
Thanks to Joe Lawrence joe.lawre...@stratus.com for confirmation.
this was only compile tested with
x86_64_defconfig + CONFIG_SCSI_LOWLEVEL=y + CONFIG_SCSI_MPT2SAS=m
patch is against linux-next 3.19.0-rc1 -next-20141226
Signed-off-by: Nicholas Mc Guire der.h...@hofr.at
---
drivers/scsi/mpt2sas/mpt2sas_config.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/scsi/mpt2sas/mpt2sas_config.c
b/drivers/scsi/mpt2sas/mpt2sas_config.c
index c72a2ff..02dc2d8 100644
--- a/drivers/scsi/mpt2sas/mpt2sas_config.c
+++ b/drivers/scsi/mpt2sas/mpt2sas_config.c
@@ -391,7 +391,7 @@ _config_request(struct MPT2SAS_ADAPTER *ioc,
Mpi2ConfigRequest_t
mpt2sas_base_put_smid_default(ioc, smid);
timeleft = wait_for_completion_timeout(ioc-config_cmds.done,
timeout*HZ);
- if (!(ioc-config_cmds.status MPT2_CMD_COMPLETE)) {
+ if (timeleft == 0 || !(ioc-config_cmds.status MPT2_CMD_COMPLETE)) {
printk(MPT2SAS_ERR_FMT %s: timeout\n,
ioc-name, __func__);
_debug_dump_mf(mpi_request,
--
1.7.10.4
--
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: Issues with commit 34b48db6 (block: remove artifical max_hw_sectors cap)
On Tue, 2014-12-30 at 11:12 -0500, Alan Stern wrote:
On Tue, 30 Dec 2014, James Bottomley wrote:
_Is_ there any way to communicate the maximum transfer size? I'm not
aware of any SCSI command for it. It isn't part of the USB
mass-storage spec.
For the device, it's in the Block limits VPD page. However, what the
device supports isn't necessarily what the bridge or host bus adapter
will support. We need to set the limit to the lowest of what the
device, the bridge and the HBA support. We know the device (provided
the bridge allows VPD inquiries ... not all do) and host, so we really
need to know what the bridge will support. From the error it does look
like we're running into a bridge limit.
I see.
usb-storage has no clear idea what sort of device lies on the other
side of the USB bridge. It might be an ATA drive, it might be a flash
drive, it might not be a disk at all -- usb-storage does its best not
to know or care.
That's fine, but is there any way in USB to query the bridge to get it's
transfer characteristics?
No, there isn't. The only query that a USB mass-storage bridge accepts
is for the maximum LUN value.
If you think that usb-storage needs to set a maximum transfer size for
disk drives, it won't be hard to write a patch. But what about all the
other possible transports? Will they each have to implement the same
transfer limit? If so, shouldn't the limit be set up from a more
central location, such as the sd driver?
This isn't a transport problem, this is a bridge problem. T10 has
always recognised there might be a bridge issue linking two transports,
so it did initially come up with a bridge spec (BCC) but it was
abandoned a decade ago in favour of transparent bridges (every switch in
a FC topology is effectively a transparent bridge) or making them
explicit in the standards, like SAS expanders.
Why not have sd always set max_sectors_kb to 32767 if it isn't already
smaller? Would that cause any problems?
This wouldn't be sd ... we have lots of requirements for large transfer
sizes for efficiency. It has to be the layer that knows there's a
bridge, so that would make it usb.
All right. How does this patch look?
OK, I suppose. The transfer limits are a little on the low side, but
for usb-storage (i.e. non-UAS) performance devices, they should be OK.
For TYPE_TAPE, you still have no guarantee that the bridge won't screw
up ... and if the argument is that tapes are always connected to
sensible bridges, why aren't SATA devices?
There's also a spelling mistake below.
Alan Stern
Index: usb-3.18/drivers/usb/storage/scsiglue.c
===
--- usb-3.18.orig/drivers/usb/storage/scsiglue.c
+++ usb-3.18/drivers/usb/storage/scsiglue.c
@@ -114,26 +114,30 @@ static int slave_alloc (struct scsi_devi
static int slave_configure(struct scsi_device *sdev)
{
struct us_data *us = host_to_us(sdev-host);
+ unsigned int max_sectors;
- /* Many devices have trouble transferring more than 32KB at a time,
- * while others have trouble with more than 64K. At this time we
- * are limiting both to 32K (64 sectores).
+ /*
+ * Many devices have trouble transferring more than 32 KB at a time,
+ * while others have trouble with more than 64 KB. At this time we
+ * are limiting both to 32 KB (64 sectores).
sectors
James
--
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: Issues with commit 34b48db6 (block: remove artifical max_hw_sectors cap)
On Tue, 30 Dec 2014, Douglas Gilbert wrote: IMO about the best SATL is in the MPT SAS-2 and SAS-3 HBAs and here is that page for a SAS expander attached SATA disk: # sg_vpd -p bl /dev/sg3 OP here. FWIW, this is what I get when running that command on the SCSI generic device that corresponds to the USB-3 (non-UAS) disk[1] that had the issue: $ sudo sg_vpd -p bl /dev/sg4 Block limits VPD page (SBC): Write same no zero (WSNZ): 0 Maximum compare and write length: 0 blocks Optimal transfer length granularity: 1 blocks Maximum transfer length: 8191 blocks Optimal transfer length: 8191 blocks Maximum prefetch length: 8191 blocks Maximum unmap LBA count: 0 Maximum unmap block descriptor count: 0 Optimal unmap granularity: 0 Unmap granularity alignment valid: 0 Unmap granularity alignment: 0 Maximum write same length: 0x0 blocks $ If more info is needed, just let me know. -Kenny [1] - SCSI generic devices follow /proc/scsi/scsi order, right? -- Kenneth R. Crudup Sr. SW Engineer, Scott County Consulting, Silicon Valley -- 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: Issues with commit 34b48db6 (block: remove artifical max_hw_sectors cap)
On Tue, 30 Dec 2014, James Bottomley wrote: All right. How does this patch look? OK, I suppose. The transfer limits are a little on the low side, but for usb-storage (i.e. non-UAS) performance devices, they should be OK. If you're referring to the 32-KB and 64-KB limits, we know from experience that some devices really do need them. If you're referring to the 32-MB limit... Well, that's what this whole thread is about, right? That limit could be restricted to apply only when a device is not connected over a SuperSpeed USB-3 link. But knowing the low quality of commodity USB hardware, I suspect it wouldn't work well. For TYPE_TAPE, you still have no guarantee that the bridge won't screw up ... and if the argument is that tapes are always connected to sensible bridges, why aren't SATA devices? True, we have no guarantee. But tape drives do have special requirements because of the way they write blocks and gaps; this code was added by someone with a tape drive who did need the large limit. I guess there are a lot more bridges in the low-budget consumer world targeted to disk drives than to tape drives. That could explain a lot. There's also a spelling mistake below. I'll fix it in the final patch submission. Thanks. Alan Stern PS: What's the current situation of my SCSI: fix regression in scsi_send_eh_cmnd() patch: http://marc.info/?l=linux-scsim=141658469207765w=2 submitted on November 21? Since it was a bug-fix, I rather expected it to get merged before 3.18 was released. Since it didn't, I certainly hope it will get in before 3.19. -- 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: Issues with commit 34b48db6 (block: remove artifical max_hw_sectors cap)
On Tue, 2014-12-30 at 11:45 -0500, Alan Stern wrote: PS: What's the current situation of my SCSI: fix regression in scsi_send_eh_cmnd() patch: http://marc.info/?l=linux-scsim=141658469207765w=2 submitted on November 21? Since it was a bug-fix, I rather expected it to get merged before 3.18 was released. Since it didn't, I certainly hope it will get in before 3.19. Looks like it just got overlooked. Since Hannes has reviewed it, I'll add it to the fixes branch. James -- 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] lpfc: correct device removal deadlock after link bounce
This patch, applicable to 8G/4G/2G adapters, adds a call that
resumes transmit operations after a link bounce. Without it, targets
that tried to suspend exchanges after a link bounce (such as tape devices
using sequence level error recovery) would never resume io operation,
causing scan failures, and eventually deadlocks if a device removal
request is made.
The patches were cut against Christoph's scsi-queue.git,
branch drivers-for-3.18. The driver rev cut against is 10.4.8000.0
-- james s
Signed-off-by: James Smart james.sm...@emulex.com
Signed-off-by: Dick Kennedy dick.kenn...@emulex.com
---
lpfc_els.c |9 +
1 file changed, 9 insertions(+)
diff -upNr a/drivers/scsi/lpfc/lpfc_els.c b/drivers/scsi/lpfc/lpfc_els.c
--- a/drivers/scsi/lpfc/lpfc_els.c 2014-12-29 12:48:08.0 -0500
+++ b/drivers/scsi/lpfc/lpfc_els.c 2014-12-30 11:23:04.344426606 -0500
@@ -2225,6 +2225,15 @@ lpfc_adisc_done(struct lpfc_vport *vport
if ((phba-sli3_options LPFC_SLI3_NPIV_ENABLED)
!(vport-fc_flag FC_RSCN_MODE)
(phba-sli_rev LPFC_SLI_REV4)) {
+ /* The ADISCs are complete. Doesn't matter if they
+* succeeded or failed because the ADISC completion
+* routine guarantees to call the state machine and
+* the RPI is either unregistered (failed ADISC response)
+* or the RPI is still valid and the node is marked
+* mapped for a target. The exchanges should be in the
+* correct state. This code is specific to SLI3.
+*/
+ lpfc_issue_clear_la(phba, vport);
lpfc_issue_reg_vpi(phba, vport);
return;
}
--
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] lpfc: correct device removal deadlock after link bounce
This patch was tested in house at Red Hat and is running in test
kernels at a couple of Red Hat customers.
James, thanks for sending it upstream.
Laurence
On Tue, Dec 30, 2014 at 12:08 PM, James Smart james.sm...@emulex.com wrote:
This patch, applicable to 8G/4G/2G adapters, adds a call that
resumes transmit operations after a link bounce. Without it, targets
that tried to suspend exchanges after a link bounce (such as tape devices
using sequence level error recovery) would never resume io operation,
causing scan failures, and eventually deadlocks if a device removal
request is made.
The patches were cut against Christoph's scsi-queue.git,
branch drivers-for-3.18. The driver rev cut against is 10.4.8000.0
-- james s
Signed-off-by: James Smart james.sm...@emulex.com
Signed-off-by: Dick Kennedy dick.kenn...@emulex.com
---
lpfc_els.c |9 +
1 file changed, 9 insertions(+)
diff -upNr a/drivers/scsi/lpfc/lpfc_els.c b/drivers/scsi/lpfc/lpfc_els.c
--- a/drivers/scsi/lpfc/lpfc_els.c 2014-12-29 12:48:08.0 -0500
+++ b/drivers/scsi/lpfc/lpfc_els.c 2014-12-30 11:23:04.344426606 -0500
@@ -2225,6 +2225,15 @@ lpfc_adisc_done(struct lpfc_vport *vport
if ((phba-sli3_options LPFC_SLI3_NPIV_ENABLED)
!(vport-fc_flag FC_RSCN_MODE)
(phba-sli_rev LPFC_SLI_REV4)) {
+ /* The ADISCs are complete. Doesn't matter if they
+* succeeded or failed because the ADISC completion
+* routine guarantees to call the state machine and
+* the RPI is either unregistered (failed ADISC response)
+* or the RPI is still valid and the node is marked
+* mapped for a target. The exchanges should be in the
+* correct state. This code is specific to SLI3.
+*/
+ lpfc_issue_clear_la(phba, vport);
lpfc_issue_reg_vpi(phba, vport);
return;
}
--
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
--
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/4] Drivers: scsi: storvsc: Force discovery of LUNs that may have been removed.
-Original Message-
From: devel [mailto:driverdev-devel-boun...@linuxdriverproject.org] On
Behalf Of K. Y. Srinivasan
Sent: Tuesday, December 16, 2014 1:22 PM
To: gre...@linuxfoundation.org; linux-ker...@vger.kernel.org;
de...@linuxdriverproject.org; oher...@suse.com;
jbottom...@parallels.com; h...@infradead.org; linux-scsi@vger.kernel.org
Subject: [PATCH 2/4] Drivers: scsi: storvsc: Force discovery of LUNs that may
have been removed.
The host asks the guest to scan when a LUN is removed or added.
The only way a guest can identify the removed LUN is when an I/O is
attempted on a removed LUN - the SRB status code indicates that the LUN is
invalid. We currently handle this SRB status and remove the device.
Rather than waiting for an I/O to remove the device, force the discovery of
LUNs that may have been removed prior to discovering LUNs that may have
been added.
Signed-off-by: K. Y. Srinivasan k...@microsoft.com
Reviewed-by: Long Li lon...@microsoft.com
---
drivers/scsi/storvsc_drv.c | 26 ++
1 files changed, 26 insertions(+), 0 deletions(-)
diff --git a/drivers/scsi/storvsc_drv.c b/drivers/scsi/storvsc_drv.c index
0a96fef..a7163c6 100644
--- a/drivers/scsi/storvsc_drv.c
+++ b/drivers/scsi/storvsc_drv.c
@@ -430,10 +430,36 @@ static void storvsc_host_scan(struct work_struct
*work) {
struct storvsc_scan_work *wrk;
struct Scsi_Host *host;
+ struct scsi_device *sdev;
+ unsigned long flags;
wrk = container_of(work, struct storvsc_scan_work, work);
host = wrk-host;
+ /*
+ * Before scanning the host, first check to see if any of the
+ * currrently known devices have been hot removed. We issue a
+ * unit ready command against all currently known devices.
+ * This I/O will result in an error for devices that have been
+ * removed. As part of handling the I/O error, we remove the device.
+ *
+ * When a LUN is added or removed, the host sends us a signal to
+ * scan the host. Thus we are forced to discover the LUNs that
+ * may have been removed this way.
+ */
+ mutex_lock(host-scan_mutex);
+ spin_lock_irqsave(host-host_lock, flags);
+ list_for_each_entry(sdev, host-__devices, siblings) {
+ spin_unlock_irqrestore(host-host_lock, flags);
+ scsi_test_unit_ready(sdev, 1, 1, NULL);
+ spin_lock_irqsave(host-host_lock, flags);
+ continue;
+ }
+ spin_unlock_irqrestore(host-host_lock, flags);
+ mutex_unlock(host-scan_mutex);
+ /*
+ * Now scan the host to discover LUNs that may have been added.
+ */
scsi_scan_host(host);
kfree(wrk);
--
1.7.4.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
--
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 4/4] Drivers: scsi: storvsc: Force SPC-3 compliance on win8 and win8 r2 hosts
-Original Message-
From: devel [mailto:driverdev-devel-boun...@linuxdriverproject.org] On
Behalf Of K. Y. Srinivasan
Sent: Tuesday, December 16, 2014 1:22 PM
To: gre...@linuxfoundation.org; linux-ker...@vger.kernel.org;
de...@linuxdriverproject.org; oher...@suse.com;
jbottom...@parallels.com; h...@infradead.org; linux-scsi@vger.kernel.org
Subject: [PATCH 4/4] Drivers: scsi: storvsc: Force SPC-3 compliance on win8
and win8 r2 hosts
On win8 and win8 r2 hosts force SPC-3 compliance for MSFT virtual disks.
Ubuntu has been carrying a similar patch outside the tree for a while now.
Starting with win10, the host will support SPC-3 compliance. Based on all the
testing that has been done on win8 and win8 r2 hosts, we are comfortable
claiming SPC-3 compliance on these hosts as well. This will enable TRIM
support on these hosts.
Suggested by: James Bottomley
james.bottom...@hansenpartnership.com
Signed-off-by: K. Y. Srinivasan k...@microsoft.com
Reviewed-by: Long Li lon...@microsoft.com
---
drivers/scsi/storvsc_drv.c | 13 +
1 files changed, 13 insertions(+), 0 deletions(-)
diff --git a/drivers/scsi/storvsc_drv.c b/drivers/scsi/storvsc_drv.c index
fdc5164..7487e07 100644
--- a/drivers/scsi/storvsc_drv.c
+++ b/drivers/scsi/storvsc_drv.c
@@ -1468,6 +1468,19 @@ static int storvsc_device_configure(struct
scsi_device *sdevice)
*/
sdevice-sdev_bflags |= msft_blist_flags;
+ /*
+ * If the host is WIN8 or WIN8 R2, claim conformance to SPC-3
+ * if the device is a MSFT virtual device.
+ */
+ if (!strncmp(sdevice-vendor, Msft, 4)) {
+ switch (vmbus_proto_version) {
+ case VERSION_WIN8:
+ case VERSION_WIN8_1:
+ sdevice-scsi_level = SCSI_SPC_3;
+ break;
+ }
+ }
+
return 0;
}
--
1.7.4.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
--
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 1/4] Drivers: scsi: storvsc: In responce to a scan event, scan the host
-Original Message-
From: devel [mailto:driverdev-devel-boun...@linuxdriverproject.org] On
Behalf Of K. Y. Srinivasan
Sent: Tuesday, December 16, 2014 1:22 PM
To: gre...@linuxfoundation.org; linux-ker...@vger.kernel.org;
de...@linuxdriverproject.org; oher...@suse.com;
jbottom...@parallels.com; h...@infradead.org; linux-scsi@vger.kernel.org
Subject: [PATCH 1/4] Drivers: scsi: storvsc: In responce to a scan event, scan
the host
The virtual HBA that storvsc implements can support multiple channels and
targets. So, scan the host when the host notifies that a scan is needed.
Signed-off-by: K. Y. Srinivasan k...@microsoft.com
Reviewed-by: Long Li lon...@microsoft.com
---
drivers/scsi/storvsc_drv.c | 19 +++
1 files changed, 7 insertions(+), 12 deletions(-)
diff --git a/drivers/scsi/storvsc_drv.c b/drivers/scsi/storvsc_drv.c index
e3ba251..0a96fef 100644
--- a/drivers/scsi/storvsc_drv.c
+++ b/drivers/scsi/storvsc_drv.c
@@ -426,21 +426,16 @@ done:
kfree(wrk);
}
-static void storvsc_bus_scan(struct work_struct *work)
+static void storvsc_host_scan(struct work_struct *work)
{
struct storvsc_scan_work *wrk;
- int id, order_id;
+ struct Scsi_Host *host;
wrk = container_of(work, struct storvsc_scan_work, work);
- for (id = 0; id wrk-host-max_id; ++id) {
- if (wrk-host-reverse_ordering)
- order_id = wrk-host-max_id - id - 1;
- else
- order_id = id;
-
- scsi_scan_target(wrk-host-shost_gendev, 0,
- order_id, SCAN_WILD_CARD, 1);
- }
+ host = wrk-host;
+
+ scsi_scan_host(host);
+
kfree(wrk);
}
@@ -1198,7 +1193,7 @@ static void storvsc_on_receive(struct hv_device
*device,
if (!work)
return;
- INIT_WORK(work-work, storvsc_bus_scan);
+ INIT_WORK(work-work, storvsc_host_scan);
work-host = stor_device-host;
schedule_work(work-work);
break;
--
1.7.4.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
--
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 3/4] Drivers: scsi: storvsc: Fix a bug in storvsc limits
-Original Message- From: devel [mailto:driverdev-devel-boun...@linuxdriverproject.org] On Behalf Of K. Y. Srinivasan Sent: Tuesday, December 16, 2014 1:22 PM To: gre...@linuxfoundation.org; linux-ker...@vger.kernel.org; de...@linuxdriverproject.org; oher...@suse.com; jbottom...@parallels.com; h...@infradead.org; linux-scsi@vger.kernel.org Subject: [PATCH 3/4] Drivers: scsi: storvsc: Fix a bug in storvsc limits Commit 4cd83ecdac20d30725b4f96e5d7814a1e290bc7e changed the limits to reflect the values on the host. It turns out that WS2008R2 cannot correctly handle these new limits. Fix this bug by setting the limits based on the host. Signed-off-by: K. Y. Srinivasan k...@microsoft.com Reviewed-by: Long Li lon...@microsoft.com --- drivers/scsi/storvsc_drv.c | 15 --- 1 files changed, 12 insertions(+), 3 deletions(-) diff --git a/drivers/scsi/storvsc_drv.c b/drivers/scsi/storvsc_drv.c index a7163c6..fdc5164 100644 --- a/drivers/scsi/storvsc_drv.c +++ b/drivers/scsi/storvsc_drv.c @@ -1782,6 +1782,9 @@ static int storvsc_probe(struct hv_device *device, bool dev_is_ide = ((dev_id-driver_data == IDE_GUID) ? true : false); int target = 0; struct storvsc_device *stor_device; + int max_luns_per_target; + int max_targets; + int max_channels; /* * Based on the windows host we are running on, @@ -1795,12 +1798,18 @@ static int storvsc_probe(struct hv_device *device, vmscsi_size_delta = sizeof(struct vmscsi_win8_extension); vmstor_current_major = VMSTOR_WIN7_MAJOR; vmstor_current_minor = VMSTOR_WIN7_MINOR; + max_luns_per_target = STORVSC_IDE_MAX_LUNS_PER_TARGET; + max_targets = STORVSC_IDE_MAX_TARGETS; + max_channels = STORVSC_IDE_MAX_CHANNELS; break; default: sense_buffer_size = POST_WIN7_STORVSC_SENSE_BUFFER_SIZE; vmscsi_size_delta = 0; vmstor_current_major = VMSTOR_WIN8_MAJOR; vmstor_current_minor = VMSTOR_WIN8_MINOR; + max_luns_per_target = STORVSC_MAX_LUNS_PER_TARGET; + max_targets = STORVSC_MAX_TARGETS; + max_channels = STORVSC_MAX_CHANNELS; break; } @@ -1848,9 +1857,9 @@ static int storvsc_probe(struct hv_device *device, break; case SCSI_GUID: - host-max_lun = STORVSC_MAX_LUNS_PER_TARGET; - host-max_id = STORVSC_MAX_TARGETS; - host-max_channel = STORVSC_MAX_CHANNELS - 1; + host-max_lun = max_luns_per_target; + host-max_id = max_targets; + host-max_channel = max_channels - 1; break; default: -- 1.7.4.1 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel -- 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: [SCIS] mpt3sas: wait_for_completion_timeout timeout not reported
On 12/30/2014 11:19 AM, Nicholas Mc Guire wrote:
wait_for_completion_timeout reaching timeout was being ignored,
this also should fail if timeout condition occurs.
Thanks to Joe Lawrence joe.lawre...@stratus.com for confirmation.
How about this instead:
Acked-by: Joe Lawrence joe.lawre...@stratus.com
You still probably want a review from the Avago folks though.
BTW, don't worry about the [SCSI] subject prefix to the commit,
[PATCH] is fine. I believe the former is a convention that the
maintainer applies to patches as he collects them to indicate that they
originated via the SCSI tree.
Thanks,
-- Joe
this was only compile tested with
x86_64_defconfig + CONFIG_SCSI_LOWLEVEL=y + CONFIG_SCSI_MPT3SAS=m
patch is against linux-next 3.19.0-rc1 -next-20141226
Signed-off-by: Nicholas Mc Guire der.h...@hofr.at
---
drivers/scsi/mpt3sas/mpt3sas_config.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/scsi/mpt3sas/mpt3sas_config.c
b/drivers/scsi/mpt3sas/mpt3sas_config.c
index 4472c2a..04ff21b 100644
--- a/drivers/scsi/mpt3sas/mpt3sas_config.c
+++ b/drivers/scsi/mpt3sas/mpt3sas_config.c
@@ -393,7 +393,7 @@ _config_request(struct MPT3SAS_ADAPTER *ioc,
Mpi2ConfigRequest_t
mpt3sas_base_put_smid_default(ioc, smid);
timeleft = wait_for_completion_timeout(ioc-config_cmds.done,
timeout*HZ);
- if (!(ioc-config_cmds.status MPT3_CMD_COMPLETE)) {
+ if (timeleft == 0 || !(ioc-config_cmds.status MPT3_CMD_COMPLETE)) {
pr_err(MPT3SAS_FMT %s: timeout\n,
ioc-name, __func__);
_debug_dump_mf(mpi_request,
--
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: Winning Notification !!!
Congratulations!You are among the five lucky winners that won a great sum of Two Million US Dollars in our online raffle draw. reply back to us with your ( Draw No: 10, 15, 20, 22, 26, 36 ) for claims process. -- 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 4/5] ses: add reliable slot attribute
From: Dan Williams dan.j.willi...@intel.com
The name provided by firmware is in a vendor specific format, publish
the slot number to have a reliable mechanism for identifying slots
across firmware implementations. If the enclosure does not provide a
slot number fallback to the component number which is guaranteed unique,
and usually mirrors the slot number.
Cleaned up the unused ses_component.desc in the process.
Signed-off-by: Dan Williams dan.j.willi...@intel.com
Signed-off-by: Song Liu songliubrav...@fb.com
Reviewed-by: Jens Axboe ax...@fb.com
Reviewed-by: Hannes Reinecke h...@suse.de
---
drivers/misc/enclosure.c | 20 +++-
drivers/scsi/ses.c| 17 -
include/linux/enclosure.h | 1 +
3 files changed, 32 insertions(+), 6 deletions(-)
diff --git a/drivers/misc/enclosure.c b/drivers/misc/enclosure.c
index ab4de85..b7995ed 100644
--- a/drivers/misc/enclosure.c
+++ b/drivers/misc/enclosure.c
@@ -145,8 +145,10 @@ enclosure_register(struct device *dev, const char *name,
int components,
if (err)
goto err;
- for (i = 0; i components; i++)
+ for (i = 0; i components; i++) {
edev-component[i].number = -1;
+ edev-component[i].slot = -1;
+ }
mutex_lock(container_list_lock);
list_add_tail(edev-node, container_list);
@@ -589,6 +591,20 @@ static ssize_t get_component_type(struct device *cdev,
return snprintf(buf, 40, %s\n, enclosure_type[ecomp-type]);
}
+static ssize_t get_component_slot(struct device *cdev,
+ struct device_attribute *attr, char *buf)
+{
+ struct enclosure_component *ecomp = to_enclosure_component(cdev);
+ int slot;
+
+ /* if the enclosure does not override then use 'number' as a stand-in */
+ if (ecomp-slot = 0)
+ slot = ecomp-slot;
+ else
+ slot = ecomp-number;
+
+ return snprintf(buf, 40, %d\n, slot);
+}
static DEVICE_ATTR(fault, S_IRUGO | S_IWUSR, get_component_fault,
set_component_fault);
@@ -599,6 +615,7 @@ static DEVICE_ATTR(active, S_IRUGO | S_IWUSR,
get_component_active,
static DEVICE_ATTR(locate, S_IRUGO | S_IWUSR, get_component_locate,
set_component_locate);
static DEVICE_ATTR(type, S_IRUGO, get_component_type, NULL);
+static DEVICE_ATTR(slot, S_IRUGO, get_component_slot, NULL);
static struct attribute *enclosure_component_attrs[] = {
dev_attr_fault.attr,
@@ -606,6 +623,7 @@ static struct attribute *enclosure_component_attrs[] = {
dev_attr_active.attr,
dev_attr_locate.attr,
dev_attr_type.attr,
+ dev_attr_slot.attr,
NULL
};
ATTRIBUTE_GROUPS(enclosure_component);
diff --git a/drivers/scsi/ses.c b/drivers/scsi/ses.c
index 1041556..433de8e 100644
--- a/drivers/scsi/ses.c
+++ b/drivers/scsi/ses.c
@@ -47,7 +47,6 @@ struct ses_device {
struct ses_component {
u64 addr;
- unsigned char *desc;
};
static int ses_probe(struct device *dev)
@@ -307,19 +306,26 @@ static void ses_process_descriptor(struct
enclosure_component *ecomp,
int invalid = desc[0] 0x80;
enum scsi_protocol proto = desc[0] 0x0f;
u64 addr = 0;
+ int slot = -1;
struct ses_component *scomp = ecomp-scratch;
unsigned char *d;
- scomp-desc = desc;
-
if (invalid)
return;
switch (proto) {
+ case SCSI_PROTOCOL_FCP:
+ if (eip) {
+ d = desc + 4;
+ slot = d[3];
+ }
+ break;
case SCSI_PROTOCOL_SAS:
- if (eip)
+ if (eip) {
+ d = desc + 4;
+ slot = d[3];
d = desc + 8;
- else
+ } else
d = desc + 4;
/* only take the phy0 addr */
addr = (u64)d[12] 56 |
@@ -335,6 +341,7 @@ static void ses_process_descriptor(struct
enclosure_component *ecomp,
/* FIXME: Need to add more protocols than just SAS */
break;
}
+ ecomp-slot = slot;
scomp-addr = addr;
}
diff --git a/include/linux/enclosure.h b/include/linux/enclosure.h
index 807622b..0f826c1 100644
--- a/include/linux/enclosure.h
+++ b/include/linux/enclosure.h
@@ -92,6 +92,7 @@ struct enclosure_component {
int fault;
int active;
int locate;
+ int slot;
enum enclosure_status status;
};
--
1.8.1
--
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/5] ses: close potential registration race
From: Dan Williams dan.j.willi...@intel.com
The slot and address fields have a small window of instability when
userspace can read them before initialization. Separate
enclosure_component
allocation from registration.
Signed-off-by: Dan Williams dan.j.willi...@intel.com
Signed-off-by: Song Liu songliubrav...@fb.com
Reviewed-by: Jens Axboe ax...@fb.com
Cc: Hannes Reinecke h...@suse.de
---
drivers/misc/enclosure.c | 35 +--
drivers/scsi/ses.c| 21 ++---
include/linux/enclosure.h | 5 +++--
3 files changed, 42 insertions(+), 19 deletions(-)
diff --git a/drivers/misc/enclosure.c b/drivers/misc/enclosure.c
index 180a544..d566f0f 100644
--- a/drivers/misc/enclosure.c
+++ b/drivers/misc/enclosure.c
@@ -273,23 +273,22 @@ enclosure_component_find_by_name(struct enclosure_device
*edev,
static const struct attribute_group *enclosure_component_groups[];
/**
- * enclosure_component_register - add a particular component to an enclosure
+ * enclosure_component_alloc - prepare a new enclosure component
* @edev: the enclosure to add the component
* @num: the device number
* @type: the type of component being added
* @name: an optional name to appear in sysfs (leave NULL if none)
*
- * Registers the component. The name is optional for enclosures that
- * give their components a unique name. If not, leave the field NULL
- * and a name will be assigned.
+ * The name is optional for enclosures that give their components a unique
+ * name. If not, leave the field NULL and a name will be assigned.
*
* Returns a pointer to the enclosure component or an error.
*/
struct enclosure_component *
-enclosure_component_register(struct enclosure_device *edev,
-unsigned int number,
-enum enclosure_component_type type,
-const char *name)
+enclosure_component_alloc(struct enclosure_device *edev,
+ unsigned int number,
+ enum enclosure_component_type type,
+ const char *name)
{
struct enclosure_component *ecomp;
struct device *cdev;
@@ -327,14 +326,30 @@ enclosure_component_register(struct enclosure_device
*edev,
cdev-release = enclosure_component_release;
cdev-groups = enclosure_component_groups;
+ return ecomp;
+}
+EXPORT_SYMBOL_GPL(enclosure_component_alloc);
+
+/**
+ * enclosure_component_register - publishes an initialized enclosure component
+ * @ecomp: component to add
+ *
+ * Returns 0 on successful registration, releases the component otherwise
+ */
+int enclosure_component_register(struct enclosure_component *ecomp)
+{
+ struct device *cdev;
+ int err;
+
+ cdev = ecomp-cdev;
err = device_register(cdev);
if (err) {
ecomp-number = -1;
put_device(cdev);
- return ERR_PTR(err);
+ return err;
}
- return ecomp;
+ return 0;
}
EXPORT_SYMBOL_GPL(enclosure_component_register);
diff --git a/drivers/scsi/ses.c b/drivers/scsi/ses.c
index b7e79e7..7dd9cf5 100644
--- a/drivers/scsi/ses.c
+++ b/drivers/scsi/ses.c
@@ -423,16 +423,23 @@ static void ses_enclosure_data_process(struct
enclosure_device *edev,
type_ptr[0] == ENCLOSURE_COMPONENT_ARRAY_DEVICE) {
if (create)
- ecomp =
enclosure_component_register(edev,
-
components++,
-
type_ptr[0],
-
name);
+ ecomp = enclosure_component_alloc(
+ edev,
+ components++,
+ type_ptr[0],
+ name);
else
ecomp = edev-component[components++];
- if (!IS_ERR(ecomp) addl_desc_ptr)
- ses_process_descriptor(ecomp,
- addl_desc_ptr);
+ if (!IS_ERR(ecomp)) {
+ if (addl_desc_ptr)
+ ses_process_descriptor(
+ ecomp,
+ addl_desc_ptr);
+ if (create)
+ enclosure_component_register(
+ ecomp);
+
[PATCH 5/5] ses: Add power_status to SES device slot
Add power_status to SES device slot, so we can power on/off the
HDDs behind the enclosure.
Check firmware status in ses_set_* before sending control pages to
firmware.
Signed-off-by: Song Liu songliubrav...@fb.com
Acked-by: Dan Williams dan.j.willi...@intel.com
Reviewed-by: Jens Axboe ax...@fb.com
Cc: Hannes Reinecke h...@suse.de
---
drivers/misc/enclosure.c | 38 ++
drivers/scsi/ses.c| 98 ++-
include/linux/enclosure.h | 6 +++
3 files changed, 133 insertions(+), 9 deletions(-)
diff --git a/drivers/misc/enclosure.c b/drivers/misc/enclosure.c
index b7995ed..3289d4d 100644
--- a/drivers/misc/enclosure.c
+++ b/drivers/misc/enclosure.c
@@ -148,6 +148,7 @@ enclosure_register(struct device *dev, const char *name,
int components,
for (i = 0; i components; i++) {
edev-component[i].number = -1;
edev-component[i].slot = -1;
+ edev-component[i].power_status = 1;
}
mutex_lock(container_list_lock);
@@ -583,6 +584,40 @@ static ssize_t set_component_locate(struct device *cdev,
return count;
}
+static ssize_t get_component_power_status(struct device *cdev,
+ struct device_attribute *attr,
+ char *buf)
+{
+ struct enclosure_device *edev = to_enclosure_device(cdev-parent);
+ struct enclosure_component *ecomp = to_enclosure_component(cdev);
+
+ if (edev-cb-get_power_status)
+ edev-cb-get_power_status(edev, ecomp);
+ return snprintf(buf, 40, %s\n, ecomp-power_status ? on : off);
+}
+
+static ssize_t set_component_power_status(struct device *cdev,
+ struct device_attribute *attr,
+ const char *buf, size_t count)
+{
+ struct enclosure_device *edev = to_enclosure_device(cdev-parent);
+ struct enclosure_component *ecomp = to_enclosure_component(cdev);
+ int val;
+
+ if (strncmp(buf, on, 2) == 0
+ (buf[2] == '\n' || buf[2] == '\0'))
+ val = 1;
+ else if (strncmp(buf, off, 3) == 0
+ (buf[3] == '\n' || buf[3] == '\0'))
+ val = 0;
+ else
+ return -EINVAL;
+
+ if (edev-cb-set_power_status)
+ edev-cb-set_power_status(edev, ecomp, val);
+ return count;
+}
+
static ssize_t get_component_type(struct device *cdev,
struct device_attribute *attr, char *buf)
{
@@ -614,6 +649,8 @@ static DEVICE_ATTR(active, S_IRUGO | S_IWUSR,
get_component_active,
set_component_active);
static DEVICE_ATTR(locate, S_IRUGO | S_IWUSR, get_component_locate,
set_component_locate);
+static DEVICE_ATTR(power_status, S_IRUGO | S_IWUSR, get_component_power_status,
+ set_component_power_status);
static DEVICE_ATTR(type, S_IRUGO, get_component_type, NULL);
static DEVICE_ATTR(slot, S_IRUGO, get_component_slot, NULL);
@@ -622,6 +659,7 @@ static struct attribute *enclosure_component_attrs[] = {
dev_attr_status.attr,
dev_attr_active.attr,
dev_attr_locate.attr,
+ dev_attr_power_status.attr,
dev_attr_type.attr,
dev_attr_slot.attr,
NULL
diff --git a/drivers/scsi/ses.c b/drivers/scsi/ses.c
index 433de8e..dcb0d76 100644
--- a/drivers/scsi/ses.c
+++ b/drivers/scsi/ses.c
@@ -67,6 +67,20 @@ static int ses_probe(struct device *dev)
#define SES_TIMEOUT (30 * HZ)
#define SES_RETRIES 3
+static void init_device_slot_control(unsigned char *dest_desc,
+struct enclosure_component *ecomp,
+unsigned char *status)
+{
+ memcpy(dest_desc, status, 4);
+ dest_desc[0] = 0;
+ /* only clear byte 1 for ENCLOSURE_COMPONENT_DEVICE */
+ if (ecomp-type == ENCLOSURE_COMPONENT_DEVICE)
+ dest_desc[1] = 0;
+ dest_desc[2] = 0xde;
+ dest_desc[3] = 0x3c;
+}
+
+
static int ses_recv_diag(struct scsi_device *sdev, int page_code,
void *buf, int bufflen)
{
@@ -178,14 +192,22 @@ static int ses_set_fault(struct enclosure_device *edev,
struct enclosure_component *ecomp,
enum enclosure_component_setting val)
{
- unsigned char desc[4] = {0 };
+ unsigned char desc[4];
+ unsigned char *desc_ptr;
+
+ desc_ptr = ses_get_page2_descriptor(edev, ecomp);
+
+ if (!desc_ptr)
+ return -EIO;
+
+ init_device_slot_control(desc, ecomp, desc_ptr);
switch (val) {
case ENCLOSURE_SETTING_DISABLED:
- /* zero is disabled */
+ desc[3] = 0xdf;
break;
case ENCLOSURE_SETTING_ENABLED:
- desc[3] = 0x20;
+ desc[3] |= 0x20;
break;
default:
[PATCH 0/5] Feature enhancements for ses module
1: close potential race condition by at enclosure race condition 2,3,4: add enclosure id and device slot, so we can create symlink in /dev/disk/by-slot: # ls -d /dev/disk/by-slot/* /dev/disk/by-slot/enclosure-0x5000ae41fc1310ff-slot0 5: add ability to power on/off device with power_status file in sysfs. Due to the complexity of SES standard, the module is not to replace implement \ all features of sg_ses (sg3_utils). Patch 5 and existing features for device element and array device elements control \ of HDDs. It is helpful to handle some HDD related fields in the kernel, as the \ kernel can generate mapping between a device to the SES device element (or array \ device element): /sys/block/sdc/device/enclosure_deviceXXX/ With patch 5, we can easily power off a running HDD by echo off /sys/block/sdc/device/enclosure_deviceXXX/power_status This is very useful for systems like Cold Storage, where HDDs are being powered \ on/off frequently Dan Williams (4): ses: close potential registration race ses: generate KOBJ_CHANGE on enclosure attach ses: add enclosure logical id ses: add reliable slot attribute Song Liu (1): ses: Add power_status to SES device slot drivers/misc/enclosure.c | 106 + drivers/scsi/ses.c| 148 +++--- include/linux/enclosure.h | 13 +++- 3 files changed, 232 insertions(+), 35 deletions(-) -- 1.8.1 -- 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 3/5] ses: add enclosure logical id
From: Dan Williams dan.j.willi...@intel.com
Export the NAA logical id for the enclosure. This is optionally
available from the sas_transport_class, but it is really a property of
the enclosure.
Signed-off-by: Dan Williams dan.j.willi...@intel.com
Signed-off-by: Song Liu songliubrav...@fb.com
Reviewed-by: Jens Axboe ax...@fb.com
Cc: Hannes Reinecke h...@suse.de
---
drivers/misc/enclosure.c | 13 +
drivers/scsi/ses.c| 9 +
include/linux/enclosure.h | 1 +
3 files changed, 23 insertions(+)
diff --git a/drivers/misc/enclosure.c b/drivers/misc/enclosure.c
index d566f0f..ab4de85 100644
--- a/drivers/misc/enclosure.c
+++ b/drivers/misc/enclosure.c
@@ -432,8 +432,21 @@ static ssize_t components_show(struct device *cdev,
}
static DEVICE_ATTR_RO(components);
+static ssize_t id_show(struct device *cdev,
+struct device_attribute *attr,
+char *buf)
+{
+ struct enclosure_device *edev = to_enclosure_device(cdev);
+
+ if (edev-cb-show_id)
+ return edev-cb-show_id(edev, buf);
+ return -EINVAL;
+}
+static DEVICE_ATTR_RO(id);
+
static struct attribute *enclosure_class_attrs[] = {
dev_attr_components.attr,
+ dev_attr_id.attr,
NULL,
};
ATTRIBUTE_GROUPS(enclosure_class);
diff --git a/drivers/scsi/ses.c b/drivers/scsi/ses.c
index 6662b0c..1041556 100644
--- a/drivers/scsi/ses.c
+++ b/drivers/scsi/ses.c
@@ -258,6 +258,14 @@ static int ses_set_active(struct enclosure_device *edev,
return ses_set_page2_descriptor(edev, ecomp, desc);
}
+static int ses_show_id(struct enclosure_device *edev, char *buf)
+{
+ struct ses_device *ses_dev = edev-scratch;
+ unsigned long long id = get_unaligned_be64(ses_dev-page1+8+4);
+
+ return sprintf(buf, %#llx\n, id);
+}
+
static struct enclosure_component_callbacks ses_enclosure_callbacks = {
.get_fault = ses_get_fault,
.set_fault = ses_set_fault,
@@ -265,6 +273,7 @@ static struct enclosure_component_callbacks
ses_enclosure_callbacks = {
.get_locate = ses_get_locate,
.set_locate = ses_set_locate,
.set_active = ses_set_active,
+ .show_id= ses_show_id,
};
struct ses_host_edev {
diff --git a/include/linux/enclosure.h b/include/linux/enclosure.h
index a835d33..807622b 100644
--- a/include/linux/enclosure.h
+++ b/include/linux/enclosure.h
@@ -79,6 +79,7 @@ struct enclosure_component_callbacks {
int (*set_locate)(struct enclosure_device *,
struct enclosure_component *,
enum enclosure_component_setting);
+ int (*show_id)(struct enclosure_device *, char *buf);
};
--
1.8.1
--
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 2/5] ses: generate KOBJ_CHANGE on enclosure attach
From: Dan Williams dan.j.willi...@intel.com In support of a /dev/disk/by-slot populated with data from the enclosure and ses modules udev needs notification when the new interface files/links are available. Otherwise, any udev rules specified for the disk cannot assume that the enclosure topology has settled. Signed-off-by: Dan Williams dan.j.willi...@intel.com Signed-off-by: Song Liu songliubrav...@fb.com Reviewed-by: Jens Axboe ax...@fb.com Reviewed-by: Hannes Reinecke h...@suse.de --- drivers/scsi/ses.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/scsi/ses.c b/drivers/scsi/ses.c index 7dd9cf5..6662b0c 100644 --- a/drivers/scsi/ses.c +++ b/drivers/scsi/ses.c @@ -349,7 +349,8 @@ static int ses_enclosure_find_by_addr(struct enclosure_device *edev, if (scomp-addr != efd-addr) continue; - enclosure_add_device(edev, i, efd-dev); + if (enclosure_add_device(edev, i, efd-dev) == 0) + kobject_uevent(efd-dev-kobj, KOBJ_CHANGE); return 1; } return 0; -- 1.8.1 -- 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 RESEND 0/5] Feature enhancements for ses module
Hi Christoph, I just send the patches (http://marc.info/?l=linux-scsim=141997962124647w=2). Thanks, Song -Original Message- From: Christoph Hellwig [mailto:h...@infradead.org] Sent: Tuesday, December 30, 2014 4:45 AM To: Song Liu Cc: linux-scsi@vger.kernel.org; Dan Williams; Hannes Reinecke; Jens Axboe; dgilb...@interlog.com; Christoph Hellwig Subject: Re: [PATCH RESEND 0/5] Feature enhancements for ses module This series fails to apply for me, most likely due to whitespace corruption. Can you resend it usign git-send-email, please? Also please replace the SES: prefix with ses:, thanks! -- 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
