Re: qla2xxx UBSAN warning in 4.14-rc1
Hi Meelis, > On Jan 24, 2018, at 2:18 PM, Meelis Roos wrote: > >>> Hello, I decided to widen the coverage of my kernel testbed and put some >>> FC cards into servers. This one is a PCI-X QLA2340 in HP Proliant DL 380 >>> G4 (first 64-bit generation of Proliants). I got a UBSAN warning from >>> qla2xxx before probing for the firmware. >> >> Would it be possible for you to test the (completely untested) patch below? > > It compiles without warnings and the driver loads without warnings. > > Meanwhile I tried the following patch, also successfully. > > However, the same problem is present in qla24xx_mbx_completion (and can > also be trivially patched over). > > I did not understand the logic of what's goind on with mailboxes - there > seem to be up to 32 of them and for some reason, a bitmask is used for > iterating over them, with mboxes = ha->mcp->in_mb filtering out some > mailboxes, and in_mb bitmap value comes from firmware? > > diff --git a/drivers/scsi/qla2xxx/qla_isr.c b/drivers/scsi/qla2xxx/qla_isr.c > index 2fd79129bb2a..7868930ae1c8 100644 > --- a/drivers/scsi/qla2xxx/qla_isr.c > +++ b/drivers/scsi/qla2xxx/qla_isr.c > @@ -272,7 +272,7 @@ qla2x00_mbx_completion(scsi_qla_host_t *vha, uint16_t mb0) > struct device_reg_2xxx __iomem *reg = &ha->iobase->isp; > > /* Read all mbox registers? */ > - mboxes = (1 << ha->mbx_count) - 1; > + mboxes = (1ULL << ha->mbx_count) - 1; > if (!ha->mcp) > ql_dbg(ql_dbg_async, vha, 0x5001, "MBX pointer ERROR.\n"); > else > > -- > Meelis Roos (mr...@linux.ee) Since I did could not get hold of 4G adapter for testing, i was not able to get to this one fixed in time. Bart’s change looks good and with your testing should be good to include. I also noticed qla24xx_mbx_completion() will need this fix. I was able to confirm it on my setup with 16/32G adapter. diff --git a/drivers/scsi/qla2xxx/qla_isr.c b/drivers/scsi/qla2xxx/qla_isr.c index d1e7fd905f16..b97b14a89ac3 100644 --- a/drivers/scsi/qla2xxx/qla_isr.c +++ b/drivers/scsi/qla2xxx/qla_isr.c @@ -272,7 +272,7 @@ qla2x00_mbx_completion(scsi_qla_host_t *vha, uint16_t mb0) struct device_reg_2xxx __iomem *reg = &ha->iobase->isp; /* Read all mbox registers? */ - mboxes = (1 << ha->mbx_count) - 1; + mboxes = (ha->mbx_count != 32 ? 1U << ha->mbx_count : 0) - 1U; if (!ha->mcp) ql_dbg(ql_dbg_async, vha, 0x5001, "MBX pointer ERROR.\n"); else @@ -2881,7 +2881,7 @@ qla24xx_mbx_completion(scsi_qla_host_t *vha, uint16_t mb0) struct device_reg_24xx __iomem *reg = &ha->iobase->isp24; /* Read all mbox registers? */ - mboxes = (1 << ha->mbx_count) - 1; + mboxes = (ha->mbx_count != 32 ? 1U << ha->mbx_count : 0) - 1U; if (!ha->mcp) ql_dbg(ql_dbg_async, vha, 0x504e, "MBX pointer ERROR.\n”); Would you care to send formal patch and add my ACK to it? Thanks for all the effort on getting this tested on your setup. Thanks, - Himanshu
Your quick response will be highly appreciated.
--
Dear Beneficiary
This is to inform you that your Long Time Awaiting Funds amounting in the
tone of USD$10,400,000.00 {TEN MILLION, FOUR HUNDRED THOUSAND UNITED STATES
DOLLARS) Which is presently in the custody of a finance house in Germany
has been approved for immediate delivery to you in your country.
For the purpose of clarification, you are advised to reconfirm the
requested below information to our direct email address-:
mrsannwill...@gmail.com
Full Names
Direct Telephone Numbers
Physical Address with Zip Code so that there will be no error during
the delivery of the funds to you in your country of residence.
Your quick response will be highly appreciated.
Mrs Ann Willi
Re: [LSF/MM TOPIC] Patch Submission process and Handling Internal Conflict
On Wed, Jan 24, 2018 at 01:36:00PM -0800, James Bottomley wrote: > On Wed, 2018-01-24 at 11:20 -0800, Mike Kravetz wrote: > > On 01/24/2018 11:05 AM, James Bottomley wrote: > > > > > > I've got two community style topics, which should probably be > > > discussed > > > in the plenary > > > > > > 1. Patch Submission Process > > > > > > Today we don't have a uniform patch submission process across > > > Storage, Filesystems and MM. The question is should we (or at > > > least should we adhere to some minimal standards). The standard > > > we've been trying to hold to in SCSI is one review per accepted > > > non-trivial patch. For us, it's useful because it encourages > > > driver writers to review each other's patches rather than just > > > posting and then complaining their patch hasn't gone in. I can > > > certainly think of a couple of bugs I've had to chase in mm where > > > the underlying patches would have benefited from review, so I'd > > > like to discuss making the one review per non-trival patch our base > > > minimum standard across the whole of LSF/MM; it would certainly > > > serve to improve our Reviewed-by statistics. > > > > Well, the mm track at least has some discussion of this last year: > > https://lwn.net/Articles/718212/ > > The pushback in your session was mandating reviews would mean slowing > patch acceptance or possibly causing the dropping of patches that > couldn't get reviewed. Michal did say that XFS didn't have the > problem, however there not being XFS people in the room, discussion > stopped there. I actually /was/ lurking in the session, but a year later I have more thoughts: Now that I've been maintainer for more than a year I feel more confident in actually talking about our review processes, though I can only speak about my own experiences and hope the other xfs developers chime in if they choose. In xfs we are fortunate enough that most of the codebase is at least one software layer up from the raw hardware, which means that anybody can build xfs with all kconfig options enabled and use it to try to create all possible metadata structures, which means that the ability to review a given patch and try it out isn't restricted to the subset of people with a particular hardware device. This means that there aren't any patches that cannot be reviewed, which is not something I'm so sure of for the mm layer. Requiring review on the vast majority of non-maintainer patches that goes into xfs (and xfsprogs) doesn't has the effect of increasing the time to upstream acceptance, since the fact that it was committed at all implies that the maintainer probably looked at it. The dangerous part of course is when the maintainer commits non-trivial code without a review -- did they look at it, or just commit whatever made the symptoms go away? So that's argument #1 for creating a group norm that yes, everyone should be involved in review on a semi regular basis. Certainly if they're also *submitting* patches. Argument #2 is that encouraging review of everything most likely reduces the overall time it takes for a feature to mature because that means that at least one of the regular participants in the group have taken the time to read and understand how the patches mesh with the existing systems and will ask questions when they see ill-fitting pieces. It definitely reduces code churn from not having to walk back bad patches and rushed microcode updates. That said, I've no data to back up this assertion, merely my observations of the past decade. My third argument is that the most time consuming part of maintainership isn't gluing patches onto a git tree and running tests, it's reviewing the patches. It's a big help to know that other people who are more familiar with various subcomponents of xfs review patches regularly, so I don't feel as much pressure to know all things at all times, and I worry less about blind spots because we work as a group of people who don't see every xfs component in exactly the same way. (Granted it helps that Dave Chinner is a fountain of historical context indexing...) That said, I also get rally itchy to commit my own patches at times, especially things that look like trivial one-liners. However, I find that nothing in xfs is simple, and moreover the reviewers are knowledgeable enough that even trivial patches can get reviewed quickly. For bigger things like new features or large refactorings, there's a strong need for updating documentation like the disk format specification, developing a test plan, and integrating new tests into xfstests. That's where review is most useful, because it is the submitter's opportunity to increase everyone's knowledge levels. It is also the reviewers' chance to anticipate design problems when it is easy/cheap to fix them, and for everyone to build confidence about the code that's going in. The challenge for everyone, then, is to get together to decide on a reasonable target for the amount and the l
[PATCH 1/1] scsi: storvsc: Increase cmd_per_lun for higher speed devices
Increase cmd_per_lun to allow more I/Os in progress per device, particularly for NVMe's. The Hyper-V host side can handle the higher count with no issues. Signed-off-by: Michael Kelley --- drivers/scsi/storvsc_drv.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/scsi/storvsc_drv.c b/drivers/scsi/storvsc_drv.c index f3264c4..6205107 100644 --- a/drivers/scsi/storvsc_drv.c +++ b/drivers/scsi/storvsc_drv.c @@ -1657,7 +1657,7 @@ static int storvsc_queuecommand(struct Scsi_Host *host, struct scsi_cmnd *scmnd) .eh_timed_out = storvsc_eh_timed_out, .slave_alloc = storvsc_device_alloc, .slave_configure = storvsc_device_configure, - .cmd_per_lun = 255, + .cmd_per_lun = 2048, .this_id = -1, .use_clustering = ENABLE_CLUSTERING, /* Make sure we dont get a sg segment crosses a page boundary */ -- 1.8.3.1
[PATCH 10/19] lpfc: Fix soft lockup in lpfc worker thread during LIP testing
During link bounce testing in a point-to-point topology, the
host may enter a soft lockup on the lpfc_worker thread:
Call Trace:
lpfc_work_done+0x1f3/0x1390 [lpfc]
lpfc_do_work+0x16f/0x180 [lpfc]
kthread+0xc7/0xe0
ret_from_fork+0x3f/0x70
The driver was simultaneously setting a combination of flags
that caused lpfc_do_work()to effectively spin between slow path
work and new event data, causing the lockup.
Ensure in the typical wq completions, that new event data flags
are set if the slow path flag is running. The slow path will
eventually reschedule the wq handling.
Signed-off-by: Dick Kennedy
Signed-off-by: James Smart
---
drivers/scsi/lpfc/lpfc_hbadisc.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/scsi/lpfc/lpfc_hbadisc.c b/drivers/scsi/lpfc/lpfc_hbadisc.c
index b159a5c4e388..9265906d956e 100644
--- a/drivers/scsi/lpfc/lpfc_hbadisc.c
+++ b/drivers/scsi/lpfc/lpfc_hbadisc.c
@@ -696,8 +696,9 @@ lpfc_work_done(struct lpfc_hba *phba)
phba->hba_flag & HBA_SP_QUEUE_EVT)) {
if (pring->flag & LPFC_STOP_IOCB_EVENT) {
pring->flag |= LPFC_DEFERRED_RING_EVENT;
- /* Set the lpfc data pending flag */
- set_bit(LPFC_DATA_READY, &phba->data_flags);
+ /* Preserve legacy behavior. */
+ if (!(phba->hba_flag & HBA_SP_QUEUE_EVT))
+ set_bit(LPFC_DATA_READY, &phba->data_flags);
} else {
if (phba->link_state >= LPFC_LINK_UP ||
phba->link_flag & LS_MDS_LOOPBACK) {
--
2.13.1
[PATCH 07/19] lpfc: Fix IO failure during hba reset testing with nvme io.
A stress test repeatedly resetting the adapter while performing io would eventually report I/O failures and missing nvme namespaces. The driver was setting the nvmefc_fcp_req->private pointer to NULL during the IO completion routine before upcalling done(). If the transport was also running an abort for that IO, the driver would fail the abort with message 6140. Failing the abort is not allowed by the nvme-fc transport, as it mandates that the io must be returned back to the transport. As that does not happen, the transport controller delete has an outstanding reference and can't complete teardown. Remove the NULL'ing of the private pointer in the nvmefc request. The driver simply overwrites this value on each IO start. Signed-off-by: Dick Kennedy Signed-off-by: James Smart --- drivers/scsi/lpfc/lpfc_nvme.c | 3 --- 1 file changed, 3 deletions(-) diff --git a/drivers/scsi/lpfc/lpfc_nvme.c b/drivers/scsi/lpfc/lpfc_nvme.c index 81e3a4f10c3c..92643ffa79c3 100644 --- a/drivers/scsi/lpfc/lpfc_nvme.c +++ b/drivers/scsi/lpfc/lpfc_nvme.c @@ -804,7 +804,6 @@ lpfc_nvme_io_cmd_wqe_cmpl(struct lpfc_hba *phba, struct lpfc_iocbq *pwqeIn, struct nvme_fc_cmd_iu *cp; struct lpfc_nvme_rport *rport; struct lpfc_nodelist *ndlp; - struct lpfc_nvme_fcpreq_priv *freqpriv; struct lpfc_nvme_lport *lport; unsigned long flags; uint32_t code, status; @@ -980,8 +979,6 @@ lpfc_nvme_io_cmd_wqe_cmpl(struct lpfc_hba *phba, struct lpfc_iocbq *pwqeIn, phba->cpucheck_cmpl_io[lpfc_ncmd->cpu]++; } #endif - freqpriv = nCmd->private; - freqpriv->nvme_buf = NULL; /* NVME targets need completion held off until the abort exchange * completes unless the NVME Rport is getting unregistered. -- 2.13.1
[PATCH 17/19] lpfc: Fix nonrecovery of NVME controller after cable swap.
In a test that is doing large numbers of cable swaps on the target,
the nvme controllers wouldn't reconnect.
During the cable swaps, the targets n_port_id would change. This
information was passed to the nvme-fc transport, in the new remoteport
registration. However, the nvme-fc transport didn't update the n_port_id
value in the remoteport struct when it reused an existing structure.
Later, when a new association was attempted on the remoteport, the
driver's NVME LS routine would use the stale n_port_id from the remoteport
struct to address the LS. As the device is no longer at that address,
the LS would go into never never land.
Separately, the nvme-fc transport will be corrected to update the
n_port_id value on a re-registration.
However, for now, there's no reason to use the transports values.
The private pointer points to the drivers node structure and the
node structure is up to date. Therefore, revise the LS routine to
use the drivers data structures for the LS. Augmented the debug
message for better debugging in the future.
Also removed a duplicate if check that seems to have slipped in.
Signed-off-by: Dick Kennedy
Signed-off-by: James Smart
---
drivers/scsi/lpfc/lpfc_nvme.c | 24 +---
1 file changed, 13 insertions(+), 11 deletions(-)
diff --git a/drivers/scsi/lpfc/lpfc_nvme.c b/drivers/scsi/lpfc/lpfc_nvme.c
index 92643ffa79c3..fc6d85f0bfcf 100644
--- a/drivers/scsi/lpfc/lpfc_nvme.c
+++ b/drivers/scsi/lpfc/lpfc_nvme.c
@@ -241,10 +241,11 @@ lpfc_nvme_cmpl_gen_req(struct lpfc_hba *phba, struct
lpfc_iocbq *cmdwqe,
ndlp = (struct lpfc_nodelist *)cmdwqe->context1;
lpfc_printf_vlog(vport, KERN_INFO, LOG_NVME_DISC,
"6047 nvme cmpl Enter "
-"Data %p DID %x Xri: %x status %x cmd:%p lsreg:%p "
-"bmp:%p ndlp:%p\n",
+"Data %p DID %x Xri: %x status %x reason x%x cmd:%p "
+"lsreg:%p bmp:%p ndlp:%p\n",
pnvme_lsreq, ndlp ? ndlp->nlp_DID : 0,
cmdwqe->sli4_xritag, status,
+(wcqe->parameter & 0x),
cmdwqe, pnvme_lsreq, cmdwqe->context3, ndlp);
lpfc_nvmeio_data(phba, "NVME LS CMPL: xri x%x stat x%x parm x%x\n",
@@ -419,6 +420,7 @@ lpfc_nvme_ls_req(struct nvme_fc_local_port *pnvme_lport,
{
int ret = 0;
struct lpfc_nvme_lport *lport;
+ struct lpfc_nvme_rport *rport;
struct lpfc_vport *vport;
struct lpfc_nodelist *ndlp;
struct ulp_bde64 *bpl;
@@ -437,19 +439,18 @@ lpfc_nvme_ls_req(struct nvme_fc_local_port *pnvme_lport,
*/
lport = (struct lpfc_nvme_lport *)pnvme_lport->private;
+ rport = (struct lpfc_nvme_rport *)pnvme_rport->private;
vport = lport->vport;
if (vport->load_flag & FC_UNLOADING)
return -ENODEV;
- if (vport->load_flag & FC_UNLOADING)
- return -ENODEV;
-
- ndlp = lpfc_findnode_did(vport, pnvme_rport->port_id);
+ /* Need the ndlp. It is stored in the driver's rport. */
+ ndlp = rport->ndlp;
if (!ndlp || !NLP_CHK_NODE_ACT(ndlp)) {
lpfc_printf_vlog(vport, KERN_ERR, LOG_NODE | LOG_NVME_IOERR,
-"6051 DID x%06x not an active rport.\n",
-pnvme_rport->port_id);
+"6051 Remoteport %p, rport has invalid ndlp. "
+"Failing LS Req\n", pnvme_rport);
return -ENODEV;
}
@@ -500,8 +501,9 @@ lpfc_nvme_ls_req(struct nvme_fc_local_port *pnvme_lport,
/* Expand print to include key fields. */
lpfc_printf_vlog(vport, KERN_INFO, LOG_NVME_DISC,
-"6149 ENTER. lport %p, rport %p lsreq%p rqstlen:%d "
-"rsplen:%d %pad %pad\n",
+"6149 Issue LS Req to DID 0x%06x lport %p, rport %p "
+"lsreq%p rqstlen:%d rsplen:%d %pad %pad\n",
+ndlp->nlp_DID,
pnvme_lport, pnvme_rport,
pnvme_lsreq, pnvme_lsreq->rqstlen,
pnvme_lsreq->rsplen, &pnvme_lsreq->rqstdma,
@@ -517,7 +519,7 @@ lpfc_nvme_ls_req(struct nvme_fc_local_port *pnvme_lport,
ndlp, 2, 30, 0);
if (ret != WQE_SUCCESS) {
atomic_inc(&lport->xmt_ls_err);
- lpfc_printf_vlog(vport, KERN_INFO, LOG_NVME_DISC,
+ lpfc_printf_vlog(vport, KERN_ERR, LOG_NVME_DISC,
"6052 EXIT. issue ls wqe failed lport %p, "
"rport %p lsreq%p Status %x DID %x\n",
pnvme_lport, pnvme_rport, pnvme_lsreq,
--
2.13.1
[PATCH 05/19] lpfc: Add WQ Full Logic for NVME Target
I/O conditions on the nvme target may have the driver submitting
to a full hardware wq. The hardware wq is a shared resource among
all nvme controllers. When the driver hit a full wq, it failed the
io posting back to the nvme-fc transport, which then escalated it
into errors.
Correct by maintaining a sideband queue within the driver that is
added to when the WQ full condition is hit, and drained from as soon
as new WQ space opens up.
Signed-off-by: Dick Kennedy
Signed-off-by: James Smart
---
drivers/scsi/lpfc/lpfc_crtn.h | 1 +
drivers/scsi/lpfc/lpfc_nvmet.c | 116 +
drivers/scsi/lpfc/lpfc_nvmet.h | 1 +
drivers/scsi/lpfc/lpfc_sli.c | 3 ++
drivers/scsi/lpfc/lpfc_sli4.h | 5 +-
5 files changed, 125 insertions(+), 1 deletion(-)
diff --git a/drivers/scsi/lpfc/lpfc_crtn.h b/drivers/scsi/lpfc/lpfc_crtn.h
index 559f9aa0ed08..3ecf50df93f4 100644
--- a/drivers/scsi/lpfc/lpfc_crtn.h
+++ b/drivers/scsi/lpfc/lpfc_crtn.h
@@ -254,6 +254,7 @@ void lpfc_nvmet_ctxbuf_post(struct lpfc_hba *phba,
struct lpfc_nvmet_ctxbuf *ctxp);
int lpfc_nvmet_rcv_unsol_abort(struct lpfc_vport *vport,
struct fc_frame_header *fc_hdr);
+void lpfc_nvmet_wqfull_process(struct lpfc_hba *phba, struct lpfc_queue *wq);
void lpfc_sli_flush_nvme_rings(struct lpfc_hba *phba);
void lpfc_nvme_wait_for_io_drain(struct lpfc_hba *phba);
void lpfc_sli4_build_dflt_fcf_record(struct lpfc_hba *, struct fcf_record *,
diff --git a/drivers/scsi/lpfc/lpfc_nvmet.c b/drivers/scsi/lpfc/lpfc_nvmet.c
index 7927ac46d345..9c2acf90212c 100644
--- a/drivers/scsi/lpfc/lpfc_nvmet.c
+++ b/drivers/scsi/lpfc/lpfc_nvmet.c
@@ -71,6 +71,8 @@ static int lpfc_nvmet_unsol_fcp_issue_abort(struct lpfc_hba *,
static int lpfc_nvmet_unsol_ls_issue_abort(struct lpfc_hba *,
struct lpfc_nvmet_rcv_ctx *,
uint32_t, uint16_t);
+static void lpfc_nvmet_wqfull_flush(struct lpfc_hba *, struct lpfc_queue *,
+ struct lpfc_nvmet_rcv_ctx *);
void
lpfc_nvmet_defer_release(struct lpfc_hba *phba, struct lpfc_nvmet_rcv_ctx
*ctxp)
@@ -741,7 +743,10 @@ lpfc_nvmet_xmt_fcp_op(struct nvmet_fc_target_port *tgtport,
struct lpfc_nvmet_rcv_ctx *ctxp =
container_of(rsp, struct lpfc_nvmet_rcv_ctx, ctx.fcp_req);
struct lpfc_hba *phba = ctxp->phba;
+ struct lpfc_queue *wq;
struct lpfc_iocbq *nvmewqeq;
+ struct lpfc_sli_ring *pring;
+ unsigned long iflags;
int rc;
if (phba->pport->load_flag & FC_UNLOADING) {
@@ -820,6 +825,21 @@ lpfc_nvmet_xmt_fcp_op(struct nvmet_fc_target_port *tgtport,
return 0;
}
+ if (rc == -EBUSY) {
+ /*
+* WQ was full, so queue nvmewqeq to be sent after
+* WQE release CQE
+*/
+ ctxp->flag |= LPFC_NVMET_DEFER_WQFULL;
+ wq = phba->sli4_hba.nvme_wq[rsp->hwqid];
+ pring = wq->pring;
+ spin_lock_irqsave(&pring->ring_lock, iflags);
+ list_add_tail(&nvmewqeq->list, &wq->wqfull_list);
+ wq->q_flag |= HBA_NVMET_WQFULL;
+ spin_unlock_irqrestore(&pring->ring_lock, iflags);
+ return 0;
+ }
+
/* Give back resources */
atomic_inc(&lpfc_nvmep->xmt_fcp_drop);
lpfc_printf_log(phba, KERN_ERR, LOG_NVME_IOERR,
@@ -851,6 +871,7 @@ lpfc_nvmet_xmt_fcp_abort(struct nvmet_fc_target_port
*tgtport,
struct lpfc_nvmet_rcv_ctx *ctxp =
container_of(req, struct lpfc_nvmet_rcv_ctx, ctx.fcp_req);
struct lpfc_hba *phba = ctxp->phba;
+ struct lpfc_queue *wq;
unsigned long flags;
if (phba->pport->load_flag & FC_UNLOADING)
@@ -880,6 +901,14 @@ lpfc_nvmet_xmt_fcp_abort(struct nvmet_fc_target_port
*tgtport,
}
ctxp->flag |= LPFC_NVMET_ABORT_OP;
+ if (ctxp->flag & LPFC_NVMET_DEFER_WQFULL) {
+ lpfc_nvmet_unsol_fcp_issue_abort(phba, ctxp, ctxp->sid,
+ctxp->oxid);
+ wq = phba->sli4_hba.nvme_wq[ctxp->wqeq->hba_wqidx];
+ lpfc_nvmet_wqfull_flush(phba, wq, ctxp);
+ return;
+ }
+
/* An state of LPFC_NVMET_STE_RCV means we have just received
* the NVME command and have not started processing it.
* (by issuing any IO WQEs on this exchange yet)
@@ -1435,16 +1464,103 @@ lpfc_nvmet_rcv_unsol_abort(struct lpfc_vport *vport,
return 0;
}
+static void
+lpfc_nvmet_wqfull_flush(struct lpfc_hba *phba, struct lpfc_queue *wq,
+ struct lpfc_nvmet_rcv_ctx *ctxp)
+{
+ struct lpfc_sli_ring *pring;
+ struct lpfc_iocbq *nvmewqeq;
+ struct lpfc_iocbq *next_nvmewqeq;
+ unsigned long iflags;
+ struct lpfc_wcqe_complete wcqe;
+ struct lpfc
[PATCH 06/19] lpfc: Fix PRLI handling when topology type changes
The lpfc driver does not discover a target when the topology
changes from switched-fabric to direct-connect. The target
rejects the PRLI from the initiator in direct-connect as the
driver is using the old S_ID from the switched topology.
The driver was inappropriately clearing the VP bit to register the
VPI, which is what is associated with the S_ID.
Fix by leaving the VP bit set (it was set earlier) and as the VFI
is being re-registered, set the UPDT bit.
Signed-off-by: Dick Kennedy
Signed-off-by: James Smart
---
drivers/scsi/lpfc/lpfc_mbox.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/scsi/lpfc/lpfc_mbox.c b/drivers/scsi/lpfc/lpfc_mbox.c
index 81fb92967b11..c32d4a323db2 100644
--- a/drivers/scsi/lpfc/lpfc_mbox.c
+++ b/drivers/scsi/lpfc/lpfc_mbox.c
@@ -2170,10 +2170,8 @@ lpfc_reg_vfi(struct lpfcMboxq *mbox, struct lpfc_vport
*vport, dma_addr_t phys)
/* Only FC supports upd bit */
if ((phba->sli4_hba.lnk_info.lnk_tp == LPFC_LNK_TYPE_FC) &&
(vport->fc_flag & FC_VFI_REGISTERED) &&
- (!phba->fc_topology_changed)) {
- bf_set(lpfc_reg_vfi_vp, reg_vfi, 0);
+ (!phba->fc_topology_changed))
bf_set(lpfc_reg_vfi_upd, reg_vfi, 1);
- }
bf_set(lpfc_reg_vfi_bbcr, reg_vfi, 0);
bf_set(lpfc_reg_vfi_bbscn, reg_vfi, 0);
--
2.13.1
Re: qla2xxx UBSAN warning in 4.14-rc1
> > Hello, I decided to widen the coverage of my kernel testbed and put some > > FC cards into servers. This one is a PCI-X QLA2340 in HP Proliant DL 380 > > G4 (first 64-bit generation of Proliants). I got a UBSAN warning from > > qla2xxx before probing for the firmware. > > Would it be possible for you to test the (completely untested) patch below? It compiles without warnings and the driver loads without warnings. Meanwhile I tried the following patch, also successfully. However, the same problem is present in qla24xx_mbx_completion (and can also be trivially patched over). I did not understand the logic of what's goind on with mailboxes - there seem to be up to 32 of them and for some reason, a bitmask is used for iterating over them, with mboxes = ha->mcp->in_mb filtering out some mailboxes, and in_mb bitmap value comes from firmware? diff --git a/drivers/scsi/qla2xxx/qla_isr.c b/drivers/scsi/qla2xxx/qla_isr.c index 2fd79129bb2a..7868930ae1c8 100644 --- a/drivers/scsi/qla2xxx/qla_isr.c +++ b/drivers/scsi/qla2xxx/qla_isr.c @@ -272,7 +272,7 @@ qla2x00_mbx_completion(scsi_qla_host_t *vha, uint16_t mb0) struct device_reg_2xxx __iomem *reg = &ha->iobase->isp; /* Read all mbox registers? */ - mboxes = (1 << ha->mbx_count) - 1; + mboxes = (1ULL << ha->mbx_count) - 1; if (!ha->mcp) ql_dbg(ql_dbg_async, vha, 0x5001, "MBX pointer ERROR.\n"); else -- Meelis Roos (mr...@linux.ee)
[PATCH 13/19] lpfc: Fix SCSI io host reset causing kernel crash
During SCSI error handling escalation to host reset, the SCSI io
routines were moved off the txcmplq, but the individual io's
ON_CMPLQ flag wasn't cleared. Thus, a background thread saw the
io and attempted to access it as if on the txcmplq.
Clear the flag upon removal.
Signed-off-by: Dick Kennedy
Signed-off-by: James Smart
---
drivers/scsi/lpfc/lpfc_init.c | 4
drivers/scsi/lpfc/lpfc_sli.c | 13 -
2 files changed, 16 insertions(+), 1 deletion(-)
diff --git a/drivers/scsi/lpfc/lpfc_init.c b/drivers/scsi/lpfc/lpfc_init.c
index 851d4e889042..7fc2db968379 100644
--- a/drivers/scsi/lpfc/lpfc_init.c
+++ b/drivers/scsi/lpfc/lpfc_init.c
@@ -958,6 +958,7 @@ lpfc_hba_clean_txcmplq(struct lpfc_hba *phba)
struct lpfc_sli_ring *pring;
LIST_HEAD(completions);
int i;
+ struct lpfc_iocbq *piocb, *next_iocb;
if (phba->sli_rev != LPFC_SLI_REV4) {
for (i = 0; i < psli->num_rings; i++) {
@@ -983,6 +984,9 @@ lpfc_hba_clean_txcmplq(struct lpfc_hba *phba)
if (!pring)
continue;
spin_lock_irq(&pring->ring_lock);
+ list_for_each_entry_safe(piocb, next_iocb,
+&pring->txcmplq, list)
+ piocb->iocb_flag &= ~LPFC_IO_ON_TXCMPLQ;
list_splice_init(&pring->txcmplq, &completions);
pring->txcmplq_cnt = 0;
spin_unlock_irq(&pring->ring_lock);
diff --git a/drivers/scsi/lpfc/lpfc_sli.c b/drivers/scsi/lpfc/lpfc_sli.c
index 8b2919a553d6..d597e15a1974 100644
--- a/drivers/scsi/lpfc/lpfc_sli.c
+++ b/drivers/scsi/lpfc/lpfc_sli.c
@@ -3778,6 +3778,7 @@ lpfc_sli_flush_fcp_rings(struct lpfc_hba *phba)
struct lpfc_sli *psli = &phba->sli;
struct lpfc_sli_ring *pring;
uint32_t i;
+ struct lpfc_iocbq *piocb, *next_iocb;
spin_lock_irq(&phba->hbalock);
/* Indicate the I/O queues are flushed */
@@ -3792,6 +3793,9 @@ lpfc_sli_flush_fcp_rings(struct lpfc_hba *phba)
spin_lock_irq(&pring->ring_lock);
/* Retrieve everything on txq */
list_splice_init(&pring->txq, &txq);
+ list_for_each_entry_safe(piocb, next_iocb,
+&pring->txcmplq, list)
+ piocb->iocb_flag &= ~LPFC_IO_ON_TXCMPLQ;
/* Retrieve everything on the txcmplq */
list_splice_init(&pring->txcmplq, &txcmplq);
pring->txq_cnt = 0;
@@ -3813,6 +3817,9 @@ lpfc_sli_flush_fcp_rings(struct lpfc_hba *phba)
spin_lock_irq(&phba->hbalock);
/* Retrieve everything on txq */
list_splice_init(&pring->txq, &txq);
+ list_for_each_entry_safe(piocb, next_iocb,
+&pring->txcmplq, list)
+ piocb->iocb_flag &= ~LPFC_IO_ON_TXCMPLQ;
/* Retrieve everything on the txcmplq */
list_splice_init(&pring->txcmplq, &txcmplq);
pring->txq_cnt = 0;
@@ -3844,6 +3851,7 @@ lpfc_sli_flush_nvme_rings(struct lpfc_hba *phba)
LIST_HEAD(txcmplq);
struct lpfc_sli_ring *pring;
uint32_t i;
+ struct lpfc_iocbq *piocb, *next_iocb;
if (phba->sli_rev < LPFC_SLI_REV4)
return;
@@ -3860,8 +3868,11 @@ lpfc_sli_flush_nvme_rings(struct lpfc_hba *phba)
for (i = 0; i < phba->cfg_nvme_io_channel; i++) {
pring = phba->sli4_hba.nvme_wq[i]->pring;
- /* Retrieve everything on the txcmplq */
spin_lock_irq(&pring->ring_lock);
+ list_for_each_entry_safe(piocb, next_iocb,
+&pring->txcmplq, list)
+ piocb->iocb_flag &= ~LPFC_IO_ON_TXCMPLQ;
+ /* Retrieve everything on the txcmplq */
list_splice_init(&pring->txcmplq, &txcmplq);
pring->txcmplq_cnt = 0;
spin_unlock_irq(&pring->ring_lock);
--
2.13.1
[PATCH 14/19] lpfc: Validate adapter support for SRIU option
When using the special option to suppress the response iu, ensure
the adapter fully supports the feature by checking feature flags
from the adapter.
Signed-off-by: Dick Kennedy
Signed-off-by: James Smart
---
drivers/scsi/lpfc/lpfc_hw4.h | 3 +++
drivers/scsi/lpfc/lpfc_init.c | 13 -
2 files changed, 15 insertions(+), 1 deletion(-)
diff --git a/drivers/scsi/lpfc/lpfc_hw4.h b/drivers/scsi/lpfc/lpfc_hw4.h
index 7c3afc3d3121..52fe28ae50fa 100644
--- a/drivers/scsi/lpfc/lpfc_hw4.h
+++ b/drivers/scsi/lpfc/lpfc_hw4.h
@@ -3293,6 +3293,9 @@ struct lpfc_sli4_parameters {
#define cfg_eqdr_SHIFT 8
#define cfg_eqdr_MASK 0x0001
#define cfg_eqdr_WORD word19
+#define cfg_nosr_SHIFT 9
+#define cfg_nosr_MASK 0x0001
+#define cfg_nosr_WORD word19
#define LPFC_NODELAY_MAX_IO32
};
diff --git a/drivers/scsi/lpfc/lpfc_init.c b/drivers/scsi/lpfc/lpfc_init.c
index 7fc2db968379..895b1da784ee 100644
--- a/drivers/scsi/lpfc/lpfc_init.c
+++ b/drivers/scsi/lpfc/lpfc_init.c
@@ -10473,8 +10473,19 @@ lpfc_get_sli4_parameters(struct lpfc_hba *phba,
LPFC_MBOXQ_t *mboxq)
phba->cfg_enable_fc4_type = LPFC_ENABLE_FCP;
}
- if (bf_get(cfg_xib, mbx_sli4_parameters) && phba->cfg_suppress_rsp)
+ /*
+* To support Suppress Response feature we must satisfy 3 conditions.
+* lpfc_suppress_rsp module parameter must be set (default).
+* In SLI4-Parameters Descriptor:
+* Extended Inline Buffers (XIB) must be supported.
+* Suppress Response IU Not Supported (SRIUNS) must NOT be supported
+* (double negative).
+*/
+ if (phba->cfg_suppress_rsp && bf_get(cfg_xib, mbx_sli4_parameters) &&
+ !(bf_get(cfg_nosr, mbx_sli4_parameters)))
phba->sli.sli_flag |= LPFC_SLI_SUPPRESS_RSP;
+ else
+ phba->cfg_suppress_rsp = 0;
if (bf_get(cfg_eqdr, mbx_sli4_parameters))
phba->sli.sli_flag |= LPFC_SLI_USE_EQDR;
--
2.13.1
[PATCH 03/19] lpfc: move placement of target destroy on driver detach
Ensure nvme localports/targetports are torn down before dismantling the adapter sli interface on driver detachment. This aids leaving interfaces live while nvme may be making callbacks to abort it. Signed-off-by: Dick Kennedy Signed-off-by: James Smart --- drivers/scsi/lpfc/lpfc_init.c | 14 +++--- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/drivers/scsi/lpfc/lpfc_init.c b/drivers/scsi/lpfc/lpfc_init.c index 5b96bf0d3331..851d4e889042 100644 --- a/drivers/scsi/lpfc/lpfc_init.c +++ b/drivers/scsi/lpfc/lpfc_init.c @@ -11503,13 +11503,6 @@ lpfc_pci_remove_one_s4(struct pci_dev *pdev) /* Remove FC host and then SCSI host with the physical port */ fc_remove_host(shost); scsi_remove_host(shost); - /* -* Bring down the SLI Layer. This step disables all interrupts, -* clears the rings, discards all mailbox commands, and resets -* the HBA FCoE function. -*/ - lpfc_debugfs_terminate(vport); - lpfc_sli4_hba_unset(phba); /* Perform ndlp cleanup on the physical port. The nvme and nvmet * localports are destroyed after to cleanup all transport memory. @@ -11518,6 +11511,13 @@ lpfc_pci_remove_one_s4(struct pci_dev *pdev) lpfc_nvmet_destroy_targetport(phba); lpfc_nvme_destroy_localport(vport); + /* +* Bring down the SLI Layer. This step disables all interrupts, +* clears the rings, discards all mailbox commands, and resets +* the HBA FCoE function. +*/ + lpfc_debugfs_terminate(vport); + lpfc_sli4_hba_unset(phba); lpfc_stop_hba_timers(phba); spin_lock_irq(&phba->hbalock); -- 2.13.1
[PATCH 19/19] lpfc: Update modified files for 2018 Copyright
Updated Copyright in files updated 11.4.0.7 Signed-off-by: Dick Kennedy Signed-off-by: James Smart --- drivers/scsi/lpfc/lpfc.h | 2 +- drivers/scsi/lpfc/lpfc_attr.c | 2 +- drivers/scsi/lpfc/lpfc_crtn.h | 2 +- drivers/scsi/lpfc/lpfc_els.c | 2 +- drivers/scsi/lpfc/lpfc_hbadisc.c | 2 +- drivers/scsi/lpfc/lpfc_hw4.h | 2 +- drivers/scsi/lpfc/lpfc_init.c | 2 +- drivers/scsi/lpfc/lpfc_mbox.c | 2 +- drivers/scsi/lpfc/lpfc_mem.c | 2 +- drivers/scsi/lpfc/lpfc_nportdisc.c | 4 ++-- drivers/scsi/lpfc/lpfc_nvme.c | 2 +- drivers/scsi/lpfc/lpfc_nvmet.c | 2 +- drivers/scsi/lpfc/lpfc_nvmet.h | 2 +- drivers/scsi/lpfc/lpfc_scsi.c | 2 +- drivers/scsi/lpfc/lpfc_sli.c | 3 +-- drivers/scsi/lpfc/lpfc_sli4.h | 2 +- drivers/scsi/lpfc/lpfc_version.h | 2 +- 17 files changed, 18 insertions(+), 19 deletions(-) diff --git a/drivers/scsi/lpfc/lpfc.h b/drivers/scsi/lpfc/lpfc.h index d042f9118e3b..9698b9635058 100644 --- a/drivers/scsi/lpfc/lpfc.h +++ b/drivers/scsi/lpfc/lpfc.h @@ -1,7 +1,7 @@ /*** * This file is part of the Emulex Linux Device Driver for * * Fibre Channel Host Bus Adapters.* - * Copyright (C) 2017 Broadcom. All Rights Reserved. The term * + * Copyright (C) 2017-2018 Broadcom. All Rights Reserved. The term * * “Broadcom” refers to Broadcom Limited and/or its subsidiaries. * * Copyright (C) 2004-2016 Emulex. All rights reserved. * * EMULEX and SLI are trademarks of Emulex.* diff --git a/drivers/scsi/lpfc/lpfc_attr.c b/drivers/scsi/lpfc/lpfc_attr.c index b79dad7b8278..70bd25666243 100644 --- a/drivers/scsi/lpfc/lpfc_attr.c +++ b/drivers/scsi/lpfc/lpfc_attr.c @@ -1,7 +1,7 @@ /*** * This file is part of the Emulex Linux Device Driver for * * Fibre Channel Host Bus Adapters.* - * Copyright (C) 2017 Broadcom. All Rights Reserved. The term * + * Copyright (C) 2017-2018 Broadcom. All Rights Reserved. The term * * “Broadcom” refers to Broadcom Limited and/or its subsidiaries. * * Copyright (C) 2004-2016 Emulex. All rights reserved. * * EMULEX and SLI are trademarks of Emulex.* diff --git a/drivers/scsi/lpfc/lpfc_crtn.h b/drivers/scsi/lpfc/lpfc_crtn.h index 3ecf50df93f4..14a86b5b51e4 100644 --- a/drivers/scsi/lpfc/lpfc_crtn.h +++ b/drivers/scsi/lpfc/lpfc_crtn.h @@ -1,7 +1,7 @@ /*** * This file is part of the Emulex Linux Device Driver for * * Fibre Channel Host Bus Adapters.* - * Copyright (C) 2017 Broadcom. All Rights Reserved. The term * + * Copyright (C) 2017-2018 Broadcom. All Rights Reserved. The term * * “Broadcom” refers to Broadcom Limited and/or its subsidiaries. * * Copyright (C) 2004-2016 Emulex. All rights reserved. * * EMULEX and SLI are trademarks of Emulex.* diff --git a/drivers/scsi/lpfc/lpfc_els.c b/drivers/scsi/lpfc/lpfc_els.c index 404e1af5e2ab..ba896554a14f 100644 --- a/drivers/scsi/lpfc/lpfc_els.c +++ b/drivers/scsi/lpfc/lpfc_els.c @@ -1,7 +1,7 @@ /*** * This file is part of the Emulex Linux Device Driver for * * Fibre Channel Host Bus Adapters.* - * Copyright (C) 2017 Broadcom. All Rights Reserved. The term * + * Copyright (C) 2017-2018 Broadcom. All Rights Reserved. The term * * “Broadcom” refers to Broadcom Limited and/or its subsidiaries. * * Copyright (C) 2004-2016 Emulex. All rights reserved. * * EMULEX and SLI are trademarks of Emulex.* diff --git a/drivers/scsi/lpfc/lpfc_hbadisc.c b/drivers/scsi/lpfc/lpfc_hbadisc.c index 9265906d956e..f5bbac3cadbb 100644 --- a/drivers/scsi/lpfc/lpfc_hbadisc.c +++ b/drivers/scsi/lpfc/lpfc_hbadisc.c @@ -1,7 +1,7 @@ /*** * This file is part of the Emulex Linux Device Driver for * * Fibre Channel Host Bus Adapters.* - * Copyright (C) 2017 Broadcom. All Rights Reserved. The term * + * Copyright (C) 2017-2018 Broadcom. All Rights Reserved. The term * * “Broadcom” refers to Broadcom Limited and/or its subsidiaries. * * Copyright (C) 2004-2016 Emulex. All rights reserved. * * EMULEX and SLI are trademarks of Emulex.* diff --git a/drivers/scsi/lpfc/lpfc_hw4.h b/drivers/scsi/lpfc/lpfc_hw4.h index 52fe28ae50fa..8685d26e6929 100644 --- a/drivers/scsi/lpfc/lpfc_hw4.h +++ b/drivers/scsi/lpfc/lpfc_hw4.h @@ -1,7 +1,7 @@ /*** * This file is part of the Emul
[PATCH 15/19] lpfc: Fix header inclusion in lpfc_nvmet
The driver was inappropriately pulling in the nvme host's nvme.h header. What it really needed was the standard header. Signed-off-by: Dick Kennedy Signed-off-by: James Smart --- drivers/scsi/lpfc/lpfc_nvmet.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/scsi/lpfc/lpfc_nvmet.c b/drivers/scsi/lpfc/lpfc_nvmet.c index 0539585d32d4..f8863c51ba20 100644 --- a/drivers/scsi/lpfc/lpfc_nvmet.c +++ b/drivers/scsi/lpfc/lpfc_nvmet.c @@ -36,7 +36,7 @@ #include #include -#include <../drivers/nvme/host/nvme.h> +#include #include #include -- 2.13.1
[PATCH 16/19] lpfc: Treat SCSI Write operation Underruns as an error
Currently, write underruns (mismatch of amount transferred vs scsi
status and its residual) detected by the adapter are not being
flagged as an error. Its expected the target controls the data
transfer and would appropriately set the RSP values. Only read
underruns are treated as errors.
Revise the SCSI error handling to treat write underruns as an
error as well.
Signed-off-by: Dick Kennedy
Signed-off-by: James Smart
---
drivers/scsi/lpfc/lpfc_scsi.c | 8 +++-
1 file changed, 3 insertions(+), 5 deletions(-)
diff --git a/drivers/scsi/lpfc/lpfc_scsi.c b/drivers/scsi/lpfc/lpfc_scsi.c
index dcc86936e6fc..10c2dc0cf1fa 100644
--- a/drivers/scsi/lpfc/lpfc_scsi.c
+++ b/drivers/scsi/lpfc/lpfc_scsi.c
@@ -3772,20 +3772,18 @@ lpfc_handle_fcp_err(struct lpfc_vport *vport, struct
lpfc_scsi_buf *lpfc_cmd,
scsi_set_resid(cmnd, be32_to_cpu(fcprsp->rspResId));
lpfc_printf_vlog(vport, KERN_INFO, LOG_FCP_UNDER,
-"9025 FCP Read Underrun, expected %d, "
+"9025 FCP Underrun, expected %d, "
"residual %d Data: x%x x%x x%x\n",
fcpDl,
scsi_get_resid(cmnd), fcpi_parm, cmnd->cmnd[0],
cmnd->underflow);
/*
-* If there is an under run check if under run reported by
+* If there is an under run, check if under run reported by
* storage array is same as the under run reported by HBA.
* If this is not same, there is a dropped frame.
*/
- if ((cmnd->sc_data_direction == DMA_FROM_DEVICE) &&
- fcpi_parm &&
- (scsi_get_resid(cmnd) != fcpi_parm)) {
+ if (fcpi_parm && (scsi_get_resid(cmnd) != fcpi_parm)) {
lpfc_printf_vlog(vport, KERN_WARNING,
LOG_FCP | LOG_FCP_ERROR,
"9026 FCP Read Check Error "
--
2.13.1
[PATCH 12/19] lpfc: Indicate CONF support in NVMe PRLI
Revise the NVME PRLI to indicate CONF support.
Signed-off-by: Dick Kennedy
Signed-off-by: James Smart
---
drivers/scsi/lpfc/lpfc_els.c | 3 ++-
drivers/scsi/lpfc/lpfc_hw4.h | 6 +++---
drivers/scsi/lpfc/lpfc_nportdisc.c | 3 ---
3 files changed, 5 insertions(+), 7 deletions(-)
diff --git a/drivers/scsi/lpfc/lpfc_els.c b/drivers/scsi/lpfc/lpfc_els.c
index 234c7c015982..404e1af5e2ab 100644
--- a/drivers/scsi/lpfc/lpfc_els.c
+++ b/drivers/scsi/lpfc/lpfc_els.c
@@ -2293,10 +2293,11 @@ lpfc_issue_els_prli(struct lpfc_vport *vport, struct
lpfc_nodelist *ndlp,
if (phba->nvmet_support) {
bf_set(prli_tgt, npr_nvme, 1);
bf_set(prli_disc, npr_nvme, 1);
-
} else {
bf_set(prli_init, npr_nvme, 1);
+ bf_set(prli_conf, npr_nvme, 1);
}
+
npr_nvme->word1 = cpu_to_be32(npr_nvme->word1);
npr_nvme->word4 = cpu_to_be32(npr_nvme->word4);
elsiocb->iocb_flag |= LPFC_PRLI_NVME_REQ;
diff --git a/drivers/scsi/lpfc/lpfc_hw4.h b/drivers/scsi/lpfc/lpfc_hw4.h
index ef469129fb71..7c3afc3d3121 100644
--- a/drivers/scsi/lpfc/lpfc_hw4.h
+++ b/drivers/scsi/lpfc/lpfc_hw4.h
@@ -4346,9 +4346,9 @@ struct lpfc_nvme_prli {
#define prli_init_SHIFT 5
#define prli_init_MASK 0x0001
#define prli_init_WORD word4
-#define prli_recov_SHIFT8
-#define prli_recov_MASK 0x0001
-#define prli_recov_WORD word4
+#define prli_conf_SHIFT 7
+#define prli_conf_MASK 0x0001
+#define prli_conf_WORD word4
uint32_t word5;
#define prli_fb_sz_SHIFT0
#define prli_fb_sz_MASK 0x
diff --git a/drivers/scsi/lpfc/lpfc_nportdisc.c
b/drivers/scsi/lpfc/lpfc_nportdisc.c
index d841aa42f607..bbf1e1342b09 100644
--- a/drivers/scsi/lpfc/lpfc_nportdisc.c
+++ b/drivers/scsi/lpfc/lpfc_nportdisc.c
@@ -2011,9 +2011,6 @@ lpfc_cmpl_prli_prli_issue(struct lpfc_vport *vport,
struct lpfc_nodelist *ndlp,
}
}
- if (bf_get_be32(prli_recov, nvpr))
- ndlp->nlp_fcp_info |= NLP_FCP_2_DEVICE;
-
lpfc_printf_vlog(vport, KERN_INFO, LOG_NVME_DISC,
"6029 NVME PRLI Cmpl w1 x%08x "
"w4 x%08x w5 x%08x flag x%x, "
--
2.13.1
[PATCH 11/19] lpfc: Fix issue_lip if link is disabled
The driver ignored checks on whether the link should be kept administratively down after a link bounce. Correct the checks. Signed-off-by: Dick Kennedy Signed-off-by: James Smart --- drivers/scsi/lpfc/lpfc_attr.c | 5 + 1 file changed, 5 insertions(+) diff --git a/drivers/scsi/lpfc/lpfc_attr.c b/drivers/scsi/lpfc/lpfc_attr.c index d8064e3ea0ba..b79dad7b8278 100644 --- a/drivers/scsi/lpfc/lpfc_attr.c +++ b/drivers/scsi/lpfc/lpfc_attr.c @@ -911,7 +911,12 @@ lpfc_issue_lip(struct Scsi_Host *shost) LPFC_MBOXQ_t *pmboxq; int mbxstatus = MBXERR_ERROR; + /* +* If the link is offline, disabled or BLOCK_MGMT_IO +* it doesn't make any sense to allow issue_lip +*/ if ((vport->fc_flag & FC_OFFLINE_MODE) || + (phba->hba_flag & LINK_DISABLED) || (phba->sli.sli_flag & LPFC_BLOCK_MGMT_IO)) return -EPERM; -- 2.13.1
[PATCH 18/19] lpfc: update driver version to 11.4.0.7
Update the driver version to 11.4.0.7 Signed-off-by: Dick Kennedy Signed-off-by: James Smart --- drivers/scsi/lpfc/lpfc_version.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/scsi/lpfc/lpfc_version.h b/drivers/scsi/lpfc/lpfc_version.h index c232bf0e8998..6f4092cb903e 100644 --- a/drivers/scsi/lpfc/lpfc_version.h +++ b/drivers/scsi/lpfc/lpfc_version.h @@ -20,7 +20,7 @@ * included with this package. * ***/ -#define LPFC_DRIVER_VERSION "11.4.0.6" +#define LPFC_DRIVER_VERSION "11.4.0.7" #define LPFC_DRIVER_NAME "lpfc" /* Used for SLI 2/3 */ -- 2.13.1
[PATCH 02/19] lpfc: Increase CQ and WQ sizes for SCSI
Increased CQ and WQ sizes for SCSI FCP, matching those used
for NVMe development.
Signed-off-by: Dick Kennedy
Signed-off-by: James Smart
---
drivers/scsi/lpfc/lpfc.h | 1 +
drivers/scsi/lpfc/lpfc_hw4.h | 3 +++
drivers/scsi/lpfc/lpfc_init.c | 30 ++
drivers/scsi/lpfc/lpfc_sli.c | 3 ++-
drivers/scsi/lpfc/lpfc_sli4.h | 5 +
5 files changed, 33 insertions(+), 9 deletions(-)
diff --git a/drivers/scsi/lpfc/lpfc.h b/drivers/scsi/lpfc/lpfc.h
index 61fb46da05d4..d042f9118e3b 100644
--- a/drivers/scsi/lpfc/lpfc.h
+++ b/drivers/scsi/lpfc/lpfc.h
@@ -760,6 +760,7 @@ struct lpfc_hba {
uint8_t mds_diags_support;
uint32_t initial_imax;
uint8_t bbcredit_support;
+ uint8_t enab_exp_wqcq_pages;
/* HBA Config Parameters */
uint32_t cfg_ack0;
diff --git a/drivers/scsi/lpfc/lpfc_hw4.h b/drivers/scsi/lpfc/lpfc_hw4.h
index 73c2f6971d2b..ef469129fb71 100644
--- a/drivers/scsi/lpfc/lpfc_hw4.h
+++ b/drivers/scsi/lpfc/lpfc_hw4.h
@@ -3212,6 +3212,9 @@ struct lpfc_sli4_parameters {
#define cfg_cqv_SHIFT 14
#define cfg_cqv_MASK 0x0003
#define cfg_cqv_WORD word4
+#define cfg_cqpsize_SHIFT 16
+#define cfg_cqpsize_MASK 0x00ff
+#define cfg_cqpsize_WORD word4
uint32_t word5;
uint32_t word6;
#define cfg_mqv_SHIFT 14
diff --git a/drivers/scsi/lpfc/lpfc_init.c b/drivers/scsi/lpfc/lpfc_init.c
index f539c554588c..5b96bf0d3331 100644
--- a/drivers/scsi/lpfc/lpfc_init.c
+++ b/drivers/scsi/lpfc/lpfc_init.c
@@ -8011,9 +8011,10 @@ static int
lpfc_alloc_fcp_wq_cq(struct lpfc_hba *phba, int wqidx)
{
struct lpfc_queue *qdesc;
+ uint32_t wqesize;
/* Create Fast Path FCP CQs */
- if (phba->fcp_embed_io)
+ if (phba->enab_exp_wqcq_pages)
/* Increase the CQ size when WQEs contain an embedded cdb */
qdesc = lpfc_sli4_queue_alloc(phba, LPFC_EXPANDED_PAGE_SIZE,
phba->sli4_hba.cq_esize,
@@ -8031,15 +8032,18 @@ lpfc_alloc_fcp_wq_cq(struct lpfc_hba *phba, int wqidx)
phba->sli4_hba.fcp_cq[wqidx] = qdesc;
/* Create Fast Path FCP WQs */
- if (phba->fcp_embed_io)
/* Increase the WQ size when WQEs contain an embedded cdb */
+ if (phba->enab_exp_wqcq_pages) {
+ wqesize = (phba->fcp_embed_io) ?
+ LPFC_WQE128_SIZE : phba->sli4_hba.wq_esize;
qdesc = lpfc_sli4_queue_alloc(phba, LPFC_EXPANDED_PAGE_SIZE,
- LPFC_WQE128_SIZE,
+ wqesize,
LPFC_WQE_EXP_COUNT);
- else
+ } else {
qdesc = lpfc_sli4_queue_alloc(phba, LPFC_DEFAULT_PAGE_SIZE,
phba->sli4_hba.wq_esize,
phba->sli4_hba.wq_ecount);
+ }
if (!qdesc) {
lpfc_printf_log(phba, KERN_ERR, LOG_INIT,
"0503 Failed allocate fast-path FCP WQ (%d)\n",
@@ -10485,6 +10489,12 @@ lpfc_get_sli4_parameters(struct lpfc_hba *phba,
LPFC_MBOXQ_t *mboxq)
else
phba->fcp_embed_io = 0;
+ if ((bf_get(cfg_cqpsize, mbx_sli4_parameters) & LPFC_CQ_16K_PAGE_SZ) &&
+ (bf_get(cfg_wqpsize, mbx_sli4_parameters) & LPFC_WQ_16K_PAGE_SZ) &&
+ (sli4_params->wqsize & LPFC_WQ_SZ128_SUPPORT))
+ phba->enab_exp_wqcq_pages = 1;
+ else
+ phba->enab_exp_wqcq_pages = 0;
/*
* Check if the SLI port supports MDS Diagnostics
*/
@@ -12227,6 +12237,7 @@ int
lpfc_fof_queue_create(struct lpfc_hba *phba)
{
struct lpfc_queue *qdesc;
+ uint32_t wqesize;
/* Create FOF EQ */
qdesc = lpfc_sli4_queue_alloc(phba, LPFC_DEFAULT_PAGE_SIZE,
@@ -12240,7 +12251,7 @@ lpfc_fof_queue_create(struct lpfc_hba *phba)
if (phba->cfg_fof) {
/* Create OAS CQ */
- if (phba->fcp_embed_io)
+ if (phba->enab_exp_wqcq_pages)
qdesc = lpfc_sli4_queue_alloc(phba,
LPFC_EXPANDED_PAGE_SIZE,
phba->sli4_hba.cq_esize,
@@ -12256,16 +12267,19 @@ lpfc_fof_queue_create(struct lpfc_hba *phba)
phba->sli4_hba.oas_cq = qdesc;
/* Create OAS WQ */
- if (phba->fcp_embed_io)
+ if (phba->enab_exp_wqcq_pages) {
+ wqesize = (phba->fcp_embed_io) ?
+ LPFC_WQE128_SIZE : phba->sli4_hba.wq_esize;
qdesc = lpfc_sli4_queue_alloc(phba,
[PATCH 08/19] lpfc: Fix RQ empty firmware trap
When nvme target deferred receive logic waits for exchange
resources, the corresponding receive buffer is not replenished
with the hardware. This can result in a lack of asynchronous
receive buffer resources in the hardware, resulting in a
"2885 Port Status Event: ... error 1=0x52004a01 ..." message.
Correct by replenishing the buffer whenenver the deferred
logic kicks in. Update corresponding debug messages and
statistics as well.
Signed-off-by: Dick Kennedy
Signed-off-by: James Smart
---
drivers/scsi/lpfc/lpfc_attr.c | 6 ++
drivers/scsi/lpfc/lpfc_mem.c | 8 ++--
drivers/scsi/lpfc/lpfc_nvmet.c | 31 +--
drivers/scsi/lpfc/lpfc_nvmet.h | 7 +--
drivers/scsi/lpfc/lpfc_sli.c | 12
5 files changed, 50 insertions(+), 14 deletions(-)
diff --git a/drivers/scsi/lpfc/lpfc_attr.c b/drivers/scsi/lpfc/lpfc_attr.c
index d188fb565a32..91df2b4e9fce 100644
--- a/drivers/scsi/lpfc/lpfc_attr.c
+++ b/drivers/scsi/lpfc/lpfc_attr.c
@@ -259,6 +259,12 @@ lpfc_nvme_info_show(struct device *dev, struct
device_attribute *attr,
atomic_read(&tgtp->xmt_abort_rsp),
atomic_read(&tgtp->xmt_abort_rsp_error));
+ len += snprintf(buf + len, PAGE_SIZE - len,
+ "DELAY: ctx %08x fod %08x wqfull %08x\n",
+ atomic_read(&tgtp->defer_ctx),
+ atomic_read(&tgtp->defer_fod),
+ atomic_read(&tgtp->defer_wqfull));
+
/* Calculate outstanding IOs */
tot = atomic_read(&tgtp->rcv_fcp_cmd_drop);
tot += atomic_read(&tgtp->xmt_fcp_release);
diff --git a/drivers/scsi/lpfc/lpfc_mem.c b/drivers/scsi/lpfc/lpfc_mem.c
index 56faeb049b4a..60078e61da5e 100644
--- a/drivers/scsi/lpfc/lpfc_mem.c
+++ b/drivers/scsi/lpfc/lpfc_mem.c
@@ -755,10 +755,14 @@ lpfc_rq_buf_free(struct lpfc_hba *phba, struct
lpfc_dmabuf *mp)
if (rc < 0) {
(rqbp->rqb_free_buffer)(phba, rqb_entry);
lpfc_printf_log(phba, KERN_ERR, LOG_INIT,
- "6409 Cannot post to RQ %d: %x %x\n",
+ "6409 Cannot post to HRQ %d: %x %x %x "
+ "DRQ %x %x\n",
rqb_entry->hrq->queue_id,
rqb_entry->hrq->host_index,
- rqb_entry->hrq->hba_index);
+ rqb_entry->hrq->hba_index,
+ rqb_entry->hrq->entry_count,
+ rqb_entry->drq->host_index,
+ rqb_entry->drq->hba_index);
} else {
list_add_tail(&rqb_entry->hbuf.list, &rqbp->rqb_buffer_list);
rqbp->buffer_count++;
diff --git a/drivers/scsi/lpfc/lpfc_nvmet.c b/drivers/scsi/lpfc/lpfc_nvmet.c
index 9c2acf90212c..0539585d32d4 100644
--- a/drivers/scsi/lpfc/lpfc_nvmet.c
+++ b/drivers/scsi/lpfc/lpfc_nvmet.c
@@ -270,8 +270,6 @@ lpfc_nvmet_ctxbuf_post(struct lpfc_hba *phba, struct
lpfc_nvmet_ctxbuf *ctx_buf)
"NVMET RCV BUSY: xri x%x sz %d "
"from %06x\n",
oxid, size, sid);
- /* defer repost rcv buffer till .defer_rcv callback */
- ctxp->flag &= ~LPFC_NVMET_DEFER_RCV_REPOST;
atomic_inc(&tgtp->rcv_fcp_cmd_out);
return;
}
@@ -837,6 +835,7 @@ lpfc_nvmet_xmt_fcp_op(struct nvmet_fc_target_port *tgtport,
list_add_tail(&nvmewqeq->list, &wq->wqfull_list);
wq->q_flag |= HBA_NVMET_WQFULL;
spin_unlock_irqrestore(&pring->ring_lock, iflags);
+ atomic_inc(&lpfc_nvmep->defer_wqfull);
return 0;
}
@@ -975,11 +974,9 @@ lpfc_nvmet_defer_rcv(struct nvmet_fc_target_port *tgtport,
tgtp = phba->targetport->private;
atomic_inc(&tgtp->rcv_fcp_cmd_defer);
- if (ctxp->flag & LPFC_NVMET_DEFER_RCV_REPOST)
- lpfc_rq_buf_free(phba, &nvmebuf->hbuf); /* repost */
- else
- nvmebuf->hrq->rqbp->rqb_free_buffer(phba, nvmebuf);
- ctxp->flag &= ~LPFC_NVMET_DEFER_RCV_REPOST;
+
+ /* Free the nvmebuf since a new buffer already replaced it */
+ nvmebuf->hrq->rqbp->rqb_free_buffer(phba, nvmebuf);
}
static struct nvmet_fc_target_template lpfc_tgttemplate = {
@@ -1309,6 +1306,9 @@ lpfc_nvmet_create_targetport(struct lpfc_hba *phba)
atomic_set(&tgtp->xmt_abort_sol, 0);
atomic_set(&tgtp->xmt_abort_rsp, 0);
atomic_set(&tgtp->xmt_abort_rsp_error, 0);
+ atomic_set(&tgtp->defer_ctx, 0);
+ atomic_set(&tgtp->defer_fod, 0);
+ atomic_set(&tgtp->defer_wqfull, 0);
}
[PATCH 09/19] lpfc: Allow set of maximum outstanding SCSI cmd limit for a target parameter
Make the attribute writeable.
Remove the ramp up to logic as its unnecessary, simply set depth.
Add debug message if depth changed, possibly reducing limit, yet
our outstanding count has yet to catch up with it.
Signed-off-by: Dick Kennedy
Signed-off-by: James Smart
---
drivers/scsi/lpfc/lpfc_attr.c | 4 ++--
drivers/scsi/lpfc/lpfc_scsi.c | 39 ---
2 files changed, 30 insertions(+), 13 deletions(-)
diff --git a/drivers/scsi/lpfc/lpfc_attr.c b/drivers/scsi/lpfc/lpfc_attr.c
index 91df2b4e9fce..d8064e3ea0ba 100644
--- a/drivers/scsi/lpfc/lpfc_attr.c
+++ b/drivers/scsi/lpfc/lpfc_attr.c
@@ -3471,8 +3471,8 @@ LPFC_VPORT_ATTR_R(lun_queue_depth, 30, 1, 512,
# tgt_queue_depth: This parameter is used to limit the number of outstanding
# commands per target port. Value range is [10,65535]. Default value is 65535.
*/
-LPFC_VPORT_ATTR_R(tgt_queue_depth, 65535, 10, 65535,
- "Max number of FCP commands we can queue to a specific target
port");
+LPFC_VPORT_ATTR_RW(tgt_queue_depth, 65535, 10, 65535,
+ "Max number of FCP commands we can queue to a specific
target port");
/*
# hba_queue_depth: This parameter is used to limit the number of outstanding
diff --git a/drivers/scsi/lpfc/lpfc_scsi.c b/drivers/scsi/lpfc/lpfc_scsi.c
index c0cdaef4db24..dcc86936e6fc 100644
--- a/drivers/scsi/lpfc/lpfc_scsi.c
+++ b/drivers/scsi/lpfc/lpfc_scsi.c
@@ -3926,7 +3926,6 @@ lpfc_scsi_cmd_iocb_cmpl(struct lpfc_hba *phba, struct
lpfc_iocbq *pIocbIn,
struct lpfc_rport_data *rdata = lpfc_cmd->rdata;
struct lpfc_nodelist *pnode = rdata->pnode;
struct scsi_cmnd *cmd;
- int depth;
unsigned long flags;
struct lpfc_fast_path_event *fast_path_evt;
struct Scsi_Host *shost;
@@ -4132,16 +4131,11 @@ lpfc_scsi_cmd_iocb_cmpl(struct lpfc_hba *phba, struct
lpfc_iocbq *pIocbIn,
}
spin_unlock_irqrestore(shost->host_lock, flags);
} else if (pnode && NLP_CHK_NODE_ACT(pnode)) {
- if ((pnode->cmd_qdepth < vport->cfg_tgt_queue_depth) &&
- time_after(jiffies, pnode->last_change_time +
+ if ((pnode->cmd_qdepth != vport->cfg_tgt_queue_depth) &&
+ time_after(jiffies, pnode->last_change_time +
msecs_to_jiffies(LPFC_TGTQ_INTERVAL))) {
spin_lock_irqsave(shost->host_lock, flags);
- depth = pnode->cmd_qdepth * LPFC_TGTQ_RAMPUP_PCENT
- / 100;
- depth = depth ? depth : 1;
- pnode->cmd_qdepth += depth;
- if (pnode->cmd_qdepth > vport->cfg_tgt_queue_depth)
- pnode->cmd_qdepth = vport->cfg_tgt_queue_depth;
+ pnode->cmd_qdepth = vport->cfg_tgt_queue_depth;
pnode->last_change_time = jiffies;
spin_unlock_irqrestore(shost->host_lock, flags);
}
@@ -4564,9 +4558,32 @@ lpfc_queuecommand(struct Scsi_Host *shost, struct
scsi_cmnd *cmnd)
*/
if (!ndlp || !NLP_CHK_NODE_ACT(ndlp))
goto out_tgt_busy;
- if (atomic_read(&ndlp->cmd_pending) >= ndlp->cmd_qdepth)
+ if (atomic_read(&ndlp->cmd_pending) >= ndlp->cmd_qdepth) {
+ lpfc_printf_vlog(vport, KERN_INFO, LOG_FCP_ERROR,
+"3377 Target Queue Full, scsi Id:%d Qdepth:%d"
+" Pending command:%d"
+"
WWNN:%02x:%02x:%02x:%02x:%02x:%02x:%02x:%02x, "
+"
WWPN:%02x:%02x:%02x:%02x:%02x:%02x:%02x:%02x",
+ndlp->nlp_sid, ndlp->cmd_qdepth,
+atomic_read(&ndlp->cmd_pending),
+ndlp->nlp_nodename.u.wwn[0],
+ndlp->nlp_nodename.u.wwn[1],
+ndlp->nlp_nodename.u.wwn[2],
+ndlp->nlp_nodename.u.wwn[3],
+ndlp->nlp_nodename.u.wwn[4],
+ndlp->nlp_nodename.u.wwn[5],
+ndlp->nlp_nodename.u.wwn[6],
+ndlp->nlp_nodename.u.wwn[7],
+ndlp->nlp_portname.u.wwn[0],
+ndlp->nlp_portname.u.wwn[1],
+ndlp->nlp_portname.u.wwn[2],
+ndlp->nlp_portname.u.wwn[3],
+ndlp->nlp_portname.u.wwn[4],
+ndlp->nlp_portname.u.wwn[5],
+ndlp->nlp_portname.u.wwn[6],
+ndlp->nlp_portname.u.wwn[7]);
goto out_tgt_busy;
-
+ }
lpfc_cmd = lpfc_get_scsi_buf(phba, ndlp);
if (lpfc_cmd == NULL) {
lpf
[PATCH 04/19] lpfc: correct debug counters for abort
Existing code was using the wrong field for the completion status
when comparing whether to increment abort statistics
Signed-off-by: Dick Kennedy
Signed-off-by: James Smart
---
drivers/scsi/lpfc/lpfc_nvmet.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/scsi/lpfc/lpfc_nvmet.c b/drivers/scsi/lpfc/lpfc_nvmet.c
index 8dbf5c9d51aa..7927ac46d345 100644
--- a/drivers/scsi/lpfc/lpfc_nvmet.c
+++ b/drivers/scsi/lpfc/lpfc_nvmet.c
@@ -130,7 +130,7 @@ lpfc_nvmet_xmt_ls_rsp_cmp(struct lpfc_hba *phba, struct
lpfc_iocbq *cmdwqe,
if (tgtp) {
if (status) {
atomic_inc(&tgtp->xmt_ls_rsp_error);
- if (status == IOERR_ABORT_REQUESTED)
+ if (result == IOERR_ABORT_REQUESTED)
atomic_inc(&tgtp->xmt_ls_rsp_aborted);
if (bf_get(lpfc_wcqe_c_xb, wcqe))
atomic_inc(&tgtp->xmt_ls_rsp_xb_set);
@@ -541,7 +541,7 @@ lpfc_nvmet_xmt_fcp_op_cmp(struct lpfc_hba *phba, struct
lpfc_iocbq *cmdwqe,
rsp->transferred_length = 0;
if (tgtp) {
atomic_inc(&tgtp->xmt_fcp_rsp_error);
- if (status == IOERR_ABORT_REQUESTED)
+ if (result == IOERR_ABORT_REQUESTED)
atomic_inc(&tgtp->xmt_fcp_rsp_aborted);
}
--
2.13.1
[PATCH 01/19] lpfc: Fix frequency of Release WQE CQEs
The driver controls when the hardware sends completions that communicate consumption of elements from the WQ. This is done by setting a WQEC bit on a WQE. The current driver sets it on every Nth WQE posting. However, the driver isn't clearing the bit if the WQE is reused. Thus, if the queue depth isn't evenly divisible by N, with enough time, it can be set on every element, creating a lot of overhead and risking CQ full conditions. Correct by clearing the bit when not setting it on an Nth element. Signed-off-by: Dick Kennedy Signed-off-by: James Smart --- drivers/scsi/lpfc/lpfc_sli.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/scsi/lpfc/lpfc_sli.c b/drivers/scsi/lpfc/lpfc_sli.c index 5f5528a12308..149f21f53b13 100644 --- a/drivers/scsi/lpfc/lpfc_sli.c +++ b/drivers/scsi/lpfc/lpfc_sli.c @@ -129,6 +129,8 @@ lpfc_sli4_wq_put(struct lpfc_queue *q, union lpfc_wqe *wqe) /* set consumption flag every once in a while */ if (!((q->host_index + 1) % q->entry_repost)) bf_set(wqe_wqec, &wqe->generic.wqe_com, 1); + else + bf_set(wqe_wqec, &wqe->generic.wqe_com, 0); if (q->phba->sli3_options & LPFC_SLI4_PHWQ_ENABLED) bf_set(wqe_wqid, &wqe->generic.wqe_com, q->queue_id); lpfc_sli_pcimem_bcopy(wqe, temp_wqe, q->entry_size); -- 2.13.1
[PATCH 00/19] lpfc updates for 11.4.0.7
This patch set provides a number of fixes for the driver. The patches were cut against the Martin's 4.16/scsi-queue tree. There are no outside dependencies and are expected to be pulled via Martins tree. James Smart (19): lpfc: Fix frequency of Release WQE CQEs lpfc: Increase CQ and WQ sizes for SCSI lpfc: move placement of target destroy on driver detach lpfc: correct debug counters for abort lpfc: Add WQ Full Logic for NVME Target lpfc: Fix PRLI handling when topology type changes lpfc: Fix IO failure during hba reset testing with nvme io. lpfc: Fix RQ empty firmware trap lpfc: Allow set of maximum outstanding SCSI cmd limit for a target parameter lpfc: Fix soft lockup in lpfc worker thread during LIP testing lpfc: Fix issue_lip if link is disabled lpfc: Indicate CONF support in NVMe PRLI lpfc: Fix SCSI io host reset causing kernel crash lpfc: Validate adapter support for SRIU option lpfc: Fix header inclusion in lpfc_nvmet lpfc: Treat SCSI Write operation Underruns as an error lpfc: Fix nonrecovery of NVME controller after cable swap. lpfc: update driver version to 11.4.0.7 lpfc: Update modified files for 2018 Copyright drivers/scsi/lpfc/lpfc.h | 3 +- drivers/scsi/lpfc/lpfc_attr.c | 17 +++- drivers/scsi/lpfc/lpfc_crtn.h | 3 +- drivers/scsi/lpfc/lpfc_els.c | 5 +- drivers/scsi/lpfc/lpfc_hbadisc.c | 7 +- drivers/scsi/lpfc/lpfc_hw4.h | 14 +++- drivers/scsi/lpfc/lpfc_init.c | 63 +++ drivers/scsi/lpfc/lpfc_mbox.c | 6 +- drivers/scsi/lpfc/lpfc_mem.c | 10 ++- drivers/scsi/lpfc/lpfc_nportdisc.c | 7 +- drivers/scsi/lpfc/lpfc_nvme.c | 29 --- drivers/scsi/lpfc/lpfc_nvmet.c | 155 + drivers/scsi/lpfc/lpfc_nvmet.h | 10 ++- drivers/scsi/lpfc/lpfc_scsi.c | 49 drivers/scsi/lpfc/lpfc_sli.c | 36 - drivers/scsi/lpfc/lpfc_sli4.h | 12 ++- drivers/scsi/lpfc/lpfc_version.h | 4 +- 17 files changed, 330 insertions(+), 100 deletions(-) -- 2.13.1
RE: [PATCH 1/1] scsi: storvsc: Spread interrupts when picking a channel for I/O requests
Updated/corrected two email addresses ...
> -Original Message-
> From: Michael Kelley (EOSG)
> Sent: Wednesday, January 24, 2018 2:14 PM
> To: KY Srinivasan ; Stephen Hemminger
> ;
> martin.peter...@oracle.com; lo...@microsoft.com; jbottom...@odin.com;
> de...@linuxdriverproject.org; linux-ker...@vger.kernel.org;
> linux-scsi@vger.kernel.org
> Cc: Michael Kelley (EOSG)
> Subject: [PATCH 1/1] scsi: storvsc: Spread interrupts when picking a channel
> for I/O requests
>
> Update the algorithm in storvsc_do_io to look for a channel
> starting with the current CPU + 1 and wrap around (within the
> current NUMA node). This spreads VMbus interrupts more evenly
> across CPUs. Previous code always started with first CPU in
> the current NUMA node, skewing the interrupt load to that CPU.
>
> Signed-off-by: Michael Kelley
> ---
> drivers/scsi/storvsc_drv.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/scsi/storvsc_drv.c b/drivers/scsi/storvsc_drv.c
> index e07907d..f3264c4 100644
> --- a/drivers/scsi/storvsc_drv.c
> +++ b/drivers/scsi/storvsc_drv.c
> @@ -1310,7 +1310,8 @@ static int storvsc_do_io(struct hv_device *device,
>*/
> cpumask_and(&alloced_mask, &stor_device->alloced_cpus,
> cpumask_of_node(cpu_to_node(q_num)));
> - for_each_cpu(tgt_cpu, &alloced_mask) {
> + for_each_cpu_wrap(tgt_cpu, &alloced_mask,
> + outgoing_channel->target_cpu + 1) {
> if (tgt_cpu != outgoing_channel->target_cpu) {
> outgoing_channel =
> stor_device->stor_chns[tgt_cpu];
> --
> 1.8.3.1
[PATCH 1/1] scsi: storvsc: Spread interrupts when picking a channel for I/O requests
Update the algorithm in storvsc_do_io to look for a channel
starting with the current CPU + 1 and wrap around (within the
current NUMA node). This spreads VMbus interrupts more evenly
across CPUs. Previous code always started with first CPU in
the current NUMA node, skewing the interrupt load to that CPU.
Signed-off-by: Michael Kelley
---
drivers/scsi/storvsc_drv.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/scsi/storvsc_drv.c b/drivers/scsi/storvsc_drv.c
index e07907d..f3264c4 100644
--- a/drivers/scsi/storvsc_drv.c
+++ b/drivers/scsi/storvsc_drv.c
@@ -1310,7 +1310,8 @@ static int storvsc_do_io(struct hv_device *device,
*/
cpumask_and(&alloced_mask, &stor_device->alloced_cpus,
cpumask_of_node(cpu_to_node(q_num)));
- for_each_cpu(tgt_cpu, &alloced_mask) {
+ for_each_cpu_wrap(tgt_cpu, &alloced_mask,
+ outgoing_channel->target_cpu + 1) {
if (tgt_cpu != outgoing_channel->target_cpu) {
outgoing_channel =
stor_device->stor_chns[tgt_cpu];
--
1.8.3.1
Re: [LSF/MM TOPIC] Patch Submission process and Handling Internal Conflict
On Wed, 2018-01-24 at 19:26 +, Bart Van Assche wrote: > On Wed, 2018-01-24 at 11:05 -0800, James Bottomley wrote: > > > > 2. Handling Internal Conflict > > > > My observation here is that actually most conflict is generated by > > the review process (I know, if we increase reviews as I propose in > > 1. we'll increase conflict on the lists on the basis of this > > observation), so I've been thinking about ways to de-escalate > > it. The principle issue is that a review which doesn't just say > > the patch is fine (or fine except for nitpicks) can be taken as > > criticism and criticism is often processed personally. The way you > > phrase criticism can have a great bearing on the amount of personal > > insult taken by the other party. Corny as it sounds, the 0day bot > > response "Hi Z, I love your patch! Perhaps something to improve:" > > is specifically targetted at this problem and seems actually to > > work. I think we could all benefit from discussing how to give and > > receive criticism in the form of patch reviews responsibly, > > especially as not everyone's native language in English and certain > > common linguistic phrasings in other languages can come off as rude > > when directly translated to English (Russian springs immediately to > > mind for some reason here). Also Note, I think fixing the review > > problem would solve most of the issues, so I'm not proposing > > anything more formal like the code of conflict stuff in the main > > kernel. > > > > We could lump both of these under a single "Community Discussion" > > topic if the organizers prefer ... especially if anyone has any > > other community type issues they'd like to bring up. > > Hello James, > > How about discussing the following two additional topics during the > same or another session: > * We all want a concensus about the code and the algorithms in the > Linux > kernel. However, some contributors are not interested in trying to > strive > towards a concensus. If some contributors e.g. receive a request to > rework > their patches, if they don't like that request and if the reviewer > is > working for the same employer sometimes they try to use the > corporate > hierarchy to make the reviewer shut up. I think this is behavior > that works > against the long-term interests of the Linux kernel. Trying to intimidate people into doing what you want is a well known social tool. The particular problem here is that it's the corporate power structure that's used to effect the intimidation. That's pretty much outside of our control (unless we work for the same company), so there's not much we can do to stop it except say you shouldn't try to intimidate reviewers. I suppose one practical policy could be demanding reviews from independent (meaning outside the corporate power structure) people. > * Some other contributors are not interested in achieving a consensus > and do > not attempt to address reviewer feedback but instead keep arguing > or do what > they can to insult the reviewer. Well, I think this fits neatly in the giving and receiving and receiving criticism bucket. The first rule of interacting with others is "never attribute to malice something which could possibly be accidental". In the end it's up to the maintainer to arbitrate based on their opinion of the merits of the review. James
Re: [LSF/MM TOPIC] Patch Submission process and Handling Internal Conflict
On Wed, 2018-01-24 at 11:20 -0800, Mike Kravetz wrote: > On 01/24/2018 11:05 AM, James Bottomley wrote: > > > > I've got two community style topics, which should probably be > > discussed > > in the plenary > > > > 1. Patch Submission Process > > > > Today we don't have a uniform patch submission process across > > Storage, Filesystems and MM. The question is should we (or at > > least should we adhere to some minimal standards). The standard > > we've been trying to hold to in SCSI is one review per accepted > > non-trivial patch. For us, it's useful because it encourages > > driver writers to review each other's patches rather than just > > posting and then complaining their patch hasn't gone in. I can > > certainly think of a couple of bugs I've had to chase in mm where > > the underlying patches would have benefited from review, so I'd > > like to discuss making the one review per non-trival patch our base > > minimum standard across the whole of LSF/MM; it would certainly > > serve to improve our Reviewed-by statistics. > > Well, the mm track at least has some discussion of this last year: > https://lwn.net/Articles/718212/ The pushback in your session was mandating reviews would mean slowing patch acceptance or possibly causing the dropping of patches that couldn't get reviewed. Michal did say that XFS didn't have the problem, however there not being XFS people in the room, discussion stopped there. Having this as a plenary would allow people outside mm to describe their experiences and for us to look at process based solutions using our shared experience. James
Re: qla2xxx UBSAN warning in 4.14-rc1
On Mon, 2017-09-18 at 13:49 +0300, Meelis Roos wrote: > Hello, I decided to widen the coverage of my kernel testbed and put some > FC cards into servers. This one is a PCI-X QLA2340 in HP Proliant DL 380 > G4 (first 64-bit generation of Proliants). I got a UBSAN warning from > qla2xxx before probing for the firmware. Would it be possible for you to test the (completely untested) patch below? diff --git a/drivers/scsi/qla2xxx/qla_isr.c b/drivers/scsi/qla2xxx/qla_isr.c index 16c43bd9bb83..4cdda66a9f32 100644 --- a/drivers/scsi/qla2xxx/qla_isr.c +++ b/drivers/scsi/qla2xxx/qla_isr.c @@ -272,7 +272,7 @@ qla2x00_mbx_completion(scsi_qla_host_t *vha, uint16_t mb0) struct device_reg_2xxx __iomem *reg = &ha->iobase->isp; /* Read all mbox registers? */ - mboxes = (1 << ha->mbx_count) - 1; + mboxes = (ha->mbx_count != 32 ? 1U << ha->mbx_count : 0) - 1U; if (!ha->mcp) ql_dbg(ql_dbg_async, vha, 0x5001, "MBX pointer ERROR.\n"); else Thanks, Bart.
Re: qla2xxx UBSAN warning in 4.14-rc1
> Hello again. And again... > > > > On Sep 18, 2017, at 3:49 AM, Meelis Roos wrote: > > > > > > Hello, I decided to widen the coverage of my kernel testbed and put some > > > FC cards into servers. This one is a PCI-X QLA2340 in HP Proliant DL 380 > > > G4 (first 64-bit generation of Proliants). I got a UBSAN warning from > > > qla2xxx before probing for the firmware. > > > > > > This is reproducible with or without firmware being available. > > > > > > [3.905570] qla2xxx [:00:00.0]-0005: : QLogic Fibre Channel HBA > > > Driver: 10.00.00.01-k. > > > [3.905977] qla2xxx :06:02.0: PCI IRQ 78 -> rerouted to legacy IRQ > > > 18 > > > [3.906172] qla2xxx [:06:02.0]-001d: : Found an ISP2312 irq 18 > > > iobase 0xc9139000. > > > [...] > > > [4.180117] > > > > > > [4.180300] UBSAN: Undefined behaviour in > > > drivers/scsi/qla2xxx/qla_isr.c:275:14 > > > [4.180464] shift exponent 32 is too large for 32-bit type 'int' > > > [4.180576] CPU: 0 PID: 138 Comm: systemd-udevd Not tainted > > > 4.14.0-rc1-9-g0666f560b71b #27 > > > [4.180741] Hardware name: HP ProLiant DL380 G4, BIOS P51 07/19/2007 > > > [4.180849] Call Trace: > > > [4.180961] dump_stack+0x4e/0x6c > > > [4.181072] ubsan_epilogue+0xd/0x3b > > > [4.181179] __ubsan_handle_shift_out_of_bounds+0x112/0x14c > > > [4.181290] ? try_to_del_timer_sync+0x44/0x68 > > > [4.181440] qla2x00_mbx_completion+0x1c5/0x25d [qla2xxx] > > > [4.182683] qla2300_intr_handler+0x1ea/0x3bb [qla2xxx] > > > [4.182827] qla2x00_mailbox_command+0x77b/0x139a [qla2xxx] > > [...] > > > we’ll take a look at this > > How is it going? 4.14 is almost here but it is still unfixed? 4.15 is almost here but nothing seems to have chanmged? -- Meelis Roos (mr...@linux.ee)
Re: [LSF/MM TOPIC] Patch Submission process and Handling Internal Conflict
On Wed, 2018-01-24 at 11:05 -0800, James Bottomley wrote: > 2. Handling Internal Conflict > > My observation here is that actually most conflict is generated by the > review process (I know, if we increase reviews as I propose in 1. we'll > increase conflict on the lists on the basis of this observation), so > I've been thinking about ways to de-escalate it. The principle issue > is that a review which doesn't just say the patch is fine (or fine > except for nitpicks) can be taken as criticism and criticism is often > processed personally. The way you phrase criticism can have a great > bearing on the amount of personal insult taken by the other party. > Corny as it sounds, the 0day bot response "Hi Z, I love your patch! > Perhaps something to improve:" is specifically targetted at this > problem and seems actually to work. I think we could all benefit from > discussing how to give and receive criticism in the form of patch > reviews responsibly, especially as not everyone's native language in > English and certain common linguistic phrasings in other languages can > come off as rude when directly translated to English (Russian springs > immediately to mind for some reason here). Also Note, I think fixing > the review problem would solve most of the issues, so I'm not proposing > anything more formal like the code of conflict stuff in the main > kernel. > > We could lump both of these under a single "Community Discussion" topic > if the organizers prefer ... especially if anyone has any other > community type issues they'd like to bring up. Hello James, How about discussing the following two additional topics during the same or another session: * We all want a concensus about the code and the algorithms in the Linux kernel. However, some contributors are not interested in trying to strive towards a concensus. If some contributors e.g. receive a request to rework their patches, if they don't like that request and if the reviewer is working for the same employer sometimes they try to use the corporate hierarchy to make the reviewer shut up. I think this is behavior that works against the long-term interests of the Linux kernel. * Some other contributors are not interested in achieving a consensus and do not attempt to address reviewer feedback but instead keep arguing or do what they can to insult the reviewer. Thanks, Bart.
Re: [LSF/MM TOPIC] Patch Submission process and Handling Internal Conflict
On 01/24/2018 11:05 AM, James Bottomley wrote: > I've got two community style topics, which should probably be discussed > in the plenary > > 1. Patch Submission Process > > Today we don't have a uniform patch submission process across Storage, > Filesystems and MM. The question is should we (or at least should we > adhere to some minimal standards). The standard we've been trying to > hold to in SCSI is one review per accepted non-trivial patch. For us, > it's useful because it encourages driver writers to review each other's > patches rather than just posting and then complaining their patch > hasn't gone in. I can certainly think of a couple of bugs I've had to > chase in mm where the underlying patches would have benefited from > review, so I'd like to discuss making the one review per non-trival > patch our base minimum standard across the whole of LSF/MM; it would > certainly serve to improve our Reviewed-by statistics. Well, the mm track at least has some discussion of this last year: https://lwn.net/Articles/718212/ -- Mike Kravetz
[LSF/MM TOPIC] Patch Submission process and Handling Internal Conflict
I've got two community style topics, which should probably be discussed in the plenary 1. Patch Submission Process Today we don't have a uniform patch submission process across Storage, Filesystems and MM. The question is should we (or at least should we adhere to some minimal standards). The standard we've been trying to hold to in SCSI is one review per accepted non-trivial patch. For us, it's useful because it encourages driver writers to review each other's patches rather than just posting and then complaining their patch hasn't gone in. I can certainly think of a couple of bugs I've had to chase in mm where the underlying patches would have benefited from review, so I'd like to discuss making the one review per non-trival patch our base minimum standard across the whole of LSF/MM; it would certainly serve to improve our Reviewed-by statistics. 2. Handling Internal Conflict My observation here is that actually most conflict is generated by the review process (I know, if we increase reviews as I propose in 1. we'll increase conflict on the lists on the basis of this observation), so I've been thinking about ways to de-escalate it. The principle issue is that a review which doesn't just say the patch is fine (or fine except for nitpicks) can be taken as criticism and criticism is often processed personally. The way you phrase criticism can have a great bearing on the amount of personal insult taken by the other party. Corny as it sounds, the 0day bot response "Hi Z, I love your patch! Perhaps something to improve:" is specifically targetted at this problem and seems actually to work. I think we could all benefit from discussing how to give and receive criticism in the form of patch reviews responsibly, especially as not everyone's native language in English and certain common linguistic phrasings in other languages can come off as rude when directly translated to English (Russian springs immediately to mind for some reason here). Also Note, I think fixing the review problem would solve most of the issues, so I'm not proposing anything more formal like the code of conflict stuff in the main kernel. We could lump both of these under a single "Community Discussion" topic if the organizers prefer ... especially if anyone has any other community type issues they'd like to bring up. James
Re: [PATCH] bnx2fc: Fix check in SCSI completion handler when reqeust has already timed out.
On Wed, 2018-01-24 at 08:07 -0800, Chad Dupuis wrote: > When a request times out we set the io_req flag BNX2FC_FLAG_IO_COMPL > so > that if a subsequent completion comes in on that task ID we will > ignore > it. The issue is that in the check for this flag there is a missing > return so we will continue to process a request which may have > already > been returned to the ownership of the SCSI layer. This can cause > unpredictable results. > > Solution is to add in the missing return. > > Signed-off-by: Chad Dupuis > --- > drivers/scsi/bnx2fc/bnx2fc_io.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/drivers/scsi/bnx2fc/bnx2fc_io.c > b/drivers/scsi/bnx2fc/bnx2fc_io.c > index 8e2f767147cb..5a645b8b9af1 100644 > --- a/drivers/scsi/bnx2fc/bnx2fc_io.c > +++ b/drivers/scsi/bnx2fc/bnx2fc_io.c > @@ -1889,6 +1889,7 @@ void bnx2fc_process_scsi_cmd_compl(struct > bnx2fc_cmd *io_req, > /* we will not receive ABTS response for this IO */ > BNX2FC_IO_DBG(io_req, "Timer context finished > processing " > "this scsi cmd\n"); > + return; > } > > /* Cancel the timeout_work, as we received IO completion */ Hello This was added after the race showed up for the first issue we fixed. Its been running stable in our lab and at the customer. Reviewed-by: Laurence Oberman Tested-by: Laurence Oberman Thanks Laurence
[PATCH] bnx2fc: Fix check in SCSI completion handler when reqeust has already timed out.
When a request times out we set the io_req flag BNX2FC_FLAG_IO_COMPL so that if a subsequent completion comes in on that task ID we will ignore it. The issue is that in the check for this flag there is a missing return so we will continue to process a request which may have already been returned to the ownership of the SCSI layer. This can cause unpredictable results. Solution is to add in the missing return. Signed-off-by: Chad Dupuis --- drivers/scsi/bnx2fc/bnx2fc_io.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/scsi/bnx2fc/bnx2fc_io.c b/drivers/scsi/bnx2fc/bnx2fc_io.c index 8e2f767147cb..5a645b8b9af1 100644 --- a/drivers/scsi/bnx2fc/bnx2fc_io.c +++ b/drivers/scsi/bnx2fc/bnx2fc_io.c @@ -1889,6 +1889,7 @@ void bnx2fc_process_scsi_cmd_compl(struct bnx2fc_cmd *io_req, /* we will not receive ABTS response for this IO */ BNX2FC_IO_DBG(io_req, "Timer context finished processing " "this scsi cmd\n"); + return; } /* Cancel the timeout_work, as we received IO completion */ -- 2.12.3
[PATCH] scsi: csiostor: remove redundant assignment to pointer 'ln'
From: Colin Ian King
The pointer ln is assigned a value that is never read, it is re-assigned
a new value in the list_for_each loop hence the initialization is
redundant and can be removed.
Cleans up clang warning:
drivers/scsi/csiostor/csio_lnode.c:117:21: warning: Value stored to 'ln'
during its initialization is never read
Signed-off-by: Colin Ian King
---
drivers/scsi/csiostor/csio_lnode.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/scsi/csiostor/csio_lnode.c
b/drivers/scsi/csiostor/csio_lnode.c
index be5ee2d37815..7d81a1e7 100644
--- a/drivers/scsi/csiostor/csio_lnode.c
+++ b/drivers/scsi/csiostor/csio_lnode.c
@@ -114,7 +114,7 @@ static enum csio_ln_ev fwevt_to_lnevt[] = {
static struct csio_lnode *
csio_ln_lookup_by_portid(struct csio_hw *hw, uint8_t portid)
{
- struct csio_lnode *ln = hw->rln;
+ struct csio_lnode *ln;
struct list_head *tmp;
/* Match siblings lnode with portid */
--
2.15.1
[PATCH] scsi: ata: don't reset three times if device is offline for SAS host
In ata_eh_reset, it will reset three times at most for sata disk. For
some drivers through libsas, it calls sas_ata_hard_reset at last. When
device is gone, function sas_ata_hard_reset will return -ENODEV. But
it will still try to reset three times for offline device. This process
lasts a long time:
[11248.344323] ata13.00: status: { ERR }
[11248.344324] ata13.00: error: { ABRT }
[11248.344327] ata13: hard resetting link
[11248.503557] sas: ata: ex 500e004aaa1f phy02:U:A
attached: (no device)
[11249.359524] sas: ata13: end_device-1:0:2: reset failed
(errno=-19)[eta03d:19h:35m:17s]
[11249.365692] ata13: reset failed (errno=-19), retrying in 9 secs
[11258.451402] ata13: hard resetting linkKB/0KB/0KB /s] [0/0/0 iops][eta
03d:22h:10m:48s]
[11259.411508] sas: ata13: end_device-1:0:2: reset failed (errno=-19)[eta
03d:22h:28m:05s]
[11259.417683] ata13: reset failed (errno=-19), retrying in 10 secs
[11268.695401] ata13: hard resetting linkKB/0KB/0KB /s] [0/0/0 iops] [eta
04d:01h:03m:37s]
[11269.699513] sas: ata13: end_device-1:0:2: reset failed (errno=-19)[eta
04d:01h:20m:54s]
[11269.705689] ata13: reset failed (errno=-19), retrying in 34 secs
[11304.275393] ata13: hard resetting linkKB/0KB/0KB /s] [0/0/0 iops] [eta
04d:11h:25m:43s]
[11305.283516] sas: ata13: end_device-1:0:2: reset failed (errno=-19)[eta
04d:11h:43m:00s]
[11305.289692] ata13: reset failed, giving up
[11305.293785] ata13.00: disabled
Actually it is no need to reset three times for this scenario. So add
a check to avoid it.
Signed-off-by: Xiang Chen
---
drivers/ata/libata-eh.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/drivers/ata/libata-eh.c b/drivers/ata/libata-eh.c
index 11c3137..23a8946 100644
--- a/drivers/ata/libata-eh.c
+++ b/drivers/ata/libata-eh.c
@@ -3032,6 +3032,15 @@ int ata_eh_reset(struct ata_link *link, int classify,
goto out;
}
+ if (rc == -ENODEV && ap->flags & ATA_FLAG_SAS_HOST) {
+ ata_link_warn(failed_link,
+ "reset failed (errno=%d, device is offline for SAS
host\n)",
+ rc);
+ if (ata_is_host_link(link))
+ ata_eh_thaw_port(ap);
+ goto out;
+ }
+
now = jiffies;
if (time_before(now, deadline)) {
unsigned long delta = deadline - now;
--
1.9.1
Darlehensangebot
Schönen Tag, Sie benötigen einen echten Kredit online Ihre Rechnungen zu sichern? Startet ein neues Unternehmen? Sie benötigen einen persönlichen Kredit oder Business-Darlehen? Wir bieten ein Darlehen von € 10.000 bis € 500,000.000.00 mit 2% Zinsen pro Jahr und auch mit einem erschwinglichen Rückzahlungsbedingungen und Zustand. Ich suche für Darlehen und Projektinvestmentfonds ? Wir halten professionelle Exzellenz, unsere Definition von Exzellenz liegt in hervorragenden Kundenservice, erschwingliche Zahlung und Rückzahlung Pläne, schnell und einfach-Prozess. Hochachtungsvoll Freundliche Grüße, Herr Kelly Williams
Re: [PATCH] qla2xxx: Fix memory corruption during hba reset test
Looks good, Reviewed-by: Johannes Thumshirn -- Johannes Thumshirn Storage jthumsh...@suse.de+49 911 74053 689 SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: Felix Imendörffer, Jane Smithard, Graham Norton HRB 21284 (AG Nürnberg) Key fingerprint = EC38 9CAB C2C4 F25D 8600 D0D0 0393 969D 2D76 0850
[PATCHv3 1/4] raid_class: Add 'JBOD' RAID level
Not a real RAID level, but some HBAs support JBOD in addition to
the 'classical' RAID levels.
Signed-off-by: Hannes Reinecke
---
drivers/scsi/raid_class.c | 1 +
include/linux/raid_class.h | 1 +
2 files changed, 2 insertions(+)
diff --git a/drivers/scsi/raid_class.c b/drivers/scsi/raid_class.c
index 2c146b44d95f..ea88906d2cc5 100644
--- a/drivers/scsi/raid_class.c
+++ b/drivers/scsi/raid_class.c
@@ -157,6 +157,7 @@ static struct {
{ RAID_LEVEL_5, "raid5" },
{ RAID_LEVEL_50, "raid50" },
{ RAID_LEVEL_6, "raid6" },
+ { RAID_LEVEL_JBOD, "jbod" },
};
static const char *raid_level_name(enum raid_level level)
diff --git a/include/linux/raid_class.h b/include/linux/raid_class.h
index 31e1ff69efc8..ec8655514283 100644
--- a/include/linux/raid_class.h
+++ b/include/linux/raid_class.h
@@ -38,6 +38,7 @@ enum raid_level {
RAID_LEVEL_5,
RAID_LEVEL_50,
RAID_LEVEL_6,
+ RAID_LEVEL_JBOD,
};
struct raid_data {
--
2.12.3
[PATCHv3 0/4] Deprecate DAC960 driver
Hi all, as we're trying to get rid of the remaining request_fn drivers here's a patchset to move the DAC960 driver to the SCSI stack. As per request from hch I've split up the driver into two new SCSI drivers called 'myrb' and 'myrs'. The 'myrb' driver only supports the earlier (V1) firmware interface, which doesn't have a SCSI interface for the logical drives; for those I've added a (pretty rudimentary, admittedly) SCSI translation for them. The 'myrs' driver supports the newer (V2) firmware interface, which is SCSI based and doesn't need the translation layer. And the weird proc interface from DAC960 has been converted to sysfs attributes. Tested with eXtremeRAID 1100 (for V1 Firmware) and Mylex AcceleRAID 170 (for V2 Firmware). Changes to v2: - Move to dma_pool API - Fixup 0-day build issues - Add myrb_biosparam - Dropped patch merged with upstream Changes to v1: - Split into two drivers - Improve scanning for V1 firmware interface Hannes Reinecke (4): raid_class: Add 'JBOD' RAID level myrb: Add Mylex RAID controller (block interface) myrs: Add Mylex RAID controller (SCSI interface) drivers/block: Remove DAC960 driver Documentation/blockdev/README.DAC960 | 756 drivers/block/DAC960.c | 7244 -- drivers/block/DAC960.h | 4415 - drivers/block/Kconfig| 12 - drivers/block/Makefile |1 - drivers/scsi/Kconfig | 30 + drivers/scsi/Makefile|2 + drivers/scsi/myrb.c | 3263 +++ drivers/scsi/myrb.h | 1891 + drivers/scsi/myrs.c | 2950 ++ drivers/scsi/myrs.h | 2042 ++ drivers/scsi/raid_class.c|1 + include/linux/raid_class.h |1 + 13 files changed, 10180 insertions(+), 12428 deletions(-) delete mode 100644 Documentation/blockdev/README.DAC960 delete mode 100644 drivers/block/DAC960.c delete mode 100644 drivers/block/DAC960.h create mode 100644 drivers/scsi/myrb.c create mode 100644 drivers/scsi/myrb.h create mode 100644 drivers/scsi/myrs.c create mode 100644 drivers/scsi/myrs.h -- 2.12.3
