Question: request tag usage
Hi Christoph, as discussed it would make sense to use the request-tag in eg scmd_printk() to identify the command. Which I duly did, only to figure out that the tag is always '-1', ie tagging is not in use. (Which is okay from the SCSI side, seeing the TCQ is basically a SCSI parallel thing). Looking closer I found plenty of code for handling tags in the block layer (and the blk-mq stuff, of course), but virtually none of the non-SPI driver seems to be using them. Which makes the original idea a bit pointless, seeing that we need to identify the command _always_, and not just if the host happens to support tagging. Which leads me to some questions: - Is the stuff in blk-mq supposed to work as a superset of SCSI TCQ? - If so, should any HBAs with a queue depth 1 (which does not support TCQ) set the tag of a command? (that's what I've initially thought would happen ...) - If not (and the -tag field is basically unused), can't we have the HBA to fill in a value here? What I would like to see is to have the '-tag' field as an identification for the commands in flight. IE every HBA with a queue depth 1 should be setting the tags. Which apparently was too much to hope for ... 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
Re: next-20140925 build: 1 failures 106 warnings (next-20140925)
Hi Mark, Can you please let me known whether you are observing these warning messages even after inclusion of below patch http://git.infradead.org/users/hch/scsi-queue.git/commitdiff/f78f694c34ae6fdc29f5e80abb2dbb894f961772 Regards, Sreekanth On Thu, Sep 25, 2014 at 9:16 PM, Christoph Hellwig h...@infradead.org wrote: On Thu, Sep 25, 2014 at 04:31:20PM +0100, Mark Brown wrote: On Thu, Sep 25, 2014 at 01:13:56PM +0100, Build bot for Mark Brown wrote: arm-allmodconfig ERROR: __aeabi_uldivmod [drivers/scsi/mpt2sas/mpt2sas.ko] undefined! Today's ARM allmodconfig fails to build due to a call to a GCC intrinsic being emitted from the mpt2sas module - I've not made any effort to investigate this myself yet, unfortunately there's been a build error in this configuration for arch/arm for the past week or so which means that the error may not have been introduced today. http://git.infradead.org/users/hch/scsi-queue.git/commitdiff/f78f694c34ae6fdc29f5e80abb2dbb894f961772 I just need James to pull the latests scsi-queue tree changes.. -- 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
[Bug 81861] Oops by mvsas v0.8.16: sas: ataX: end_device-Y:0:Z: dev error handler - general protection fault, RIP: mvs_task_prep_ata+0x80/0x3a0
https://bugzilla.kernel.org/show_bug.cgi?id=81861
Leon Woestenberg sidebranch.li...@gmail.com changed:
What|Removed |Added
CC||sidebranch.li...@gmail.com
--- Comment #17 from Leon Woestenberg sidebranch.li...@gmail.com ---
With TXQ_PHY_SHIFT being 12, and TXQ_CMD_SHIFT being 29, it seems the PHY
one-bit-hot coding appears in bits 12 through 28 inclusive.
I.e. 16 bits or PHY ID's are supported.
The register transmitted to the controller seems a 32-bit fixed register, so
this seems a hardware limitation rather than software driver limitation.
469del_q = TXQ_MODE_I | tag |
470(TXQ_CMD_STP TXQ_CMD_SHIFT) |
471(MVS_PHY_ID TXQ_PHY_SHIFT) |
472(mvi_dev-taskfileset TXQ_SRS_SHIFT);
printk(%d, mvi-tx_prod]);
473mvi-tx[mvi-tx_prod] = cpu_to_le32(del_q);
Remaining question: how is this supposed to fly with port expanders where PHY
ID's get 16?
Thanks to an extensive debug report by e-mail from Rob Elliott (HP Server
Storage) --- thanks! --- which I copied ad verbatim:
---
1. Although MVS_PHY_ID looks like a constant, it's really not:
#define MVS_PHY_ID (1U sas_phy-id)
2. This fault:
[ 32.271218] BUG: unable to handle kernel NULL pointer dereference at
0255
(although 255 looks like a decimal number 0xff, it's really hex 0x255)
at this line:
0xa01c481e +1838:mov0x254(%rbx),%ecx
implies that rbx contains 1, so 0x254 + 1 = 0x255.
3. pahole drivers/scsi/mvsas/mv_sas.o
shows there are two structures with fields at offset 596:
* asd_sas_phy.id
* asd_sas_port.sas_addr[8]
4. objdump -drS drivers/scsi/mvsas/mv_sas.o
shows only a few lines with 0x254(%something), one of which
is the del_q line you've identified:
mvs_task_prep_ata(struct mvs_info *mvi, struct mvs_task_exec_info *tei):
struct sas_ha_struct *sha = mvi-sas;
struct sas_task *task = tei-task;
struct domain_device *dev = task-dev;
struct sas_phy *sphy = dev-phy;
struct asd_sas_phy *sas_phy = sha-sas_phy[sphy-number];
...
del_q = TXQ_MODE_I | tag |
(TXQ_CMD_STP TXQ_CMD_SHIFT) |
(MVS_PHY_ID TXQ_PHY_SHIFT) |
(mvi_dev-taskfileset TXQ_SRS_SHIFT);
mvi-tx[mvi-tx_prod] = cpu_to_le32(del_q);
MVS_PHY_ID =
sas_phy-id =
sha-sas_phy[sphy-number] =
mvi-sas-sas_phy[dev-phy-number] =
mvi-sas-sas_phy[task-dev-phy-number]-id
mvi-sas-sas_phy[tei-task-dev-phy-number]-id
Looking at the offsets reported by pahole, that means:
%rdi-56-344[%rsi-0-0-56-688]-254
mvi-sas-sas_phy is a pointer to a pointer:
struct sas_ha_struct {
...
struct asd_sas_phy * * sas_phy; /* 344 8 */
You might look for somewhere that could accidentally
be setting sas_phy[something] to a for loop index,
with a typecast hiding the problem from the compiler.
Or, the phy-number value being passed might be
out of range; if there were discovery errors, something
might not have been initialized like this function expects.
Rob ElliottHP Server Storage
---
--
You are receiving this mail because:
You are watching the assignee of the bug.
--
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: Question: request tag usage
On Fri, Sep 26, 2014 at 08:29:29AM +0200, Hannes Reinecke wrote: Hi Christoph, as discussed it would make sense to use the request-tag in eg scmd_printk() to identify the command. Which I duly did, only to figure out that the tag is always '-1', ie tagging is not in use. (Which is okay from the SCSI side, seeing the TCQ is basically a SCSI parallel thing). tag are still a live part of SAM for every transport, they've only been renamed to command identifier in SAM-4 to confuse everyone. Looking closer I found plenty of code for handling tags in the block layer (and the blk-mq stuff, of course), but virtually none of the non-SPI driver seems to be using them. A quick grep for scsi_activate_tcq disagrees with you. Which makes the original idea a bit pointless, seeing that we need to identify the command _always_, and not just if the host happens to support tagging. Which leads me to some questions: - Is the stuff in blk-mq supposed to work as a superset of SCSI TCQ? Yes. - If so, should any HBAs with a queue depth 1 (which does not support TCQ) set the tag of a command? (that's what I've initially thought would happen ...) - If not (and the -tag field is basically unused), can't we have the HBA to fill in a value here? blk-mq will always provide, and does rely on a valid request-tag. A LLDD can still use it's own internal tagging or mess with scmd-tag, although in general it should benefit from using the block layer tagging. Which apparently was too much to hope for ... I guess for now we'll need to stay with the command pointer address. We can revisit this once the old request layer is gone. -- 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 0/1] Error are logged when application issues illegal request
On Thu, Sep 25, 2014 at 02:05:14PM -0500, wenxi...@linux.vnet.ibm.com wrote: Hi Christoph, Sorry! This patch includes the fix in ipr.h. I built this patch in the latest scsi tree. I've insted just applied the typo fix as I didn't want to rebase. Can you cross check: http://git.infradead.org/users/hch/scsi-queue.git/shortlog/refs/heads/drivers-for-3.18 for me please? -- 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 V6 01/18] scsi: fixing the type for well known LUs
Robert, I guess this version is okay with you?
On Thu, Sep 25, 2014 at 03:32:19PM +0300, Dolev Raviv wrote:
From: Subhash Jadavani subha...@codeaurora.org
Some devices may respond with wrong type for well-known logical units.
This patch forces well-known type for devices which doesn't report it
correct.
Signed-off-by: Subhash Jadavani subha...@codeaurora.org
Signed-off-by: Sujit Reddy Thumma sthu...@codeaurora.org
Signed-off-by: Dolev Raviv dra...@codeaurora.org
diff --git a/drivers/scsi/scsi_scan.c b/drivers/scsi/scsi_scan.c
index 56675db..1095d5a 100644
--- a/drivers/scsi/scsi_scan.c
+++ b/drivers/scsi/scsi_scan.c
@@ -805,6 +805,19 @@ static int scsi_add_lun(struct scsi_device *sdev,
unsigned char *inq_result,
} else {
sdev-type = (inq_result[0] 0x1f);
sdev-removable = (inq_result[1] 0x80) 7;
+
+ /*
+ * some devices may respond with wrong type for
+ * well-known logical units. Force well-known type
+ * to enumerate them correctly.
+ */
+ if (scsi_is_wlun(sdev-lun) sdev-type != TYPE_WLUN) {
+ sdev_printk(KERN_WARNING, sdev,
+ %s: correcting incorrect peripheral device
type 0x%x for W-LUN 0x%16phN\n,
+ __func__, sdev-type, sdev-lun);
+ sdev-type = TYPE_WLUN;
+ }
+
}
if (sdev-type == TYPE_RBC || sdev-type == TYPE_ROM) {
diff --git a/include/scsi/scsi.h b/include/scsi/scsi.h
index 261e708..d17178e 100644
--- a/include/scsi/scsi.h
+++ b/include/scsi/scsi.h
@@ -333,6 +333,7 @@ static inline int scsi_status_is_good(int status)
#define TYPE_RBC 0x0e
#define TYPE_OSD0x11
#define TYPE_ZBC0x14
+#define TYPE_WLUN 0x1e/* well-known logical unit */
#define TYPE_NO_LUN 0x7f
/* SCSI protocols; these are taken from SPC-3 section 7.5 */
--
1.8.5.2
--
QUALCOMM ISRAEL, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation
--
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
---end quoted text---
--
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 V6 02/18] scsi: sysfs: don't add scsi_device if its already added
Looks fine to me, just want a cross check from Martin or Hannes. On Thu, Sep 25, 2014 at 03:32:20PM +0300, Dolev Raviv wrote: From: Subhash Jadavani subha...@codeaurora.org If LLD has added scsi device (by calling scsi_add_device) before scheduling async scsi_scan_host then scsi_finish_async_scan() will end up calling scsi_sysfs_add_sdev for scsi device which was already added by LLD. This patch fixes this issue by skipping the call to scsi_sysfs_add_sdev() if it's already visible to rest of the kernel. Signed-off-by: Subhash Jadavani subha...@codeaurora.org Signed-off-by: Dolev Raviv dra...@codeaurora.org diff --git a/drivers/scsi/scsi_scan.c b/drivers/scsi/scsi_scan.c index 1095d5a..c6c5716 100644 --- a/drivers/scsi/scsi_scan.c +++ b/drivers/scsi/scsi_scan.c @@ -1746,6 +1746,9 @@ static void scsi_sysfs_add_devices(struct Scsi_Host *shost) /* target removed before the device could be added */ if (sdev-sdev_state == SDEV_DEL) continue; + /* If device is already visible, skip adding it to sysfs */ + if (sdev-is_visible) + continue; if (!scsi_host_scan_allowed(shost) || scsi_sysfs_add_sdev(sdev) != 0) __scsi_remove_device(sdev); -- 1.8.5.2 -- QUALCOMM ISRAEL, on behalf of Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation -- 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 ---end quoted text--- -- 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: Question: request tag usage
On 09/26/2014 10:03 AM, Christoph Hellwig wrote: On Fri, Sep 26, 2014 at 08:29:29AM +0200, Hannes Reinecke wrote: Hi Christoph, as discussed it would make sense to use the request-tag in eg scmd_printk() to identify the command. Which I duly did, only to figure out that the tag is always '-1', ie tagging is not in use. (Which is okay from the SCSI side, seeing the TCQ is basically a SCSI parallel thing). tag are still a live part of SAM for every transport, they've only been renamed to command identifier in SAM-4 to confuse everyone. Looking closer I found plenty of code for handling tags in the block layer (and the blk-mq stuff, of course), but virtually none of the non-SPI driver seems to be using them. A quick grep for scsi_activate_tcq disagrees with you. Yeah, I've noticed after I've written the mail. However, main point still stands: using 'tag' to identify commands is pointless if not all of the LLDDs use tagging ... Which makes the original idea a bit pointless, seeing that we need to identify the command _always_, and not just if the host happens to support tagging. Which leads me to some questions: - Is the stuff in blk-mq supposed to work as a superset of SCSI TCQ? Yes. - If so, should any HBAs with a queue depth 1 (which does not support TCQ) set the tag of a command? (that's what I've initially thought would happen ...) - If not (and the -tag field is basically unused), can't we have the HBA to fill in a value here? blk-mq will always provide, and does rely on a valid request-tag. A LLDD can still use it's own internal tagging or mess with scmd-tag, although in general it should benefit from using the block layer tagging. I know. But I was asking about non-mq LLDDs. Which apparently was too much to hope for ... I guess for now we'll need to stay with the command pointer address. We can revisit this once the old request layer is gone. Too bad. The tags would have provided a really nice concise way of identifying the command... 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
[Bug 85151] pm80xx + 7805H + HP SAS port expander = mpi_smp_completion 2604:smp IO status 0x2 and sas: expander ... discovery failed(0xffffffa6)
https://bugzilla.kernel.org/show_bug.cgi?id=85151 --- Comment #7 from Jack Wang xjtu...@gmail.com --- Cc pmchba maillist. 2014-09-25 18:20 GMT+02:00 bugzilla-dae...@bugzilla.kernel.org: https://bugzilla.kernel.org/show_bug.cgi?id=85151 --- Comment #6 from Jack Wang xjtu...@gmail.com --- Ah, I forgot no bsg node if expander discover failed:( HBA SAS address is 0, does not matter. From my point, this bug clear SMP protocol related, you could report to PMC, I think they will offer help. -- You are receiving this mail because: You are watching the assignee of the bug. -- 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 -- You are receiving this mail because: You are watching the assignee of the bug. -- 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: [Bug 85151] pm80xx + 7805H + HP SAS port expander = mpi_smp_completion 2604:smp IO status 0x2 and sas: expander ... discovery failed(0xffffffa6)
Cc pmchba maillist. 2014-09-25 18:20 GMT+02:00 bugzilla-dae...@bugzilla.kernel.org: https://bugzilla.kernel.org/show_bug.cgi?id=85151 --- Comment #6 from Jack Wang xjtu...@gmail.com --- Ah, I forgot no bsg node if expander discover failed:( HBA SAS address is 0, does not matter. From my point, this bug clear SMP protocol related, you could report to PMC, I think they will offer help. -- You are receiving this mail because: You are watching the assignee of the bug. -- 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
[PATCH 2/2] be2iscsi : Bump the driver version
Bump the driver version Signed-off-by: John Soni Jose sony.joh...@emulex.com Signed-off-by: Jayamohan Kallickal jayamohan.kallic...@emulex.com --- drivers/scsi/be2iscsi/be_main.h |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/scsi/be2iscsi/be_main.h b/drivers/scsi/be2iscsi/be_main.h index 3605631..7ee0ffc 100644 --- a/drivers/scsi/be2iscsi/be_main.h +++ b/drivers/scsi/be2iscsi/be_main.h @@ -36,7 +36,7 @@ #include scsi/scsi_transport_iscsi.h #define DRV_NAME be2iscsi -#define BUILD_STR 10.4.74.0 +#define BUILD_STR 10.4.114.0 #define BE_NAMEEmulex OneConnect \ Open-iSCSI Driver version BUILD_STR #define DRV_DESC BE_NAME Driver -- 1.7.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/2] be2iscsi : Fix kernel panic during reboot/shutdown
In the reboot/shutdown path, workqueue was destroyed after the
adapter resource were freed. The task associated with workqueue
was getting executed after resources were freed. This lead to
kernel panic.
Signed-off-by: John Soni Jose sony.joh...@emulex.com
Signed-off-by: Jayamohan Kallickal jayamohan.kallic...@emulex.com
---
drivers/scsi/be2iscsi/be_main.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/scsi/be2iscsi/be_main.c b/drivers/scsi/be2iscsi/be_main.c
index db2bd4d..30d74a0 100644
--- a/drivers/scsi/be2iscsi/be_main.c
+++ b/drivers/scsi/be2iscsi/be_main.c
@@ -5223,6 +5223,7 @@ static void beiscsi_quiesce(struct beiscsi_hba *phba,
free_irq(phba-pcidev-irq, phba);
}
pci_disable_msix(phba-pcidev);
+ cancel_delayed_work_sync(phba-beiscsi_hw_check_task);
for (i = 0; i phba-num_cpus; i++) {
pbe_eq = phwi_context-be_eq[i];
@@ -5244,7 +5245,6 @@ static void beiscsi_quiesce(struct beiscsi_hba *phba,
hwi_cleanup(phba);
}
- cancel_delayed_work_sync(phba-beiscsi_hw_check_task);
}
static void beiscsi_remove(struct pci_dev *pcidev)
--
1.7.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: Question: request tag usage
On Fri, 2014-09-26 at 10:20 +0200, Hannes Reinecke wrote: On 09/26/2014 10:03 AM, Christoph Hellwig wrote: On Fri, Sep 26, 2014 at 08:29:29AM +0200, Hannes Reinecke wrote: Hi Christoph, as discussed it would make sense to use the request-tag in eg scmd_printk() to identify the command. Which I duly did, only to figure out that the tag is always '-1', ie tagging is not in use. (Which is okay from the SCSI side, seeing the TCQ is basically a SCSI parallel thing). tag are still a live part of SAM for every transport, they've only been renamed to command identifier in SAM-4 to confuse everyone. Looking closer I found plenty of code for handling tags in the block layer (and the blk-mq stuff, of course), but virtually none of the non-SPI driver seems to be using them. A quick grep for scsi_activate_tcq disagrees with you. Yeah, I've noticed after I've written the mail. However, main point still stands: using 'tag' to identify commands is pointless if not all of the LLDDs use tagging ... Every non parallel LLD uses tagging; they all use the network request response model, so they can no longer hold the bus until they get an answer (which was how untagged commands work in SPI), so for most of the transports, untagged commands aren't legal. Of course, some drivers roll their own tags instead of using the block ones. 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
[Bug 85151] pm80xx + 7805H + HP SAS port expander = mpi_smp_completion 2604:smp IO status 0x2 and sas: expander ... discovery failed(0xffffffa6)
https://bugzilla.kernel.org/show_bug.cgi?id=85151 --- Comment #9 from linux-...@crashplan.pro --- Even with latest HP SAS expander firmware version 2.10 (CP022989, Sep 9th 2014, PUF21000.bin e898facebe75c180c0a9e7d521d0285a), no drives attached, only the 7805H with one cable SFF-8643 to SFF-8088 (0.5 meter in length) to the external (1C,PORT1C) of the expander, there are these failure messages: [ 117.805044] sas: DOING DISCOVERY on port 0, pid:134 [ 117.807859] pm80xx mpi_smp_completion 2604:smp IO status 0x2 [ 117.808354] sas: expander 5001438018c7ed26 discovery failed(0xffa6) [ 117.809010] sas: DONE DISCOVERY on port 0, pid:134, result:-90 [ 117.809878] sas: DOING DISCOVERY on port 1, pid:134 [ 117.810706] sas: smp_execute_task: task to dev 5001438018c7ed26 response: 0x status 0x8a [ 117.811277] sas: smp_execute_task: task to dev 5001438018c7ed26 response: 0x status 0x8a [ 117.811891] sas: smp_execute_task: task to dev 5001438018c7ed26 response: 0x status 0x8a [ 117.812443] sas: RG to ex 5001438018c7ed26 failed:0xffba [ 117.813380] sas: DONE DISCOVERY on port 1, pid:134, result:-70 [ 117.814045] sas: DOING DISCOVERY on port 2, pid:134 [ 117.814966] sas: smp_execute_task: task to dev 5001438018c7ed26 response: 0x status 0x8a [ 117.815649] sas: smp_execute_task: task to dev 5001438018c7ed26 response: 0x status 0x8a [ 117.816361] sas: smp_execute_task: task to dev 5001438018c7ed26 response: 0x status 0x8a [ 117.817032] sas: RG to ex 5001438018c7ed26 failed:0xffba [ 117.817804] sas: DONE DISCOVERY on port 2, pid:134, result:-70 [ 117.818335] sas: DOING DISCOVERY on port 3, pid:134 [ 117.819051] sas: smp_execute_task: task to dev 5001438018c7ed26 response: 0x status 0x8a [ 117.819646] sas: smp_execute_task: task to dev 5001438018c7ed26 response: 0x status 0x8a [ 117.820414] sas: smp_execute_task: task to dev 5001438018c7ed26 response: 0x status 0x8a [ 117.820964] sas: RG to ex 5001438018c7ed26 failed:0xffba [ 117.821709] sas: DONE DISCOVERY on port 3, pid:134, result:-70 -- You are receiving this mail because: You are watching the assignee of the bug. -- 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] be2iscsi : Update to 10.4.114.0
This patchset updates be2iscsi driver to 10.4.114.0 These patches are based on for-next branch of scsi.git. John Soni Jose (2): be2iscsi : Fix kernel panic during reboot/shutdown be2iscsi : Bump the driver version drivers/scsi/be2iscsi/be_main.c |2 +- drivers/scsi/be2iscsi/be_main.h |2 +- 2 files changed, 2 insertions(+), 2 deletions(-) -- 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/8] scsi-mq: Add support for multiple hardware queues
On Sat, Sep 20, 2014 at 2:05 AM, Sagi Grimberg sa...@dev.mellanox.co.il wrote:
On 9/19/2014 3:57 PM, Bart Van Assche wrote:
Allow a SCSI LLD to declare how many hardware queues it supports
by setting Scsi_Host.nr_hw_queues before calling scsi_add_host().
Note: it is assumed that each hardware queue has a queue depth of
shost-can_queue. In other words, the total queue depth per host
is (number of hardware queues) * (shost-can_queue).
Signed-off-by: Bart Van Assche bvanass...@acm.org
Cc: Christoph Hellwig h...@lst.de
---
drivers/scsi/scsi_lib.c | 2 +-
include/scsi/scsi_host.h | 4
2 files changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c
index d837dc1..b0b6117 100644
--- a/drivers/scsi/scsi_lib.c
+++ b/drivers/scsi/scsi_lib.c
@@ -2071,7 +2071,7 @@ int scsi_mq_setup_tags(struct Scsi_Host *shost)
memset(shost-tag_set, 0, sizeof(shost-tag_set));
shost-tag_set.ops = scsi_mq_ops;
- shost-tag_set.nr_hw_queues = 1;
+ shost-tag_set.nr_hw_queues = shost-nr_hw_queues ? : 1;
shost-tag_set.queue_depth = shost-can_queue;
shost-tag_set.cmd_size = cmd_size;
shost-tag_set.numa_node = NUMA_NO_NODE;
diff --git a/include/scsi/scsi_host.h b/include/scsi/scsi_host.h
index ba20347..0a867d9 100644
--- a/include/scsi/scsi_host.h
+++ b/include/scsi/scsi_host.h
@@ -638,6 +638,10 @@ struct Scsi_Host {
short unsigned int sg_prot_tablesize;
unsigned int max_sectors;
unsigned long dma_boundary;
+ /*
+ * In scsi-mq mode, the number of hardware queues supported by the LLD.
+ */
+ unsigned nr_hw_queues;
/*
* Used to assign serial numbers to the cmds.
* Protected by the host lock.
I think this patch should be squashed with passing LLD hctx patch (in
whatever form it ends up).
I suggest to apply this patch and related scsi-mq multi hw-queue
enablement patches first, so that any scsi drivers capable of
multi hw-queue can go without waiting for passing hctx
patches which may take a bit long since lots of drivers are involved,
as Jens said, the mapping from req to hctx is quite cheap.
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: Question: request tag usage
On 09/26/2014 12:12 PM, James Bottomley wrote:
On Fri, 2014-09-26 at 10:20 +0200, Hannes Reinecke wrote:
On 09/26/2014 10:03 AM, Christoph Hellwig wrote:
On Fri, Sep 26, 2014 at 08:29:29AM +0200, Hannes Reinecke wrote:
Hi Christoph,
as discussed it would make sense to use the request-tag in eg
scmd_printk() to identify the command.
Which I duly did, only to figure out that the tag is always '-1', ie
tagging is not in use.
(Which is okay from the SCSI side, seeing the TCQ is basically a
SCSI parallel thing).
tag are still a live part of SAM for every transport, they've only
been renamed to command identifier in SAM-4 to confuse everyone.
Looking closer I found plenty of code for handling tags in the block
layer (and the blk-mq stuff, of course), but virtually none of the
non-SPI driver seems to be using them.
A quick grep for scsi_activate_tcq disagrees with you.
Yeah, I've noticed after I've written the mail.
However, main point still stands: using 'tag' to identify commands
is pointless if not all of the LLDDs use tagging ...
Every non parallel LLD uses tagging; they all use the network request
response model, so they can no longer hold the bus until they get an
answer (which was how untagged commands work in SPI), so for most of the
transports, untagged commands aren't legal. Of course, some drivers
roll their own tags instead of using the block ones.
Hmm, I probably will get shot for this, but we _could_ do something
like this:
diff --git a/block/blk-core.c b/block/blk-core.c
index bf930f4..91570d2 100644
--- a/block/blk-core.c
+++ b/block/blk-core.c
@@ -2347,7 +2347,8 @@ void blk_start_request(struct request *req)
req-resid_len = blk_rq_bytes(req);
if (unlikely(blk_bidi_rq(req)))
req-next_rq-resid_len = blk_rq_bytes(req-next_rq);
-
+ if (!blk_queue_tagged(req-q))
+ req-tag = (++req-q-last_tag) % req-q-nr_requests;
BUG_ON(test_bit(REQ_ATOM_COMPLETE, req-atomic_flags));
blk_add_timer(req);
}
diff --git a/include/linux/blkdev.h b/include/linux/blkdev.h
index 518b465..e8ce575 100644
--- a/include/linux/blkdev.h
+++ b/include/linux/blkdev.h
@@ -418,6 +418,7 @@ struct request_queue {
struct blk_queue_tag*queue_tags;
struct list_headtag_busy_list;
+ unsigned intlast_tag;
unsigned intnr_sorted;
unsigned intin_flight[2];
I know, I know. But it would give us a rather nice command identifier.
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
Re: [PATCH V6 02/18] scsi: sysfs: don't add scsi_device if its already added
On 09/26/2014 10:14 AM, Christoph Hellwig wrote: Looks fine to me, just want a cross check from Martin or Hannes. On Thu, Sep 25, 2014 at 03:32:20PM +0300, Dolev Raviv wrote: From: Subhash Jadavani subha...@codeaurora.org If LLD has added scsi device (by calling scsi_add_device) before scheduling async scsi_scan_host then scsi_finish_async_scan() will end up calling scsi_sysfs_add_sdev for scsi device which was already added by LLD. This patch fixes this issue by skipping the call to scsi_sysfs_add_sdev() if it's already visible to rest of the kernel. Signed-off-by: Subhash Jadavani subha...@codeaurora.org Signed-off-by: Dolev Raviv dra...@codeaurora.org diff --git a/drivers/scsi/scsi_scan.c b/drivers/scsi/scsi_scan.c index 1095d5a..c6c5716 100644 --- a/drivers/scsi/scsi_scan.c +++ b/drivers/scsi/scsi_scan.c @@ -1746,6 +1746,9 @@ static void scsi_sysfs_add_devices(struct Scsi_Host *shost) /* target removed before the device could be added */ if (sdev-sdev_state == SDEV_DEL) continue; +/* If device is already visible, skip adding it to sysfs */ +if (sdev-is_visible) +continue; if (!scsi_host_scan_allowed(shost) || scsi_sysfs_add_sdev(sdev) != 0) __scsi_remove_device(sdev); -- 1.8.5.2 -- QUALCOMM ISRAEL, on behalf of Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation -- 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 ---end quoted text--- -- Looks okay. 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
RE: Question: request tag usage
-Original Message- From: Hannes Reinecke [mailto:h...@suse.de] Sent: Friday, September 26, 2014 3:21 AM To: Christoph Hellwig Cc: Elliott, Robert (Server Storage); SCSI Mailing List; Jens Axboe Subject: Re: Question: request tag usage On 09/26/2014 10:03 AM, Christoph Hellwig wrote: ... I guess for now we'll need to stay with the command pointer address. We can revisit this once the old request layer is gone. Too bad. The tags would have provided a really nice concise way of identifying the command... I would still go ahead and print the tag; it's extremely useful for blk-mq. How about having scmd_printk do this? * if tag is -1, print scmd %p * else print tag %d -- 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/8] scsi-mq: Add support for multiple hardware queues
On 26/09/2014 5:08, Ming Lei wrote: I suggest to apply this patch and related scsi-mq multi hw-queue enablement patches first, so that any scsi drivers capable of multi hw-queue can go without waiting for passing hctx patches which may take a bit long since lots of drivers are involved, as Jens said, the mapping from req to hctx is quite cheap. Hello Ming, This week I have been traveling. I hope to find more time next week or the week after next week to rework this patch series and to address the feedback I have received from you, Jens, Christoph and Sagi. 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
re: qla2xxx: Add FDMI-2 functionality.
Hello Himanshu Madhani,
The patch df57cabac41f: qla2xxx: Add FDMI-2 functionality. from Sep
25, 2014, leads to the following static checker warnings:
drivers/scsi/qla2xxx/qla_gs.c:1339 qla2x00_fdmi_rhba() error: snprintf() chops
off the last chars of 'ha-model_number': 17 vs 16
drivers/scsi/qla2xxx/qla_gs.c:1628 qla2x00_fdmi_rpa() error: snprintf() chops
off the last chars of 'p_sysid-nodename': 65 vs 32
drivers/scsi/qla2xxx/qla_gs.c:1631 qla2x00_fdmi_rpa() error: snprintf() chops
off the last chars of '(((vha-host)-shost_data)-system_hostname)': 256 vs 32
drivers/scsi/qla2xxx/qla_gs.c:1763 qla2x00_fdmiv2_rhba() error: snprintf()
chops off the last chars of 'ha-model_number': 17 vs 16
drivers/scsi/qla2xxx/qla_gs.c:2195 qla2x00_fdmiv2_rpa() error: snprintf() chops
off the last chars of 'p_sysid-nodename': 65 vs 32
drivers/scsi/qla2xxx/qla_gs.c:2198 qla2x00_fdmiv2_rpa() error: snprintf() chops
off the last chars of '(((vha-host)-shost_data)-system_hostname)': 256 vs 32
drivers/scsi/qla2xxx/qla_gs.c
2194 if (p_sysid) {
2195 snprintf(eiter-a.host_name, sizeof(eiter-a.host_name),
2196 %s, p_sysid-nodename);
We're chopping most of the hostname off. That seems bad.
2197 } else {
2198 snprintf(eiter-a.host_name, sizeof(eiter-a.host_name),
2199 %s, fc_host_system_hostname(vha-host));
2200 }
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] xen/xenbus: Use 'void' instead of 'int' for the return of xenbus_switch_state()
When xenbus_switch_state() fails, it will call xenbus_switch_fatal()
internally, so need not return any status value, then use 'void' instead
of 'int' for xenbus_switch_state() and __xenbus_switch_state().
Also need be sure that all callers which check the return value must let
'err' be 0.
And also need change the related comments for xenbus_switch_state().
Signed-off-by: Chen Gang gang.chen.5...@gmail.com
---
drivers/block/xen-blkback/xenbus.c | 9 ++---
drivers/net/xen-netback/xenbus.c | 5 +
drivers/pci/xen-pcifront.c | 15 ++-
drivers/xen/xen-pciback/xenbus.c | 21 -
drivers/xen/xen-scsiback.c | 5 +
drivers/xen/xenbus/xenbus_client.c | 16
include/xen/xenbus.h | 3 ++-
7 files changed, 24 insertions(+), 50 deletions(-)
diff --git a/drivers/block/xen-blkback/xenbus.c
b/drivers/block/xen-blkback/xenbus.c
index 3a8b810..fdcc584 100644
--- a/drivers/block/xen-blkback/xenbus.c
+++ b/drivers/block/xen-blkback/xenbus.c
@@ -587,9 +587,7 @@ static int xen_blkbk_probe(struct xenbus_device *dev,
if (err)
goto fail;
- err = xenbus_switch_state(dev, XenbusStateInitWait);
- if (err)
- goto fail;
+ xenbus_switch_state(dev, XenbusStateInitWait);
return 0;
@@ -837,10 +835,7 @@ again:
if (err)
xenbus_dev_fatal(dev, err, ending transaction);
- err = xenbus_switch_state(dev, XenbusStateConnected);
- if (err)
- xenbus_dev_fatal(dev, err, %s: switching to Connected state,
-dev-nodename);
+ xenbus_switch_state(dev, XenbusStateConnected);
return;
abort:
diff --git a/drivers/net/xen-netback/xenbus.c b/drivers/net/xen-netback/xenbus.c
index 9c47b89..b5c3d47 100644
--- a/drivers/net/xen-netback/xenbus.c
+++ b/drivers/net/xen-netback/xenbus.c
@@ -337,10 +337,7 @@ static int netback_probe(struct xenbus_device *dev,
if (err)
pr_debug(Error writing multi-queue-max-queues\n);
- err = xenbus_switch_state(dev, XenbusStateInitWait);
- if (err)
- goto fail;
-
+ xenbus_switch_state(dev, XenbusStateInitWait);
be-state = XenbusStateInitWait;
/* This kicks hotplug scripts, so do it immediately. */
diff --git a/drivers/pci/xen-pcifront.c b/drivers/pci/xen-pcifront.c
index 53df39a..c1d73b7 100644
--- a/drivers/pci/xen-pcifront.c
+++ b/drivers/pci/xen-pcifront.c
@@ -901,18 +901,16 @@ static int pcifront_try_connect(struct pcifront_device
*pdev)
}
}
- err = xenbus_switch_state(pdev-xdev, XenbusStateConnected);
-
+ xenbus_switch_state(pdev-xdev, XenbusStateConnected);
+ return 0;
out:
return err;
}
static int pcifront_try_disconnect(struct pcifront_device *pdev)
{
- int err = 0;
enum xenbus_state prev_state;
-
prev_state = xenbus_read_driver_state(pdev-xdev-nodename);
if (prev_state = XenbusStateClosing)
@@ -923,11 +921,10 @@ static int pcifront_try_disconnect(struct pcifront_device
*pdev)
pcifront_disconnect(pdev);
}
- err = xenbus_switch_state(pdev-xdev, XenbusStateClosed);
+ xenbus_switch_state(pdev-xdev, XenbusStateClosed);
out:
-
- return err;
+ return 0;
}
static int pcifront_attach_devices(struct pcifront_device *pdev)
@@ -1060,8 +1057,8 @@ static int pcifront_detach_devices(struct pcifront_device
*pdev)
domain, bus, slot, func);
}
- err = xenbus_switch_state(pdev-xdev, XenbusStateReconfiguring);
-
+ xenbus_switch_state(pdev-xdev, XenbusStateReconfiguring);
+ return 0;
out:
return err;
}
diff --git a/drivers/xen/xen-pciback/xenbus.c b/drivers/xen/xen-pciback/xenbus.c
index c214daa..630a215 100644
--- a/drivers/xen/xen-pciback/xenbus.c
+++ b/drivers/xen/xen-pciback/xenbus.c
@@ -184,10 +184,7 @@ static int xen_pcibk_attach(struct xen_pcibk_device *pdev)
dev_dbg(pdev-xdev-dev, Connecting...\n);
- err = xenbus_switch_state(pdev-xdev, XenbusStateConnected);
- if (err)
- xenbus_dev_fatal(pdev-xdev, err,
-Error switching to connected state!);
+ xenbus_switch_state(pdev-xdev, XenbusStateConnected);
dev_dbg(pdev-xdev-dev, Connected? %d\n, err);
out:
@@ -500,12 +497,7 @@ static int xen_pcibk_reconfigure(struct xen_pcibk_device
*pdev)
}
}
- err = xenbus_switch_state(pdev-xdev, XenbusStateReconfigured);
- if (err) {
- xenbus_dev_fatal(pdev-xdev, err,
-Error switching to reconfigured state!);
- goto out;
- }
+ xenbus_switch_state(pdev-xdev, XenbusStateReconfigured);
out:
mutex_unlock(pdev-dev_lock);
@@ -640,10 +632,7 @@ static int xen_pcibk_setup_backend(struct xen_pcibk_device
*pdev)
Re: [Xen-devel] [PATCH] xen/xenbus: Use 'void' instead of 'int' for the return of xenbus_switch_state()
On 26/09/14 17:36, Chen Gang wrote:
When xenbus_switch_state() fails, it will call xenbus_switch_fatal()
internally, so need not return any status value, then use 'void' instead
of 'int' for xenbus_switch_state() and __xenbus_switch_state().
Also need be sure that all callers which check the return value must let
'err' be 0.
I've rewritten the commit message as:
xen/xenbus: don't return errors from xenbus_switch_state()
Most users of xenbus_switch_state() weren't handling the failure of
xenbus_switch_state() correctly. They either called
xenbus_dev_fatal() (which xenbus_switch_state() has effectively
already tried to do), or ignored errors.
xenbus_switch_state() may fail because:
a) The device is being unplugged by the toolstack. The device will
shortly be removed and the error does not need to be handled.
b) Xenstore is broken. There isn't much the driver can do in this
case since xenstore is required to signal failure to the toolstack.
So, don't report any errors from xenbus_switch_state() which removes
some unnecessary error handling in some of the drivers.
I'd appreciate a review from some of the other front/backend driver
maintainers on whether this is sensible reasoning.
David
And also need change the related comments for xenbus_switch_state().
Signed-off-by: Chen Gang gang.chen.5...@gmail.com
---
drivers/block/xen-blkback/xenbus.c | 9 ++---
drivers/net/xen-netback/xenbus.c | 5 +
drivers/pci/xen-pcifront.c | 15 ++-
drivers/xen/xen-pciback/xenbus.c | 21 -
drivers/xen/xen-scsiback.c | 5 +
drivers/xen/xenbus/xenbus_client.c | 16
include/xen/xenbus.h | 3 ++-
7 files changed, 24 insertions(+), 50 deletions(-)
diff --git a/drivers/block/xen-blkback/xenbus.c
b/drivers/block/xen-blkback/xenbus.c
index 3a8b810..fdcc584 100644
--- a/drivers/block/xen-blkback/xenbus.c
+++ b/drivers/block/xen-blkback/xenbus.c
@@ -587,9 +587,7 @@ static int xen_blkbk_probe(struct xenbus_device *dev,
if (err)
goto fail;
- err = xenbus_switch_state(dev, XenbusStateInitWait);
- if (err)
- goto fail;
+ xenbus_switch_state(dev, XenbusStateInitWait);
return 0;
@@ -837,10 +835,7 @@ again:
if (err)
xenbus_dev_fatal(dev, err, ending transaction);
- err = xenbus_switch_state(dev, XenbusStateConnected);
- if (err)
- xenbus_dev_fatal(dev, err, %s: switching to Connected state,
- dev-nodename);
+ xenbus_switch_state(dev, XenbusStateConnected);
return;
abort:
diff --git a/drivers/net/xen-netback/xenbus.c
b/drivers/net/xen-netback/xenbus.c
index 9c47b89..b5c3d47 100644
--- a/drivers/net/xen-netback/xenbus.c
+++ b/drivers/net/xen-netback/xenbus.c
@@ -337,10 +337,7 @@ static int netback_probe(struct xenbus_device *dev,
if (err)
pr_debug(Error writing multi-queue-max-queues\n);
- err = xenbus_switch_state(dev, XenbusStateInitWait);
- if (err)
- goto fail;
-
+ xenbus_switch_state(dev, XenbusStateInitWait);
be-state = XenbusStateInitWait;
/* This kicks hotplug scripts, so do it immediately. */
diff --git a/drivers/pci/xen-pcifront.c b/drivers/pci/xen-pcifront.c
index 53df39a..c1d73b7 100644
--- a/drivers/pci/xen-pcifront.c
+++ b/drivers/pci/xen-pcifront.c
@@ -901,18 +901,16 @@ static int pcifront_try_connect(struct pcifront_device
*pdev)
}
}
- err = xenbus_switch_state(pdev-xdev, XenbusStateConnected);
-
+ xenbus_switch_state(pdev-xdev, XenbusStateConnected);
+ return 0;
out:
return err;
}
static int pcifront_try_disconnect(struct pcifront_device *pdev)
{
- int err = 0;
enum xenbus_state prev_state;
-
prev_state = xenbus_read_driver_state(pdev-xdev-nodename);
if (prev_state = XenbusStateClosing)
@@ -923,11 +921,10 @@ static int pcifront_try_disconnect(struct
pcifront_device *pdev)
pcifront_disconnect(pdev);
}
- err = xenbus_switch_state(pdev-xdev, XenbusStateClosed);
+ xenbus_switch_state(pdev-xdev, XenbusStateClosed);
out:
-
- return err;
+ return 0;
}
static int pcifront_attach_devices(struct pcifront_device *pdev)
@@ -1060,8 +1057,8 @@ static int pcifront_detach_devices(struct
pcifront_device *pdev)
domain, bus, slot, func);
}
- err = xenbus_switch_state(pdev-xdev, XenbusStateReconfiguring);
-
+ xenbus_switch_state(pdev-xdev, XenbusStateReconfiguring);
+ return 0;
out:
return err;
}
diff --git a/drivers/xen/xen-pciback/xenbus.c
b/drivers/xen/xen-pciback/xenbus.c
index c214daa..630a215 100644
--- a/drivers/xen/xen-pciback/xenbus.c
+++ b/drivers/xen/xen-pciback/xenbus.c
@@ -184,10 +184,7 @@
Re: [PATCH 0/2] be2iscsi : Update to 10.4.114.0
On 09/26/2014 02:13 PM, John Soni Jose wrote: This patchset updates be2iscsi driver to 10.4.114.0 These patches are based on for-next branch of scsi.git. John Soni Jose (2): be2iscsi : Fix kernel panic during reboot/shutdown be2iscsi : Bump the driver version drivers/scsi/be2iscsi/be_main.c |2 +- drivers/scsi/be2iscsi/be_main.h |2 +- 2 files changed, 2 insertions(+), 2 deletions(-) Looks ok to me. Reviewed-by: Mike Christie micha...@cs.wisc.edu Christoph, since this was only two patches I was not sure if you wanted me to round it up with the other iscsi patches I have for 3.18 (I only have 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
Re: [PATCH 0/2] be2iscsi : Update to 10.4.114.0
On Fri, Sep 26, 2014 at 02:06:57PM -0500, Mike Christie wrote: Reviewed-by: Mike Christie micha...@cs.wisc.edu Christoph, since this was only two patches I was not sure if you wanted me to round it up with the other iscsi patches I have for 3.18 (I only have 2). Can you please send everything you have ASAP? Doesn't matter if you include these two or not. -- 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] wd719x: Introduce Western Digital WD7193/7197/7296 PCI SCSI card driver
Introduce wd719x, a driver for Western Digital WD7193, WD7197 and WD7296 PCI
SCSI controllers based on WD33C296A chip.
Tested with WD7193 card.
The card requires firmware that can be cut out of the Windows NT driver that
can be downloaded from WD at:
http://support.wdc.com/product/download.asp?groupid=801sid=27lang=en
There is no license anywhere in the file or on the page - so I guess that the
firmware cannot be added to linux-firmware.
This script downloads and extracts the firmware:
wget http://support.wdc.com/download/archive/pciscsi.exe
lha xi pciscsi.exe pci-scsi.exe
lha xi pci-scsi.exe nt/wd7296a.sys
rm pci-scsi.exe
dd if=wd7296a.sys of=wd719x-risc.bin bs=1 skip=5760 count=14336
dd if=wd7296a.sys of=wd719x-wcs.bin bs=1 skip=20096 count=514
rm wd7296a.sys
Reviewed-by: Christoph Hellwig h...@lst.de
Signed-off-by: Ondrej Zary li...@rainbow-software.org
---
drivers/scsi/Kconfig |8 +
drivers/scsi/Makefile |1 +
drivers/scsi/wd719x.c | 1008 +
drivers/scsi/wd719x.h | 249
4 files changed, 1266 insertions(+)
create mode 100644 drivers/scsi/wd719x.c
create mode 100644 drivers/scsi/wd719x.h
diff --git a/drivers/scsi/Kconfig b/drivers/scsi/Kconfig
index bd85fb4..a390df6 100644
--- a/drivers/scsi/Kconfig
+++ b/drivers/scsi/Kconfig
@@ -1431,6 +1431,14 @@ config SCSI_NSP32
To compile this driver as a module, choose M here: the
module will be called nsp32.
+config SCSI_WD719X
+ tristate Western Digital WD7193/7197/7296 support
+ depends on PCI SCSI
+ select EEPROM_93CX6
+ ---help---
+ This is a driver for Western Digital WD7193, WD7197 and WD7296 PCI
+ SCSI controllers (based on WD33C296A chip).
+
config SCSI_DEBUG
tristate SCSI debugging host simulator
depends on SCSI
diff --git a/drivers/scsi/Makefile b/drivers/scsi/Makefile
index 5f0d299..2034974 100644
--- a/drivers/scsi/Makefile
+++ b/drivers/scsi/Makefile
@@ -142,6 +142,7 @@ obj-$(CONFIG_SCSI_PMCRAID) += pmcraid.o
obj-$(CONFIG_SCSI_VIRTIO) += virtio_scsi.o
obj-$(CONFIG_VMWARE_PVSCSI)+= vmw_pvscsi.o
obj-$(CONFIG_HYPERV_STORAGE) += hv_storvsc.o
+obj-$(CONFIG_SCSI_WD719X) += wd719x.o
obj-$(CONFIG_ARM) += arm/
diff --git a/drivers/scsi/wd719x.c b/drivers/scsi/wd719x.c
new file mode 100644
index 000..ce6dafd
--- /dev/null
+++ b/drivers/scsi/wd719x.c
@@ -0,0 +1,1008 @@
+/*
+ * Driver for Western Digital WD7193, WD7197 and WD7296 SCSI cards
+ * Copyright 2013 Ondrej Zary
+ *
+ * Original driver by
+ * Aaron Dewell dew...@woods.net
+ * Gaerti juergen.gaert...@mbox.si.uni-hannover.de
+ *
+ * HW documentation available in book:
+ *
+ * SPIDER Command Protocol
+ * by Chandru M. Sippy
+ * SCSI Storage Products (MCP)
+ * Western Digital Corporation
+ * 09-15-95
+ *
+ *
http://web.archive.org/web/20070717175254/http://sun1.rrzn.uni-hannover.de/gaertner.juergen/wd719x/Linux/Docu/Spider/
+ */
+
+/*
+ * Driver workflow:
+ * 1. SCSI command is transformed to SCB (Spider Control Block) by the
+ *queuecommand function.
+ * 2. The address of the SCB is stored in a list to be able to access it, if
+ *something goes wrong.
+ * 3. The address of the SCB is written to the Controller, which loads the SCB
+ *via BM-DMA and processes it.
+ * 4. After it has finished, it generates an interrupt, and sets registers.
+ *
+ * flaws:
+ * - abort/reset functions
+ *
+ * ToDo:
+ * - tagged queueing
+ */
+
+#include linux/module.h
+#include linux/delay.h
+#include linux/pci.h
+#include linux/firmware.h
+#include linux/eeprom_93cx6.h
+#include scsi/scsi_cmnd.h
+#include scsi/scsi_device.h
+#include scsi/scsi_host.h
+#include wd719x.h
+
+/* low-level register access */
+static inline u8 wd719x_readb(struct wd719x *wd, u8 reg)
+{
+ return ioread8(wd-base + reg);
+}
+
+static inline u32 wd719x_readl(struct wd719x *wd, u8 reg)
+{
+ return ioread32(wd-base + reg);
+}
+
+static inline void wd719x_writeb(struct wd719x *wd, u8 reg, u8 val)
+{
+ iowrite8(val, wd-base + reg);
+}
+
+static inline void wd719x_writew(struct wd719x *wd, u8 reg, u16 val)
+{
+ iowrite16(val, wd-base + reg);
+}
+
+static inline void wd719x_writel(struct wd719x *wd, u8 reg, u32 val)
+{
+ iowrite32(val, wd-base + reg);
+}
+
+/* wait until the command register is ready */
+static inline int wd719x_wait_ready(struct wd719x *wd)
+{
+ int i = 0;
+
+ do {
+ if (wd719x_readb(wd, WD719X_AMR_COMMAND) == WD719X_CMD_READY)
+ return 0;
+ udelay(1);
+ } while (i++ WD719X_WAIT_FOR_CMD_READY);
+
+ dev_err(wd-pdev-dev, command register is not ready: 0x%02x\n,
+ wd719x_readb(wd, WD719X_AMR_COMMAND));
+
+ return -ETIMEDOUT;
+}
+
+/* poll interrupt status register until command finishes */
+static inline int wd719x_wait_done(struct wd719x *wd, int timeout)
+{
+ u8 status;
+
+ while (timeout 0) {
+
[PATCH 1/2] eeprom-93cx6: Add (read-only) support for 8-bit mode
Add read-only support for EEPROMs configured in 8-bit mode (ORG pin connected
to GND).
This will be used by wd719x driver.
Signed-off-by: Ondrej Zary li...@rainbow-software.org
---
drivers/misc/eeprom/eeprom_93cx6.c | 62 +++-
include/linux/eeprom_93cx6.h |4 +++
2 files changed, 65 insertions(+), 1 deletion(-)
diff --git a/drivers/misc/eeprom/eeprom_93cx6.c
b/drivers/misc/eeprom/eeprom_93cx6.c
index 0ff4b02..0cf2c9d 100644
--- a/drivers/misc/eeprom/eeprom_93cx6.c
+++ b/drivers/misc/eeprom/eeprom_93cx6.c
@@ -170,7 +170,7 @@ static void eeprom_93cx6_read_bits(struct eeprom_93cx6
*eeprom,
}
/**
- * eeprom_93cx6_read - Read multiple words from eeprom
+ * eeprom_93cx6_read - Read a word from eeprom
* @eeprom: Pointer to eeprom structure
* @word: Word index from where we should start reading
* @data: target pointer where the information will have to be stored
@@ -235,6 +235,66 @@ void eeprom_93cx6_multiread(struct eeprom_93cx6 *eeprom,
const u8 word,
EXPORT_SYMBOL_GPL(eeprom_93cx6_multiread);
/**
+ * eeprom_93cx6_readb - Read a byte from eeprom
+ * @eeprom: Pointer to eeprom structure
+ * @word: Byte index from where we should start reading
+ * @data: target pointer where the information will have to be stored
+ *
+ * This function will read a byte of the eeprom data
+ * into the given data pointer.
+ */
+void eeprom_93cx6_readb(struct eeprom_93cx6 *eeprom, const u8 byte,
+ u8 *data)
+{
+ u16 command;
+ u16 tmp;
+
+ /*
+* Initialize the eeprom register
+*/
+ eeprom_93cx6_startup(eeprom);
+
+ /*
+* Select the read opcode and the byte to be read.
+*/
+ command = (PCI_EEPROM_READ_OPCODE (eeprom-width + 1)) | byte;
+ eeprom_93cx6_write_bits(eeprom, command,
+ PCI_EEPROM_WIDTH_OPCODE + eeprom-width + 1);
+
+ /*
+* Read the requested 8 bits.
+*/
+ eeprom_93cx6_read_bits(eeprom, tmp, 8);
+ *data = tmp 0xff;
+
+ /*
+* Cleanup eeprom register.
+*/
+ eeprom_93cx6_cleanup(eeprom);
+}
+EXPORT_SYMBOL_GPL(eeprom_93cx6_readb);
+
+/**
+ * eeprom_93cx6_multireadb - Read multiple bytes from eeprom
+ * @eeprom: Pointer to eeprom structure
+ * @byte: Index from where we should start reading
+ * @data: target pointer where the information will have to be stored
+ * @words: Number of bytes that should be read.
+ *
+ * This function will read all requested bytes from the eeprom,
+ * this is done by calling eeprom_93cx6_readb() multiple times.
+ */
+void eeprom_93cx6_multireadb(struct eeprom_93cx6 *eeprom, const u8 byte,
+ u8 *data, const u16 bytes)
+{
+ unsigned int i;
+
+ for (i = 0; i bytes; i++)
+ eeprom_93cx6_readb(eeprom, byte + i, data[i]);
+}
+EXPORT_SYMBOL_GPL(eeprom_93cx6_multireadb);
+
+/**
* eeprom_93cx6_wren - set the write enable state
* @eeprom: Pointer to eeprom structure
* @enable: true to enable writes, otherwise disable writes
diff --git a/include/linux/eeprom_93cx6.h b/include/linux/eeprom_93cx6.h
index e50f98b..eb0b198 100644
--- a/include/linux/eeprom_93cx6.h
+++ b/include/linux/eeprom_93cx6.h
@@ -75,6 +75,10 @@ extern void eeprom_93cx6_read(struct eeprom_93cx6 *eeprom,
const u8 word, u16 *data);
extern void eeprom_93cx6_multiread(struct eeprom_93cx6 *eeprom,
const u8 word, __le16 *data, const u16 words);
+extern void eeprom_93cx6_readb(struct eeprom_93cx6 *eeprom,
+ const u8 byte, u8 *data);
+extern void eeprom_93cx6_multireadb(struct eeprom_93cx6 *eeprom,
+ const u8 byte, u8 *data, const u16 bytes);
extern void eeprom_93cx6_wren(struct eeprom_93cx6 *eeprom, bool enable);
--
Ondrej Zary
--
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] wd719x: Introduce Western Digital WD7193/7197/7296 PCI SCSI card driver
Hello, this is a new driver for Western Digital WD7193, WD7197 and WD7296 PCI SCSI controllers based on WD33C296A chip. These nice cards never worked good with Linux. It's based on old and ugly wd719x driver written back in 2.0 days, then hacked to 2.2 and finally to 2.4 kernels. Most of the code is rewritten: from ~4100 lines to ~1200. I've tested the driver on a WD7193 card with some hard drives and CD-ROMs: QUANTUM LP240S GM240S01X 4.6 IBM 0663L12 e g IBM DORS-32160 WA0A SONY CD-ROM CDU-55S 1.0t SONY CD-ROM CDU-415 1.1g The card supports TCQ and linked commands (for cmd_per_lun 1?) but I don't know how it should be implemented in a driver. Device/bus/host resets seem to work fine when tested by sg_reset. But don't know how to test command abort. The card requires firmware that can be cut out of the Windows NT driver that can be downloaded from WD at: http://support.wdc.com/product/download.asp?groupid=801sid=27lang=en There is no license anywhere in the file or on the page - so I guess that the firmware cannot be added to linux-firmware. This script downloads and extracts the firmware: #!/bin/sh wget http://support.wdc.com/download/archive/pciscsi.exe lha xi pciscsi.exe pci-scsi.exe lha xi pci-scsi.exe nt/wd7296a.sys rm pci-scsi.exe dd if=wd7296a.sys of=wd719x-risc.bin bs=1 skip=5760 count=14336 dd if=wd7296a.sys of=wd719x-wcs.bin bs=1 skip=20096 count=514 rm wd7296a.sys -- Ondrej Zary -- 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: qla2xxx: Add FDMI-2 functionality.
On 9/26/14, 8:08 AM, Dan Carpenter dan.carpen...@oracle.com wrote:
Hello Himanshu Madhani,
The patch df57cabac41f: qla2xxx: Add FDMI-2 functionality. from Sep
25, 2014, leads to the following static checker warnings:
drivers/scsi/qla2xxx/qla_gs.c:1339 qla2x00_fdmi_rhba() error: snprintf()
chops off the last chars of 'ha-model_number': 17 vs 16
drivers/scsi/qla2xxx/qla_gs.c:1628 qla2x00_fdmi_rpa() error: snprintf()
chops off the last chars of 'p_sysid-nodename': 65 vs 32
drivers/scsi/qla2xxx/qla_gs.c:1631 qla2x00_fdmi_rpa() error: snprintf()
chops off the last chars of
'(((vha-host)-shost_data)-system_hostname)': 256 vs 32
drivers/scsi/qla2xxx/qla_gs.c:1763 qla2x00_fdmiv2_rhba() error:
snprintf() chops off the last chars of 'ha-model_number': 17 vs 16
drivers/scsi/qla2xxx/qla_gs.c:2195 qla2x00_fdmiv2_rpa() error: snprintf()
chops off the last chars of 'p_sysid-nodename': 65 vs 32
drivers/scsi/qla2xxx/qla_gs.c:2198 qla2x00_fdmiv2_rpa() error: snprintf()
chops off the last chars of
'(((vha-host)-shost_data)-system_hostname)': 256 vs 32
drivers/scsi/qla2xxx/qla_gs.c
2194 if (p_sysid) {
2195 snprintf(eiter-a.host_name,
sizeof(eiter-a.host_name),
2196 %s, p_sysid-nodename);
We're chopping most of the hostname off. That seems bad.
2197 } else {
2198 snprintf(eiter-a.host_name,
sizeof(eiter-a.host_name),
2199 %s, fc_host_system_hostname(vha-host));
2200 }
Thanks for the update Dan, Will send a fix soon.
regards,
dan carpenter
attachment: winmail.dat
[PATCH v1 5/5] driver-core: add driver asynchronous probe support
From: Luis R. Rodriguez mcg...@suse.com Some init systems may wish to express the desire to have device drivers run their device driver's bus probe() run asynchronously. This implements support for this and allows userspace to request async probe as a preference through a generic shared device driver module parameter, async_probe. Implemention for async probe is supported through a module parameter given that since synchronous probe has been prevalent for years some userspace might exist which relies on the fact that the device driver will probe synchronously and the assumption that devices it provides will be immediately available after this. Some device driver might not be able to run async probe so we enable device drivers to annotate this to prevent this module parameter from having any effect on them. This implementation uses queue_work(system_unbound_wq) to queue async probes, this should enable probe to run slightly *faster* if the driver's probe path did not have much interaction with other workqueues otherwise it may run _slightly_ slower. Tests were done with cxgb4, which is known to take long on probe, both without having to run request_firmware() [0] and then by requiring it to use request_firmware() [1]. The difference in run time are only measurable in microseconds: =| strategyfw (usec) no-fw (usec) | -| synchronous 244725691307563 | kthread 25066415.5 1309868.5| queue_work(system_unbound_wq) 24913661.5 1307631 | -| In practice, in seconds, the difference is barely noticeable: =| strategyfw (s) no-fw (s)| -| synchronous 24.47 1.31 | kthread 25.07 1.31 | queue_work(system_unbound_wq) 24.91 1.31 | -| [0] http://ftp.suse.com/pub/people/mcgrof/async-probe/probe-cgxb4-no-firmware.png [1] http://ftp.suse.com/pub/people/mcgrof/async-probe/probe-cgxb4-firmware.png The rest of the commit log documents why this feature was implemented primarily first for systemd and things it should consider next. Systemd has a general timeout for all workers currently set to 180 seconds after which it will send a sigkill signal. Systemd now has a warning which is issued once it reaches 1/3 of the timeout. The original motivation for the systemd timeout was to help track device drivers which do not use asynch firmware loading on init() and the timeout was originally set to 30 seconds. Since systemd + kernel are heavily tied in for the purposes of this patch it is assumed you have merged on systemd the following commits: 671174136525ddf208cdbe75d6d6bd159afa961fudev: timeout - warn after a third of the timeout before killing b5338a19864ac3f5632aee48069a669479621dcaudev: timeout - increase timeout 2e92633dbae52f5ac9b7b2e068935990d475d2cdudev: bump event timeout to 60 seconds be2ea723b1d023b3d385d3b791ee4607cbfb20caudev: remove userspace firmware loading support 9f20a8a376f924c8eb5423cfc1f98644fc1e2d1audev: fixup commit dd5eddd28a74a49607a8fffcaf960040dba98479udev: unify event timeout handling 9719859c07aa13539ed2cd4b31972cd30f678543udevd: add --event-timeout commandline option Since we bundle together serially driver init() and probe() on module initialiation systemd's imposed timeout put a limit on the amount of time a driver init() and probe routines can take. There's a few overlooked issues with this and the timeout in general: 0) Not all drivers are killed, the signal is just sent and the kill will only be acted upoon if the driver you loaded happens to have some code path that either uses kthreads (which as of 786235ee are now killable), or uses some code which checks for fatal_signal_pending() on the kernel somewhere -- i.e: pci_read_vpd(). 1) Since systemd is the only one logging the sigkill debugging that drivers are not loaded or in the worst case *failed to boot* because of a sigkill has proven hard to debug. 2) When and if the signal is received by the driver somehow the driver may fail at different points in its initialization and unless all error paths on the driver are implemented perfectly this could mean leaving a device in a half initialized state. 3) The timeout is penalizing device drivers that take long on probe(), this wasn't the original motivation. Systemd seems to have been under
blk-mq, scsi-mq, UFS
Hi all, could someone explain to me: - what is the difference between blk-mq and scsi-mq - why don't I observe large speedups when running the same tiotests on Linux v3.12 (which has no blk-mq) and Linux v3.14 (which does have blk-mq) on a Xilinx Zynq development board (the two Linux versions are configured by Xilinx Zynq and I know only how to add kernel command line parameters)? - when Linux v3.17 becomes available (and Xilinx Zynq ports it for their development board) will I see large speedups reading/writing to the target SDD (which is driven through the UFS driver)? Any and all info would be greatly appreciated. -- 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: blk-mq, scsi-mq, UFS
Andras Kovacs neoteny at freemail.hu writes: reading/writing to the target SDD (which is driven through the UFS driver)? Of course I meant SSD. -- 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
