Re: [SCSI] csiostor: Chelsio FCoE offload driver
On 2/6/2013 6:39 PM, Dan Carpenter wrote:
> Hopefully, you recieved an email about this last November, but this
> is a follow up because the bug is still there.
>
I don't recollect getting that email. Thanks for reporting nevertheless.
There are some patches lined up for supporting new features and some bug
fixes. I will ensure those patches address the issues you have reported.
Thanks,
Naresh.
> Smatch complains about a buffer overflow in this:
>
> drivers/scsi/csiostor/csio_rnode.c:872 csio_rnode_fwevt_handler()
> error: buffer overflow '(rn)->stats.n_evt_fw' 22 <= 26
>
>859 void
>860 csio_rnode_fwevt_handler(struct csio_rnode *rn, uint8_t fwevt)
>861 {
>862 struct csio_lnode *ln = csio_rnode_to_lnode(rn);
>863 enum csio_rn_ev evt;
>864
>865 evt = CSIO_FWE_TO_RNFE(fwevt);
>866 if (!evt) {
>
> Events greater than PROTO_ERR_IMPL_LOGO are invalid.
>
>867 csio_ln_err(ln, "ssni:x%x Unhandled FW Rdev event:
> %d\n",
>868 csio_rn_flowid(rn), fwevt);
>869 CSIO_INC_STATS(rn, n_evt_unexp);
>870 return;
>871 }
>872 CSIO_INC_STATS(rn, n_evt_fw[fwevt]);
>
> It looks like new events were added and the size of the n_evt_fw[]
> array wasn't updated to hold them. Everything after RSCN_DEV_LOST
> causes memory corruption.
>
>RSCN_DEV_LOST = 0x16,
>SCR_ACC_RCVD= 0x17,
>ADISC_RJT_RCVD = 0x18,
>LOGO_SNT= 0x19,
>PROTO_ERR_IMPL_LOGO = 0x1a,
>
> There is a related bug in the lnode version of this code which
> Smatch does not catch.
>
> drivers/scsi/csiostor/csio_lnode.c
> 1555 /* save previous event for debugging */
> 1556 ln->prev_evt = ln->cur_evt;
> 1557 ln->cur_evt = rdev_wr->event_cause;
> 1558 CSIO_INC_STATS(ln,
> n_evt_fw[rdev_wr->event_cause]);
>
> ^^
> Memory corruption.
>
> 1559
> 1560 /* Translate all the fabric events to lnode
> SM events */
> 1561 evt = CSIO_FWE_TO_LNE(rdev_wr->event_cause);
> 1562 if (evt) {
>
> Valid events handled here but we already corrupted memory three
> lines earlier.
>
> 1563 csio_ln_dbg(ln,
> 1564 "Posting event to lnode
> event:%d "
> 1565 "cause:%d flowid:x%x\n", evt,
> 1566 rdev_wr->event_cause,
> rdev_flowid);
> 1567 csio_post_event(&ln->sm, evt);
> 1568 }
> 1569
>
> I wasn't a part of the discussion in November, but the fix for this
> seems trivial. I'm probably missing something?
>
> 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 06/23] qla2xxx: Update the FTP site references in the driver sources.
From: Giridhar Malavali Signed-off-by: Giridhar Malavali Signed-off-by: Saurav Kashyap --- drivers/scsi/qla2xxx/qla_init.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/scsi/qla2xxx/qla_init.c b/drivers/scsi/qla2xxx/qla_init.c index a581c85..bbf5688 100644 --- a/drivers/scsi/qla2xxx/qla_init.c +++ b/drivers/scsi/qla2xxx/qla_init.c @@ -5054,7 +5054,7 @@ qla24xx_load_risc_flash(scsi_qla_host_t *vha, uint32_t *srisc_addr, return rval; } -#define QLA_FW_URL "ftp://ftp.qlogic.com/outgoing/linux/firmware/"; +#define QLA_FW_URL "http://ldriver.qlogic.com/firmware/"; int qla2x00_load_risc(scsi_qla_host_t *vha, uint32_t *srisc_addr) -- 1.7.7 -- 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 03/23] qla2xxx: Avoid null pointer dereference in shutdown routine.
From: Masanari Iida Signed-off-by: Masanari Iida Signed-off-by: Saurav Kashyap --- drivers/scsi/qla2xxx/qla_os.c |3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) diff --git a/drivers/scsi/qla2xxx/qla_os.c b/drivers/scsi/qla2xxx/qla_os.c index 0612d25..9e3ae1d 100644 --- a/drivers/scsi/qla2xxx/qla_os.c +++ b/drivers/scsi/qla2xxx/qla_os.c @@ -2808,6 +2808,9 @@ qla2x00_shutdown(struct pci_dev *pdev) scsi_qla_host_t *vha; struct qla_hw_data *ha; + if (!atomic_read(&pdev->enable_cnt)) + return; + vha = pci_get_drvdata(pdev); ha = vha->hw; -- 1.7.7 -- 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 05/23] qla2xxx: Reject loopback request if one is already in progress.
From: Chad Dupuis
If another function on the port has initiated a loopback operation do not
process the current request.
Signed-off-by: Chad Dupuis
Signed-off-by: Saurav Kashyap
---
drivers/scsi/qla2xxx/qla_bsg.c |8
drivers/scsi/qla2xxx/qla_dbg.c |2 +-
2 files changed, 9 insertions(+), 1 deletions(-)
diff --git a/drivers/scsi/qla2xxx/qla_bsg.c b/drivers/scsi/qla2xxx/qla_bsg.c
index f7cb6a3..5b49766 100644
--- a/drivers/scsi/qla2xxx/qla_bsg.c
+++ b/drivers/scsi/qla2xxx/qla_bsg.c
@@ -746,6 +746,14 @@ qla2x00_process_loopback(struct fc_bsg_job *bsg_job)
goto done_free_dma_rsp;
}
+ if ((config[0] & INTERNAL_LOOPBACK_MASK) != 0) {
+ ql_dbg(ql_dbg_user, vha, 0x70c4,
+ "Loopback operation already in "
+ "progress.\n");
+ rval = -EAGAIN;
+ goto done_free_dma_rsp;
+ }
+
ql_dbg(ql_dbg_user, vha, 0x70c0,
"elreq.options=%04x\n", elreq.options);
diff --git a/drivers/scsi/qla2xxx/qla_dbg.c b/drivers/scsi/qla2xxx/qla_dbg.c
index af045ed..c1d2310 100644
--- a/drivers/scsi/qla2xxx/qla_dbg.c
+++ b/drivers/scsi/qla2xxx/qla_dbg.c
@@ -24,7 +24,7 @@
* | Async Events | 0x5071 | 0x502b-0x502f |
* | || 0x5047,0x5052 |
* | Timer Routines | 0x6011 ||
- * | User Space Interactions | 0x70c3 | 0x7018,0x702e, |
+ * | User Space Interactions | 0x70c4 | 0x7018,0x702e, |
* | || 0x7020,0x7024, |
* | || 0x7039,0x7045, |
* | || 0x7073-0x7075, |
--
1.7.7
--
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 17/23] qla2xxx: Correct list-iteration bug in Report-ID Acquisition codes.
From: Andrew Vasquez
Code in qla24xx_report_id_acquisition() incorrectly assumed that
upon completion of list iteration (with no match), the 'pos'
(vp) variable passed to list_for_each_entry() would be set to
NULL. In this context, if the firmware were to return an
unrecognized vp_idx, the follow-on assignments to vp-members
could result in corruption of the structure.
Signed-off-by: Andrew Vasquez
Signed-off-by: Saurav Kashyap
---
drivers/scsi/qla2xxx/qla_mbx.c | 11 ---
1 files changed, 8 insertions(+), 3 deletions(-)
diff --git a/drivers/scsi/qla2xxx/qla_mbx.c b/drivers/scsi/qla2xxx/qla_mbx.c
index 2b6782d..dc0fe52 100644
--- a/drivers/scsi/qla2xxx/qla_mbx.c
+++ b/drivers/scsi/qla2xxx/qla_mbx.c
@@ -3141,6 +3141,7 @@ qla24xx_report_id_acquisition(scsi_qla_host_t *vha,
struct qla_hw_data *ha = vha->hw;
scsi_qla_host_t *vp;
unsigned long flags;
+ int found;
ql_dbg(ql_dbg_mbx + ql_dbg_verbose, vha, 0x10b6,
"Entered %s.\n", __func__);
@@ -3176,13 +3177,17 @@ qla24xx_report_id_acquisition(scsi_qla_host_t *vha,
return;
}
+ found = 0;
spin_lock_irqsave(&ha->vport_slock, flags);
- list_for_each_entry(vp, &ha->vp_list, list)
- if (vp_idx == vp->vp_idx)
+ list_for_each_entry(vp, &ha->vp_list, list) {
+ if (vp_idx == vp->vp_idx) {
+ found = 1;
break;
+ }
+ }
spin_unlock_irqrestore(&ha->vport_slock, flags);
- if (!vp)
+ if (!found)
return;
vp->d_id.b.domain = rptid_entry->port_id[2];
--
1.7.7
--
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 09/23] qla2xxx: Unload hangs after issuing BSG commands to vport.
From: Chad Dupuis
BSG code path increments ref count in the send path, but does not
decrement in the return path leading to hang during unload of the
driver.
Signed-off-by: Chad Dupuis
Signed-off-by: Saurav Kashyap
---
drivers/scsi/qla2xxx/qla_bsg.c| 10 +-
drivers/scsi/qla2xxx/qla_init.c |4 +---
drivers/scsi/qla2xxx/qla_inline.h |7 +++
drivers/scsi/qla2xxx/qla_os.c |4 ++--
4 files changed, 15 insertions(+), 10 deletions(-)
diff --git a/drivers/scsi/qla2xxx/qla_bsg.c b/drivers/scsi/qla2xxx/qla_bsg.c
index 525c339..79babab 100644
--- a/drivers/scsi/qla2xxx/qla_bsg.c
+++ b/drivers/scsi/qla2xxx/qla_bsg.c
@@ -27,7 +27,7 @@ void
qla2x00_bsg_sp_free(void *data, void *ptr)
{
srb_t *sp = (srb_t *)ptr;
- struct scsi_qla_host *vha = (scsi_qla_host_t *)data;
+ struct scsi_qla_host *vha = sp->fcport->vha;
struct fc_bsg_job *bsg_job = sp->u.bsg_job;
struct qla_hw_data *ha = vha->hw;
@@ -40,7 +40,7 @@ qla2x00_bsg_sp_free(void *data, void *ptr)
if (sp->type == SRB_CT_CMD ||
sp->type == SRB_ELS_CMD_HST)
kfree(sp->fcport);
- mempool_free(sp, vha->hw->srb_mempool);
+ qla2x00_rel_sp(vha, sp);
}
int
@@ -368,7 +368,7 @@ qla2x00_process_els(struct fc_bsg_job *bsg_job)
if (rval != QLA_SUCCESS) {
ql_log(ql_log_warn, vha, 0x700e,
"qla2x00_start_sp failed = %d\n", rval);
- mempool_free(sp, ha->srb_mempool);
+ qla2x00_rel_sp(vha, sp);
rval = -EIO;
goto done_unmap_sg;
}
@@ -515,7 +515,7 @@ qla2x00_process_ct(struct fc_bsg_job *bsg_job)
if (rval != QLA_SUCCESS) {
ql_log(ql_log_warn, vha, 0x7017,
"qla2x00_start_sp failed=%d.\n", rval);
- mempool_free(sp, ha->srb_mempool);
+ qla2x00_rel_sp(vha, sp);
rval = -EIO;
goto done_free_fcport;
}
@@ -1995,6 +1995,6 @@ done:
spin_unlock_irqrestore(&ha->hardware_lock, flags);
if (bsg_job->request->msgcode == FC_BSG_HST_CT)
kfree(sp->fcport);
- mempool_free(sp, ha->srb_mempool);
+ qla2x00_rel_sp(vha, sp);
return 0;
}
diff --git a/drivers/scsi/qla2xxx/qla_init.c b/drivers/scsi/qla2xxx/qla_init.c
index 97f2684..7568324 100644
--- a/drivers/scsi/qla2xxx/qla_init.c
+++ b/drivers/scsi/qla2xxx/qla_init.c
@@ -70,9 +70,7 @@ qla2x00_sp_free(void *data, void *ptr)
struct scsi_qla_host *vha = (scsi_qla_host_t *)data;
del_timer(&iocb->timer);
- mempool_free(sp, vha->hw->srb_mempool);
-
- QLA_VHA_MARK_NOT_BUSY(vha);
+ qla2x00_rel_sp(vha, sp);
}
/* Asynchronous Login/Logout Routines -- */
diff --git a/drivers/scsi/qla2xxx/qla_inline.h
b/drivers/scsi/qla2xxx/qla_inline.h
index deb8618..130f6f3 100644
--- a/drivers/scsi/qla2xxx/qla_inline.h
+++ b/drivers/scsi/qla2xxx/qla_inline.h
@@ -198,6 +198,13 @@ done:
}
static inline void
+qla2x00_rel_sp(scsi_qla_host_t *vha, srb_t *sp)
+{
+ mempool_free(sp, vha->hw->srb_mempool);
+ QLA_VHA_MARK_NOT_BUSY(vha);
+}
+
+static inline void
qla2x00_init_timer(srb_t *sp, unsigned long tmo)
{
init_timer(&sp->u.iocb_cmd.timer);
diff --git a/drivers/scsi/qla2xxx/qla_os.c b/drivers/scsi/qla2xxx/qla_os.c
index 9e3ae1d..33fb217 100644
--- a/drivers/scsi/qla2xxx/qla_os.c
+++ b/drivers/scsi/qla2xxx/qla_os.c
@@ -630,7 +630,7 @@ qla2x00_sp_free_dma(void *vha, void *ptr)
}
CMD_SP(cmd) = NULL;
- mempool_free(sp, ha->srb_mempool);
+ qla2x00_rel_sp(sp->fcport->vha, sp);
}
static void
@@ -718,7 +718,7 @@ qla2xxx_queuecommand(struct Scsi_Host *host, struct
scsi_cmnd *cmd)
goto qc24_target_busy;
}
- sp = qla2x00_get_sp(base_vha, fcport, GFP_ATOMIC);
+ sp = qla2x00_get_sp(vha, fcport, GFP_ATOMIC);
if (!sp) {
set_bit(HOST_RAMP_DOWN_QUEUE_DEPTH, &vha->dpc_flags);
goto qc24_host_busy;
--
1.7.7
--
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 07/23] qla2xxx: Do link initialization on get loop id failure.
From: Joe Carnuccio
To avoid continually doing ISP resets when get loop id fails to
obtain the adapter loop id, first try to do a link initialization.
Signed-off-by: Joe Carnuccio
Signed-off-by: Saurav Kashyap
---
drivers/scsi/qla2xxx/qla_dbg.c |2 +-
drivers/scsi/qla2xxx/qla_def.h |1 +
drivers/scsi/qla2xxx/qla_gbl.h |3 ++
drivers/scsi/qla2xxx/qla_init.c |8 ++
drivers/scsi/qla2xxx/qla_mbx.c | 48 +++
5 files changed, 61 insertions(+), 1 deletions(-)
diff --git a/drivers/scsi/qla2xxx/qla_dbg.c b/drivers/scsi/qla2xxx/qla_dbg.c
index c1d2310..65e95bd 100644
--- a/drivers/scsi/qla2xxx/qla_dbg.c
+++ b/drivers/scsi/qla2xxx/qla_dbg.c
@@ -12,7 +12,7 @@
* | Level| Last Value Used | Holes |
* --
* | Module Init and Probe| 0x0126 | 0x4b,0xba,0xfa |
- * | Mailbox commands | 0x1150 | 0x111a-0x111b |
+ * | Mailbox commands | 0x1154 | 0x111a-0x111b |
* | || 0x112c-0x112e |
* | || 0x113a |
* | Device Discovery | 0x2087 | 0x2020-0x2022, |
diff --git a/drivers/scsi/qla2xxx/qla_def.h b/drivers/scsi/qla2xxx/qla_def.h
index 5c42c91..e96abfc 100644
--- a/drivers/scsi/qla2xxx/qla_def.h
+++ b/drivers/scsi/qla2xxx/qla_def.h
@@ -814,6 +814,7 @@ typedef struct {
#define MBC_HOST_MEMORY_COPY 0x53/* Host Memory Copy. */
#define MBC_SEND_RNFT_ELS 0x5e/* Send RNFT ELS request */
#define MBC_GET_LINK_PRIV_STATS0x6d/* Get link & private
data. */
+#define MBC_LINK_INITIALIZATION0x72/* Do link
initialization. */
#define MBC_SET_VENDOR_ID 0x76/* Set Vendor ID. */
#define MBC_PORT_RESET 0x120 /* Port Reset */
#define MBC_SET_PORT_CONFIG0x122 /* Set port configuration */
diff --git a/drivers/scsi/qla2xxx/qla_gbl.h b/drivers/scsi/qla2xxx/qla_gbl.h
index 1732713..ee8ea95 100644
--- a/drivers/scsi/qla2xxx/qla_gbl.h
+++ b/drivers/scsi/qla2xxx/qla_gbl.h
@@ -282,6 +282,9 @@ extern int
qla2x00_get_port_name(scsi_qla_host_t *, uint16_t, uint8_t *, uint8_t);
extern int
+qla24xx_link_initialize(scsi_qla_host_t *);
+
+extern int
qla2x00_lip_reset(scsi_qla_host_t *);
extern int
diff --git a/drivers/scsi/qla2xxx/qla_init.c b/drivers/scsi/qla2xxx/qla_init.c
index bbf5688..97f2684 100644
--- a/drivers/scsi/qla2xxx/qla_init.c
+++ b/drivers/scsi/qla2xxx/qla_init.c
@@ -2207,6 +2207,7 @@ qla2x00_configure_hba(scsi_qla_host_t *vha)
charconnect_type[22];
struct qla_hw_data *ha = vha->hw;
unsigned long flags;
+ scsi_qla_host_t *base_vha = pci_get_drvdata(ha->pdev);
/* Get host addresses. */
rval = qla2x00_get_adapter_id(vha,
@@ -2220,6 +2221,13 @@ qla2x00_configure_hba(scsi_qla_host_t *vha)
} else {
ql_log(ql_log_warn, vha, 0x2009,
"Unable to get host loop ID.\n");
+ if (IS_FWI2_CAPABLE(ha) && (vha == base_vha) &&
+ (rval == QLA_COMMAND_ERROR && loop_id == 0x1b)) {
+ ql_log(ql_log_warn, vha, 0x1151,
+ "Doing link init.\n");
+ if (qla24xx_link_initialize(vha) == QLA_SUCCESS)
+ return rval;
+ }
set_bit(ISP_ABORT_NEEDED, &vha->dpc_flags);
}
return (rval);
diff --git a/drivers/scsi/qla2xxx/qla_mbx.c b/drivers/scsi/qla2xxx/qla_mbx.c
index 92d51fc..550f75a 100644
--- a/drivers/scsi/qla2xxx/qla_mbx.c
+++ b/drivers/scsi/qla2xxx/qla_mbx.c
@@ -1633,6 +1633,54 @@ qla2x00_get_port_name(scsi_qla_host_t *vha, uint16_t
loop_id, uint8_t *name,
}
/*
+ * qla24xx_link_initialization
+ * Issue link initialization mailbox command.
+ *
+ * Input:
+ * ha = adapter block pointer.
+ * TARGET_QUEUE_LOCK must be released.
+ * ADAPTER_STATE_LOCK must be released.
+ *
+ * Returns:
+ * qla2x00 local function return status code.
+ *
+ * Context:
+ * Kernel context.
+ */
+int
+qla24xx_link_initialize(scsi_qla_host_t *vha)
+{
+ int rval;
+ mbx_cmd_t mc;
+ mbx_cmd_t *mcp = &mc;
+
+ ql_dbg(ql_dbg_mbx + ql_dbg_verbose, vha, 0x1152,
+ "Entered %s.\n", __func__);
+
+ if (!IS_FWI2_CAPABLE(vha->hw) || IS_CNA_CAPABLE(vha->hw))
+ return QLA_FUNCTION_FAILED;
+
+ mcp->mb[0] = MBC_LINK_INITIALIZATION;
+ mcp->mb[1] = BIT_6|BIT_4;
+ mcp->mb[2] = 0;
+ mcp->mb[3] = 0;
+ mcp->out_mb = MBX_3|MBX_2|MBX_1|MBX_0;
+ mcp->in_mb = MBX_0;
+ mcp->tov = MBX_TOV_SECONDS;
+ mcp->flags = 0;
+ rval =
[PATCH 12/23] qla2xxx: Display the lock owner on lock acquire failure.
Signed-off-by: Giridhar Malavali
Signed-off-by: Saurav Kashyap
---
drivers/scsi/qla2xxx/qla_dbg.c |2 +-
drivers/scsi/qla2xxx/qla_nx.c |9 -
drivers/scsi/qla2xxx/qla_os.c |8 +++-
3 files changed, 16 insertions(+), 3 deletions(-)
diff --git a/drivers/scsi/qla2xxx/qla_dbg.c b/drivers/scsi/qla2xxx/qla_dbg.c
index 65e95bd..29101fe 100644
--- a/drivers/scsi/qla2xxx/qla_dbg.c
+++ b/drivers/scsi/qla2xxx/qla_dbg.c
@@ -36,7 +36,7 @@
* | || 0x800b,0x8039 |
* | AER/EEH | 0x9011 | |
* | Virtual Port | 0xa007 | |
- * | ISP82XX Specific | 0xb084 | 0xb002,0xb024 |
+ * | ISP82XX Specific | 0xb086 | 0xb002,0xb024 |
* | MultiQ | 0xc00c | |
* | Misc | 0xd010 | |
* | Target Mode | 0xe070 ||
diff --git a/drivers/scsi/qla2xxx/qla_nx.c b/drivers/scsi/qla2xxx/qla_nx.c
index 042368b..dc4be5b 100644
--- a/drivers/scsi/qla2xxx/qla_nx.c
+++ b/drivers/scsi/qla2xxx/qla_nx.c
@@ -847,14 +847,21 @@ static int
qla82xx_rom_lock(struct qla_hw_data *ha)
{
int done = 0, timeout = 0;
+ uint32_t lock_owner = 0;
+ scsi_qla_host_t *vha = pci_get_drvdata(ha->pdev);
while (!done) {
/* acquire semaphore2 from PCI HW block */
done = qla82xx_rd_32(ha, QLA82XX_PCIE_REG(PCIE_SEM2_LOCK));
if (done == 1)
break;
- if (timeout >= qla82xx_rom_lock_timeout)
+ if (timeout >= qla82xx_rom_lock_timeout) {
+ lock_owner = qla82xx_rd_32(ha, QLA82XX_ROM_LOCK_ID);
+ ql_dbg(ql_dbg_p3p, vha, 0xb085,
+ "Failed to acquire rom lock, acquired by %d.\n",
+ lock_owner);
return -1;
+ }
timeout++;
}
qla82xx_wr_32(ha, QLA82XX_ROM_LOCK_ID, ROM_LOCK_DRIVER);
diff --git a/drivers/scsi/qla2xxx/qla_os.c b/drivers/scsi/qla2xxx/qla_os.c
index 33fb217..a947f70 100644
--- a/drivers/scsi/qla2xxx/qla_os.c
+++ b/drivers/scsi/qla2xxx/qla_os.c
@@ -4065,6 +4065,8 @@ qla83xx_force_lock_recovery(scsi_qla_host_t *base_vha)
uint32_t idc_lck_rcvry_stage_mask = 0x3;
uint32_t idc_lck_rcvry_owner_mask = 0x3c;
struct qla_hw_data *ha = base_vha->hw;
+ ql_dbg(ql_dbg_p3p, base_vha, 0xb086,
+ "Trying force recovery of the IDC lock.\n");
rval = qla83xx_rd_reg(base_vha, QLA83XX_IDC_LOCK_RECOVERY, &data);
if (rval)
@@ -4156,6 +4158,7 @@ qla83xx_idc_lock(scsi_qla_host_t *base_vha, uint16_t
requester_id)
{
uint16_t options = (requester_id << 15) | BIT_6;
uint32_t data;
+ uint32_t lock_owner;
struct qla_hw_data *ha = base_vha->hw;
/* IDC-lock implementation using driver-lock/lock-id remote registers */
@@ -4167,8 +4170,11 @@ retry_lock:
qla83xx_wr_reg(base_vha, QLA83XX_DRIVER_LOCKID,
ha->portnum);
} else {
+ qla83xx_rd_reg(base_vha, QLA83XX_DRIVER_LOCKID,
+ &lock_owner);
ql_dbg(ql_dbg_p3p, base_vha, 0xb063,
- "Failed to acquire IDC lock. retrying...\n");
+ "Failed to acquire IDC lock, acquired by %d, "
+ "retrying...\n", lock_owner);
/* Retry/Perform IDC-Lock recovery */
if (qla83xx_idc_lock_recovery(base_vha)
--
1.7.7
--
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 10/23] qla2xxx: Extra loopback error handling for ISP83xx.
From: Chad Dupuis
Add the following error handling for loopback diagnostic mode with ISP83xx:
1. If we do not receive an MBA_DCBX_COMPLETE after our initial set port
configuration command, try to reset the port back into normal operation.
If that fails, take a FCoE dump and then reset the chip.
2. After completing the loopback diagnostic operation, if the reset of the port
back into normal operation fails then reset the port so we take a FCoE dump
and then reset the chip.
3. When we receive an IDC notification and the requested operation is loopback
extend the loop down timer so the link does not appear to down for an
extended period of time.
Signed-off-by: Chad Dupuis
Signed-off-by: Saurav Kashyap
---
drivers/scsi/qla2xxx/qla_bsg.c | 127 +++
drivers/scsi/qla2xxx/qla_isr.c | 16 -
2 files changed, 87 insertions(+), 56 deletions(-)
diff --git a/drivers/scsi/qla2xxx/qla_bsg.c b/drivers/scsi/qla2xxx/qla_bsg.c
index 79babab..5478fff 100644
--- a/drivers/scsi/qla2xxx/qla_bsg.c
+++ b/drivers/scsi/qla2xxx/qla_bsg.c
@@ -531,6 +531,58 @@ done_unmap_sg:
done:
return rval;
}
+
+/* Disable loopback mode */
+static inline int
+qla81xx_reset_loopback_mode(scsi_qla_host_t *vha, uint16_t *config,
+int wait)
+{
+ int ret = 0;
+ int rval = 0;
+ uint16_t new_config[4];
+ struct qla_hw_data *ha = vha->hw;
+
+ if (!IS_QLA81XX(ha) && !IS_QLA8031(ha))
+ goto done_reset_internal;
+
+ memset(new_config, 0 , sizeof(new_config));
+ if ((config[0] & INTERNAL_LOOPBACK_MASK) >> 1 ==
+ ENABLE_INTERNAL_LOOPBACK ||
+ (config[0] & INTERNAL_LOOPBACK_MASK) >> 1 ==
+ ENABLE_EXTERNAL_LOOPBACK) {
+ new_config[0] = config[0] & ~INTERNAL_LOOPBACK_MASK;
+ ql_dbg(ql_dbg_user, vha, 0x70bf, "new_config[0]=%02x\n",
+ (new_config[0] & INTERNAL_LOOPBACK_MASK));
+ memcpy(&new_config[1], &config[1], sizeof(uint16_t) * 3) ;
+
+ ha->notify_dcbx_comp = wait;
+ ret = qla81xx_set_port_config(vha, new_config);
+ if (ret != QLA_SUCCESS) {
+ ql_log(ql_log_warn, vha, 0x7025,
+ "Set port config failed.\n");
+ ha->notify_dcbx_comp = 0;
+ rval = -EINVAL;
+ goto done_reset_internal;
+ }
+
+ /* Wait for DCBX complete event */
+ if (wait && !wait_for_completion_timeout(&ha->dcbx_comp,
+ (20 * HZ))) {
+ ql_dbg(ql_dbg_user, vha, 0x7026,
+ "State change notification not received.\n");
+ ha->notify_dcbx_comp = 0;
+ rval = -EINVAL;
+ goto done_reset_internal;
+ } else
+ ql_dbg(ql_dbg_user, vha, 0x7027,
+ "State change received.\n");
+
+ ha->notify_dcbx_comp = 0;
+ }
+done_reset_internal:
+ return rval;
+}
+
/*
* Set the port configuration to enable the internal or external loopback
* depending on the loopback mode.
@@ -569,6 +621,15 @@ qla81xx_set_loopback_mode(scsi_qla_host_t *vha, uint16_t
*config,
if (!wait_for_completion_timeout(&ha->dcbx_comp, (20 * HZ))) {
ql_dbg(ql_dbg_user, vha, 0x7022,
"State change notification not received.\n");
+ ret = qla81xx_reset_loopback_mode(vha, new_config, 0);
+ /*
+* If the reset of the loopback mode doesn't work take a FCoE
+* dump and reset the chip.
+*/
+ if (ret) {
+ ha->isp_ops->fw_dump(vha, 0);
+ set_bit(ISP_ABORT_NEEDED, &vha->dpc_flags);
+ }
rval = -EINVAL;
} else {
if (ha->flags.idc_compl_status) {
@@ -587,57 +648,6 @@ done_set_internal:
return rval;
}
-/* Disable loopback mode */
-static inline int
-qla81xx_reset_loopback_mode(scsi_qla_host_t *vha, uint16_t *config,
-int wait)
-{
- int ret = 0;
- int rval = 0;
- uint16_t new_config[4];
- struct qla_hw_data *ha = vha->hw;
-
- if (!IS_QLA81XX(ha) && !IS_QLA8031(ha))
- goto done_reset_internal;
-
- memset(new_config, 0 , sizeof(new_config));
- if ((config[0] & INTERNAL_LOOPBACK_MASK) >> 1 ==
- ENABLE_INTERNAL_LOOPBACK ||
- (config[0] & INTERNAL_LOOPBACK_MASK) >> 1 ==
- ENABLE_EXTERNAL_LOOPBACK) {
- new_config[0] = config[0] & ~INTERNAL_LOOPBACK_MASK;
- ql_dbg(ql_dbg_user, vha, 0x70bf, "new_config[0]=%02x\n",
- (new_config[0] & INTERNAL_LOOPBACK_MASK));
- memcpy(&new_config[1], &config[1], sizeof(uint16_t) * 3) ;
-
- ha->notify_dcbx_comp = wait;
-
[PATCH 20/23] qla2xxx: Don't process RSCNs for a vport on the same physical adapter.
From: Chad Dupuis
Currently,the driver is processes RSCNs for each new NPIV ports that is created.
Processing the RSCN includes a name server query to see what has changed at the
name server side. The name server query is performed by the physical port and
each virtual port on the physical adapter (since the RSCN is passed to each
virtual port for processing). As the number of virtual ports being created
increases, this causes a lot of traffic and busies the firmware.
Processing the RSCN for a virtual port we already have a priori knowledge of is
not necessary so check the 24-bit fabric ID of the RSCN entry and skip
processing it if the RSCN is for a virtual port we already know about.
Signed-off-by: Chad Dupuis
Signed-off-by: Saurav Kashyap
---
drivers/scsi/qla2xxx/qla_gbl.h |1 +
drivers/scsi/qla2xxx/qla_init.c | 21 +++--
drivers/scsi/qla2xxx/qla_isr.c | 29 +
3 files changed, 33 insertions(+), 18 deletions(-)
diff --git a/drivers/scsi/qla2xxx/qla_gbl.h b/drivers/scsi/qla2xxx/qla_gbl.h
index 617771b..02f11de 100644
--- a/drivers/scsi/qla2xxx/qla_gbl.h
+++ b/drivers/scsi/qla2xxx/qla_gbl.h
@@ -446,6 +446,7 @@ extern uint8_t *qla25xx_read_nvram_data(scsi_qla_host_t *,
uint8_t *, uint32_t,
uint32_t);
extern int qla25xx_write_nvram_data(scsi_qla_host_t *, uint8_t *, uint32_t,
uint32_t);
+extern int qla2x00_is_a_vp_did(scsi_qla_host_t *, uint32_t);
extern int qla2x00_beacon_on(struct scsi_qla_host *);
extern int qla2x00_beacon_off(struct scsi_qla_host *);
diff --git a/drivers/scsi/qla2xxx/qla_init.c b/drivers/scsi/qla2xxx/qla_init.c
index 891b8f1..a1e5848 100644
--- a/drivers/scsi/qla2xxx/qla_init.c
+++ b/drivers/scsi/qla2xxx/qla_init.c
@@ -3368,8 +3368,7 @@ qla2x00_find_all_fabric_devs(scsi_qla_host_t *vha,
int first_dev, last_dev;
port_id_t wrap = {}, nxt_d_id;
struct qla_hw_data *ha = vha->hw;
- struct scsi_qla_host *vp, *base_vha = pci_get_drvdata(ha->pdev);
- struct scsi_qla_host *tvp;
+ struct scsi_qla_host *base_vha = pci_get_drvdata(ha->pdev);
rval = QLA_SUCCESS;
@@ -3482,22 +3481,8 @@ qla2x00_find_all_fabric_devs(scsi_qla_host_t *vha,
continue;
/* Bypass virtual ports of the same host. */
- found = 0;
- if (ha->num_vhosts) {
- unsigned long flags;
-
- spin_lock_irqsave(&ha->vport_slock, flags);
- list_for_each_entry_safe(vp, tvp, &ha->vp_list, list) {
- if (new_fcport->d_id.b24 == vp->d_id.b24) {
- found = 1;
- break;
- }
- }
- spin_unlock_irqrestore(&ha->vport_slock, flags);
-
- if (found)
- continue;
- }
+ if (qla2x00_is_a_vp_did(vha, new_fcport->d_id.b24))
+ continue;
/* Bypass if same domain and area of adapter. */
if (((new_fcport->d_id.b24 & 0x00) ==
diff --git a/drivers/scsi/qla2xxx/qla_isr.c b/drivers/scsi/qla2xxx/qla_isr.c
index fa738cd..d62fd1a 100644
--- a/drivers/scsi/qla2xxx/qla_isr.c
+++ b/drivers/scsi/qla2xxx/qla_isr.c
@@ -495,6 +495,31 @@ qla83xx_handle_8200_aen(scsi_qla_host_t *vha, uint16_t *mb)
}
}
+int
+qla2x00_is_a_vp_did(scsi_qla_host_t *vha, uint32_t rscn_entry)
+{
+ struct qla_hw_data *ha = vha->hw;
+ scsi_qla_host_t *vp;
+ uint32_t vp_did;
+ unsigned long flags;
+ int ret = 0;
+
+ if (!ha->num_vhosts)
+ return ret;
+
+ spin_lock_irqsave(&ha->vport_slock, flags);
+ list_for_each_entry(vp, &ha->vp_list, list) {
+ vp_did = vp->d_id.b24;
+ if (vp_did == rscn_entry) {
+ ret = 1;
+ break;
+ }
+ }
+ spin_unlock_irqrestore(&ha->vport_slock, flags);
+
+ return ret;
+}
+
/**
* qla2x00_async_event() - Process aynchronous events.
* @ha: SCSI driver HA context
@@ -901,6 +926,10 @@ skip_rio:
/* Ignore reserved bits from RSCN-payload. */
rscn_entry = ((mb[1] & 0x3ff) << 16) | mb[2];
+ /* Skip RSCNs for virtual ports on the same physical port */
+ if (qla2x00_is_a_vp_did(vha, rscn_entry))
+ break;
+
atomic_set(&vha->loop_down_timer, 0);
vha->flags.management_server_logged_in = 0;
--
1.7.7
--
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 19/23] qla2xxx: Add setting of driver version string for vendor application.
From: Joe Carnuccio
Signed-off-by: Joe Carnuccio
Signed-off-by: Saurav Kashyap
---
drivers/scsi/qla2xxx/qla_dbg.c |2 +-
drivers/scsi/qla2xxx/qla_def.h |2 +
drivers/scsi/qla2xxx/qla_gbl.h |3 ++
drivers/scsi/qla2xxx/qla_init.c |2 +
drivers/scsi/qla2xxx/qla_mbx.c | 58 +++
5 files changed, 66 insertions(+), 1 deletions(-)
diff --git a/drivers/scsi/qla2xxx/qla_dbg.c b/drivers/scsi/qla2xxx/qla_dbg.c
index 4e58001..69d7a85 100644
--- a/drivers/scsi/qla2xxx/qla_dbg.c
+++ b/drivers/scsi/qla2xxx/qla_dbg.c
@@ -12,7 +12,7 @@
* | Level| Last Value Used | Holes |
* --
* | Module Init and Probe| 0x0126 | 0x4b,0xba,0xfa |
- * | Mailbox commands | 0x1154 | 0x111a-0x111b |
+ * | Mailbox commands | 0x1158 | 0x111a-0x111b |
* | || 0x112c-0x112e |
* | || 0x113a |
* | Device Discovery | 0x2087 | 0x2020-0x2022, |
diff --git a/drivers/scsi/qla2xxx/qla_def.h b/drivers/scsi/qla2xxx/qla_def.h
index 6550653..992e240 100644
--- a/drivers/scsi/qla2xxx/qla_def.h
+++ b/drivers/scsi/qla2xxx/qla_def.h
@@ -863,6 +863,8 @@ typedef struct {
#defineMBX_1 BIT_1
#defineMBX_0 BIT_0
+#define RNID_TYPE_SET_VERSION 0x9
+
/*
* Firmware state codes from get firmware state mailbox command
*/
diff --git a/drivers/scsi/qla2xxx/qla_gbl.h b/drivers/scsi/qla2xxx/qla_gbl.h
index b67f74a..617771b 100644
--- a/drivers/scsi/qla2xxx/qla_gbl.h
+++ b/drivers/scsi/qla2xxx/qla_gbl.h
@@ -358,6 +358,9 @@ extern int
qla2x00_disable_fce_trace(scsi_qla_host_t *, uint64_t *, uint64_t *);
extern int
+qla2x00_set_driver_version(scsi_qla_host_t *, char *);
+
+extern int
qla2x00_read_sfp(scsi_qla_host_t *, dma_addr_t, uint8_t *,
uint16_t, uint16_t, uint16_t, uint16_t);
diff --git a/drivers/scsi/qla2xxx/qla_init.c b/drivers/scsi/qla2xxx/qla_init.c
index edb4f8e..891b8f1 100644
--- a/drivers/scsi/qla2xxx/qla_init.c
+++ b/drivers/scsi/qla2xxx/qla_init.c
@@ -619,6 +619,8 @@ qla2x00_initialize_adapter(scsi_qla_host_t *vha)
if (IS_QLA24XX_TYPE(ha) || IS_QLA25XX(ha))
qla24xx_read_fcp_prio_cfg(vha);
+ qla2x00_set_driver_version(vha, QLA2XXX_VERSION);
+
return (rval);
}
diff --git a/drivers/scsi/qla2xxx/qla_mbx.c b/drivers/scsi/qla2xxx/qla_mbx.c
index dc0fe52..281947e 100644
--- a/drivers/scsi/qla2xxx/qla_mbx.c
+++ b/drivers/scsi/qla2xxx/qla_mbx.c
@@ -3867,6 +3867,64 @@ qla81xx_restart_mpi_firmware(scsi_qla_host_t *vha)
}
int
+qla2x00_set_driver_version(scsi_qla_host_t *vha, char *version)
+{
+ int rval;
+ mbx_cmd_t mc;
+ mbx_cmd_t *mcp = &mc;
+ int len;
+ uint16_t dwlen;
+ uint8_t *str;
+ dma_addr_t str_dma;
+ struct qla_hw_data *ha = vha->hw;
+
+ if (!IS_FWI2_CAPABLE(ha) || IS_QLA82XX(ha))
+ return QLA_FUNCTION_FAILED;
+
+ ql_dbg(ql_dbg_mbx + ql_dbg_verbose, vha, 0x1155,
+ "Entered %s.\n", __func__);
+
+ str = dma_pool_alloc(ha->s_dma_pool, GFP_KERNEL, &str_dma);
+ if (!str) {
+ ql_log(ql_log_warn, vha, 0x1156,
+ "Failed to allocate driver version param.\n");
+ return QLA_MEMORY_ALLOC_FAILED;
+ }
+
+ memcpy(str, "\x7\x3\x11\x0", 4);
+ dwlen = str[0];
+ len = dwlen * sizeof(uint32_t) - 4;
+ memset(str + 4, 0, len);
+ if (len > strlen(version))
+ len = strlen(version);
+ memcpy(str + 4, version, len);
+
+ mcp->mb[0] = MBC_SET_RNID_PARAMS;
+ mcp->mb[1] = RNID_TYPE_SET_VERSION << 8 | dwlen;
+ mcp->mb[2] = MSW(LSD(str_dma));
+ mcp->mb[3] = LSW(LSD(str_dma));
+ mcp->mb[6] = MSW(MSD(str_dma));
+ mcp->mb[7] = LSW(MSD(str_dma));
+ mcp->out_mb = MBX_7|MBX_6|MBX_3|MBX_2|MBX_1|MBX_0;
+ mcp->in_mb = MBX_0;
+ mcp->tov = MBX_TOV_SECONDS;
+ mcp->flags = 0;
+ rval = qla2x00_mailbox_command(vha, mcp);
+
+ if (rval != QLA_SUCCESS) {
+ ql_dbg(ql_dbg_mbx, vha, 0x1157,
+ "Failed=%x mb[0]=%x.\n", rval, mcp->mb[0]);
+ } else {
+ ql_dbg(ql_dbg_mbx + ql_dbg_verbose, vha, 0x1158,
+ "Done %s.\n", __func__);
+ }
+
+ dma_pool_free(ha->s_dma_pool, str, str_dma);
+
+ return rval;
+}
+
+int
qla2x00_read_sfp(scsi_qla_host_t *vha, dma_addr_t sfp_dma, uint8_t *sfp,
uint16_t dev, uint16_t off, uint16_t len, uint16_t opt)
{
--
1.7.7
--
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 21/23] qla2xxx: Don't process state change aen for reset owner.
Signed-off-by: Giridhar Malavali
Signed-off-by: Saurav Kashyap
---
drivers/scsi/qla2xxx/qla_isr.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/drivers/scsi/qla2xxx/qla_isr.c b/drivers/scsi/qla2xxx/qla_isr.c
index d62fd1a..cbf6a43 100644
--- a/drivers/scsi/qla2xxx/qla_isr.c
+++ b/drivers/scsi/qla2xxx/qla_isr.c
@@ -491,6 +491,8 @@ qla83xx_handle_8200_aen(scsi_qla_host_t *vha, uint16_t *mb)
if (mb[1] & IDC_DEVICE_STATE_CHANGE) {
ql_log(ql_log_info, vha, 0x506a,
"IDC Device-State changed = 0x%x.\n", mb[4]);
+ if (ha->flags.nic_core_reset_owner)
+ return;
qla83xx_schedule_work(vha, MBA_IDC_AEN);
}
}
--
1.7.7
--
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 23/23] qla2xxx: Wait for IDC complete event to finish loopback operation.
From: Chad Dupuis
Wait for the IDC complete AEN before returning the loopback operation back to
the application to make sure the port is put back into normal operations.
Signed-off-by: Chad Dupuis
Signed-off-by: Saurav Kashyap
---
drivers/scsi/qla2xxx/qla_bsg.c | 39 +--
drivers/scsi/qla2xxx/qla_def.h |6 ++
drivers/scsi/qla2xxx/qla_isr.c |3 +++
drivers/scsi/qla2xxx/qla_os.c |1 +
4 files changed, 39 insertions(+), 10 deletions(-)
diff --git a/drivers/scsi/qla2xxx/qla_bsg.c b/drivers/scsi/qla2xxx/qla_bsg.c
index 169dc85..5d4f5cb 100644
--- a/drivers/scsi/qla2xxx/qla_bsg.c
+++ b/drivers/scsi/qla2xxx/qla_bsg.c
@@ -535,7 +535,7 @@ done:
/* Disable loopback mode */
static inline int
qla81xx_reset_loopback_mode(scsi_qla_host_t *vha, uint16_t *config,
-int wait)
+int wait, int wait2)
{
int ret = 0;
int rval = 0;
@@ -556,28 +556,45 @@ qla81xx_reset_loopback_mode(scsi_qla_host_t *vha,
uint16_t *config,
memcpy(&new_config[1], &config[1], sizeof(uint16_t) * 3) ;
ha->notify_dcbx_comp = wait;
+ ha->notify_lb_portup_comp = wait2;
+
ret = qla81xx_set_port_config(vha, new_config);
if (ret != QLA_SUCCESS) {
ql_log(ql_log_warn, vha, 0x7025,
"Set port config failed.\n");
ha->notify_dcbx_comp = 0;
+ ha->notify_lb_portup_comp = 0;
rval = -EINVAL;
goto done_reset_internal;
}
/* Wait for DCBX complete event */
if (wait && !wait_for_completion_timeout(&ha->dcbx_comp,
- (20 * HZ))) {
+ (DCBX_COMP_TIMEOUT * HZ))) {
ql_dbg(ql_dbg_user, vha, 0x7026,
- "State change notification not received.\n");
+ "DCBX completion not received.\n");
ha->notify_dcbx_comp = 0;
+ ha->notify_lb_portup_comp = 0;
rval = -EINVAL;
goto done_reset_internal;
} else
ql_dbg(ql_dbg_user, vha, 0x7027,
- "State change received.\n");
+ "DCBX completion received.\n");
+
+ if (wait2 &&
+ !wait_for_completion_timeout(&ha->lb_portup_comp,
+ (LB_PORTUP_COMP_TIMEOUT * HZ))) {
+ ql_dbg(ql_dbg_user, vha, 0x70c5,
+ "Port up completion not received.\n");
+ ha->notify_lb_portup_comp = 0;
+ rval = -EINVAL;
+ goto done_reset_internal;
+ } else
+ ql_dbg(ql_dbg_user, vha, 0x70c6,
+ "Port up completion received.\n");
ha->notify_dcbx_comp = 0;
+ ha->notify_lb_portup_comp = 0;
}
done_reset_internal:
return rval;
@@ -618,10 +635,11 @@ qla81xx_set_loopback_mode(scsi_qla_host_t *vha, uint16_t
*config,
}
/* Wait for DCBX complete event */
- if (!wait_for_completion_timeout(&ha->dcbx_comp, (20 * HZ))) {
+ if (!wait_for_completion_timeout(&ha->dcbx_comp,
+ (DCBX_COMP_TIMEOUT * HZ))) {
ql_dbg(ql_dbg_user, vha, 0x7022,
- "State change notification not received.\n");
- ret = qla81xx_reset_loopback_mode(vha, new_config, 0);
+ "DCBX completion not received.\n");
+ ret = qla81xx_reset_loopback_mode(vha, new_config, 0, 0);
/*
* If the reset of the loopback mode doesn't work take a FCoE
* dump and reset the chip.
@@ -639,7 +657,7 @@ qla81xx_set_loopback_mode(scsi_qla_host_t *vha, uint16_t
*config,
ha->flags.idc_compl_status = 0;
} else
ql_dbg(ql_dbg_user, vha, 0x7023,
- "State change received.\n");
+ "DCBX completion received.\n");
}
ha->notify_dcbx_comp = 0;
@@ -749,6 +767,7 @@ qla2x00_process_loopback(struct fc_bsg_job *bsg_job)
if (IS_QLA81XX(ha) || IS_QLA8031(ha)) {
memset(config, 0, sizeof(config));
memset(new_config, 0, sizeof(new_config));
+
if (qla81xx_get_port_config(vha, config)) {
ql_log(ql_log_warn, vha, 0x701f,
"Get port config failed.\n");
@@ -773,7 +792,7 @@ qla2x00_process_loopback(struct fc_bsg_job *bsg_job)
config, new_config, elreq.options);
else
rval = qla81xx_reset_loopback_mod
[PATCH 22/23] qla2xxx: Integrate generic card temperature with mezz card temperature.
From: Joe Carnuccio
Give priority to I2C thermal.
Signed-off-by: Joe Carnuccio
Signed-off-by: Saurav Kashyap
---
drivers/scsi/qla2xxx/qla_attr.c | 33 +--
drivers/scsi/qla2xxx/qla_dbg.c |2 +-
drivers/scsi/qla2xxx/qla_def.h |5 ++-
drivers/scsi/qla2xxx/qla_gbl.h |2 +-
drivers/scsi/qla2xxx/qla_init.c |2 +-
drivers/scsi/qla2xxx/qla_mbx.c | 82 ---
6 files changed, 86 insertions(+), 40 deletions(-)
diff --git a/drivers/scsi/qla2xxx/qla_attr.c b/drivers/scsi/qla2xxx/qla_attr.c
index 7256167..1d82eef 100644
--- a/drivers/scsi/qla2xxx/qla_attr.c
+++ b/drivers/scsi/qla2xxx/qla_attr.c
@@ -1272,22 +1272,29 @@ qla2x00_thermal_temp_show(struct device *dev,
struct device_attribute *attr, char *buf)
{
scsi_qla_host_t *vha = shost_priv(class_to_shost(dev));
- int rval = QLA_FUNCTION_FAILED;
- uint16_t temp, frac;
+ uint16_t temp = 0;
- if (!vha->hw->flags.thermal_supported)
- return snprintf(buf, PAGE_SIZE, "\n");
+ if (!vha->hw->thermal_support) {
+ ql_log(ql_log_warn, vha, 0x70db,
+ "Thermal not supported by this card.\n");
+ goto done;
+ }
- temp = frac = 0;
- if (qla2x00_reset_active(vha))
- ql_log(ql_log_warn, vha, 0x707b,
- "ISP reset active.\n");
- else if (!vha->hw->flags.eeh_busy)
- rval = qla2x00_get_thermal_temp(vha, &temp, &frac);
- if (rval != QLA_SUCCESS)
- return snprintf(buf, PAGE_SIZE, "\n");
+ if (qla2x00_reset_active(vha)) {
+ ql_log(ql_log_warn, vha, 0x70dc, "ISP reset active.\n");
+ goto done;
+ }
+
+ if (vha->hw->flags.eeh_busy) {
+ ql_log(ql_log_warn, vha, 0x70dd, "PCI EEH busy.\n");
+ goto done;
+ }
+
+ if (qla2x00_get_thermal_temp(vha, &temp) == QLA_SUCCESS)
+ return snprintf(buf, PAGE_SIZE, "%d\n", temp);
- return snprintf(buf, PAGE_SIZE, "%d.%02d\n", temp, frac);
+done:
+ return snprintf(buf, PAGE_SIZE, "\n");
}
static ssize_t
diff --git a/drivers/scsi/qla2xxx/qla_dbg.c b/drivers/scsi/qla2xxx/qla_dbg.c
index 69d7a85..1626de5 100644
--- a/drivers/scsi/qla2xxx/qla_dbg.c
+++ b/drivers/scsi/qla2xxx/qla_dbg.c
@@ -12,7 +12,7 @@
* | Level| Last Value Used | Holes |
* --
* | Module Init and Probe| 0x0126 | 0x4b,0xba,0xfa |
- * | Mailbox commands | 0x1158 | 0x111a-0x111b |
+ * | Mailbox commands | 0x115b | 0x111a-0x111b |
* | || 0x112c-0x112e |
* | || 0x113a |
* | Device Discovery | 0x2087 | 0x2020-0x2022, |
diff --git a/drivers/scsi/qla2xxx/qla_def.h b/drivers/scsi/qla2xxx/qla_def.h
index 992e240..c081882 100644
--- a/drivers/scsi/qla2xxx/qla_def.h
+++ b/drivers/scsi/qla2xxx/qla_def.h
@@ -864,6 +864,7 @@ typedef struct {
#defineMBX_0 BIT_0
#define RNID_TYPE_SET_VERSION 0x9
+#define RNID_TYPE_ASIC_TEMP0xC
/*
* Firmware state codes from get firmware state mailbox command
@@ -2628,7 +2629,6 @@ struct qla_hw_data {
uint32_tnic_core_hung:1;
uint32_tquiesce_owner:1;
- uint32_tthermal_supported:1;
uint32_tnic_core_reset_hdlr_active:1;
uint32_tnic_core_reset_owner:1;
uint32_tisp82xx_no_md_cap:1;
@@ -3076,6 +3076,9 @@ struct qla_hw_data {
int cfg_lun_q_depth;
struct qlt_hw_data tgt;
+ uint16_tthermal_support;
+#define THERMAL_SUPPORT_I2C BIT_0
+#define THERMAL_SUPPORT_ISP BIT_1
};
/*
diff --git a/drivers/scsi/qla2xxx/qla_gbl.h b/drivers/scsi/qla2xxx/qla_gbl.h
index 02f11de..eb3ca21 100644
--- a/drivers/scsi/qla2xxx/qla_gbl.h
+++ b/drivers/scsi/qla2xxx/qla_gbl.h
@@ -55,7 +55,7 @@ extern void qla2x00_update_fcport(scsi_qla_host_t *,
fc_port_t *);
extern void qla2x00_alloc_fw_dump(scsi_qla_host_t *);
extern void qla2x00_try_to_stop_firmware(scsi_qla_host_t *);
-extern int qla2x00_get_thermal_temp(scsi_qla_host_t *, uint16_t *, uint16_t *);
+extern int qla2x00_get_thermal_temp(scsi_qla_host_t *, uint16_t *);
extern void qla84xx_put_chip(struct scsi_qla_host *);
diff --git a/drivers/scsi/qla2xxx/qla_init.c b/drivers/scsi/qla2xxx/qla_init.c
index a1e5848..edf4d14 100644
--- a/drivers/scsi/qla2xxx/qla_init.c
+++ b/drivers/scsi/qla2xxx/qla_init.c
@@ -523,7 +523,7 @@ qla2x00_initialize_adapter(scsi_qla_host_t *vha)
vha->flags.reset_active = 0;
ha->flags.pci_channel_io_perm_failure = 0;
ha->flags.eeh_busy = 0;
- ha->flags.thermal_supported = 1;
+ ha->th
[PATCH 13/23] qla2xxx: Update the copyright information.
Signed-off-by: Giridhar Malavali Signed-off-by: Saurav Kashyap --- drivers/scsi/qla2xxx/qla_attr.c |2 +- drivers/scsi/qla2xxx/qla_bsg.h |2 +- drivers/scsi/qla2xxx/qla_dbg.c |2 +- drivers/scsi/qla2xxx/qla_dbg.h |2 +- drivers/scsi/qla2xxx/qla_def.h |2 +- drivers/scsi/qla2xxx/qla_dfs.c |2 +- drivers/scsi/qla2xxx/qla_fw.h |2 +- drivers/scsi/qla2xxx/qla_gbl.h |2 +- drivers/scsi/qla2xxx/qla_gs.c |2 +- drivers/scsi/qla2xxx/qla_init.c |2 +- drivers/scsi/qla2xxx/qla_inline.h |2 +- drivers/scsi/qla2xxx/qla_iocb.c |2 +- drivers/scsi/qla2xxx/qla_isr.c |2 +- drivers/scsi/qla2xxx/qla_mbx.c |2 +- drivers/scsi/qla2xxx/qla_mid.c |2 +- drivers/scsi/qla2xxx/qla_nx.c |2 +- drivers/scsi/qla2xxx/qla_nx.h |2 +- drivers/scsi/qla2xxx/qla_os.c |2 +- drivers/scsi/qla2xxx/qla_settings.h |2 +- drivers/scsi/qla2xxx/qla_sup.c |2 +- drivers/scsi/qla2xxx/qla_version.h |2 +- 21 files changed, 21 insertions(+), 21 deletions(-) diff --git a/drivers/scsi/qla2xxx/qla_attr.c b/drivers/scsi/qla2xxx/qla_attr.c index 83d7984..7256167 100644 --- a/drivers/scsi/qla2xxx/qla_attr.c +++ b/drivers/scsi/qla2xxx/qla_attr.c @@ -1,6 +1,6 @@ /* * QLogic Fibre Channel HBA Driver - * Copyright (c) 2003-2012 QLogic Corporation + * Copyright (c) 2003-2013 QLogic Corporation * * See LICENSE.qla2xxx for copyright and licensing details. */ diff --git a/drivers/scsi/qla2xxx/qla_bsg.h b/drivers/scsi/qla2xxx/qla_bsg.h index 37b8b7b..e9f6b9b 100644 --- a/drivers/scsi/qla2xxx/qla_bsg.h +++ b/drivers/scsi/qla2xxx/qla_bsg.h @@ -1,6 +1,6 @@ /* * QLogic Fibre Channel HBA Driver - * Copyright (c) 2003-2012 QLogic Corporation + * Copyright (c) 2003-2013 QLogic Corporation * * See LICENSE.qla2xxx for copyright and licensing details. */ diff --git a/drivers/scsi/qla2xxx/qla_dbg.c b/drivers/scsi/qla2xxx/qla_dbg.c index 29101fe..4e58001 100644 --- a/drivers/scsi/qla2xxx/qla_dbg.c +++ b/drivers/scsi/qla2xxx/qla_dbg.c @@ -1,6 +1,6 @@ /* * QLogic Fibre Channel HBA Driver - * Copyright (c) 2003-2012 QLogic Corporation + * Copyright (c) 2003-2013 QLogic Corporation * * See LICENSE.qla2xxx for copyright and licensing details. */ diff --git a/drivers/scsi/qla2xxx/qla_dbg.h b/drivers/scsi/qla2xxx/qla_dbg.h index 8f911c0..35e20b4 100644 --- a/drivers/scsi/qla2xxx/qla_dbg.h +++ b/drivers/scsi/qla2xxx/qla_dbg.h @@ -1,6 +1,6 @@ /* * QLogic Fibre Channel HBA Driver - * Copyright (c) 2003-2012 QLogic Corporation + * Copyright (c) 2003-2013 QLogic Corporation * * See LICENSE.qla2xxx for copyright and licensing details. */ diff --git a/drivers/scsi/qla2xxx/qla_def.h b/drivers/scsi/qla2xxx/qla_def.h index e96abfc..5c1a865 100644 --- a/drivers/scsi/qla2xxx/qla_def.h +++ b/drivers/scsi/qla2xxx/qla_def.h @@ -1,6 +1,6 @@ /* * QLogic Fibre Channel HBA Driver - * Copyright (c) 2003-2012 QLogic Corporation + * Copyright (c) 2003-2013 QLogic Corporation * * See LICENSE.qla2xxx for copyright and licensing details. */ diff --git a/drivers/scsi/qla2xxx/qla_dfs.c b/drivers/scsi/qla2xxx/qla_dfs.c index 706c4f7..792a292 100644 --- a/drivers/scsi/qla2xxx/qla_dfs.c +++ b/drivers/scsi/qla2xxx/qla_dfs.c @@ -1,6 +1,6 @@ /* * QLogic Fibre Channel HBA Driver - * Copyright (c) 2003-2012 QLogic Corporation + * Copyright (c) 2003-2013 QLogic Corporation * * See LICENSE.qla2xxx for copyright and licensing details. */ diff --git a/drivers/scsi/qla2xxx/qla_fw.h b/drivers/scsi/qla2xxx/qla_fw.h index da1a8da..1ac2b0e 100644 --- a/drivers/scsi/qla2xxx/qla_fw.h +++ b/drivers/scsi/qla2xxx/qla_fw.h @@ -1,6 +1,6 @@ /* * QLogic Fibre Channel HBA Driver - * Copyright (c) 2003-2012 QLogic Corporation + * Copyright (c) 2003-2013 QLogic Corporation * * See LICENSE.qla2xxx for copyright and licensing details. */ diff --git a/drivers/scsi/qla2xxx/qla_gbl.h b/drivers/scsi/qla2xxx/qla_gbl.h index ee8ea95..b67f74a 100644 --- a/drivers/scsi/qla2xxx/qla_gbl.h +++ b/drivers/scsi/qla2xxx/qla_gbl.h @@ -1,6 +1,6 @@ /* * QLogic Fibre Channel HBA Driver - * Copyright (c) 2003-2012 QLogic Corporation + * Copyright (c) 2003-2013 QLogic Corporation * * See LICENSE.qla2xxx for copyright and licensing details. */ diff --git a/drivers/scsi/qla2xxx/qla_gs.c b/drivers/scsi/qla2xxx/qla_gs.c index 01efc0e..40c5933 100644 --- a/drivers/scsi/qla2xxx/qla_gs.c +++ b/drivers/scsi/qla2xxx/qla_gs.c @@ -1,6 +1,6 @@ /* * QLogic Fibre Channel HBA Driver - * Copyright (c) 2003-2012 QLogic Corporation + * Copyright (c) 2003-2013 QLogic Corporation * * See LICENSE.qla2xxx for copyright and licensing details. */ diff --git a/drivers/scsi/qla2xxx/qla_init.c b/drivers/scsi/qla2xxx/qla_init.c index 7568324..d9b 100644 --- a/drivers/scsi/qla2xxx/qla_init.c +++ b/drivers/scsi/qla2xxx/qla_init.c @@ -1,6 +1,6 @@ /* * QLogic Fibre Channel HBA Driver - * Copyright (c) 2003-2
[PATCH 11/23] qla2xxx: Move loopback mode reset after chip reset check.
From: Chad Dupuis
If we need to do a chip reset because of a serious loopback error don't try to
reset the loopback mode on the port as the mailbox command will timeout.
Signed-off-by: Chad Dupuis
Signed-off-by: Saurav Kashyap
---
drivers/scsi/qla2xxx/qla_bsg.c | 39 ---
1 files changed, 20 insertions(+), 19 deletions(-)
diff --git a/drivers/scsi/qla2xxx/qla_bsg.c b/drivers/scsi/qla2xxx/qla_bsg.c
index 5478fff..169dc85 100644
--- a/drivers/scsi/qla2xxx/qla_bsg.c
+++ b/drivers/scsi/qla2xxx/qla_bsg.c
@@ -790,6 +790,26 @@ qla2x00_process_loopback(struct fc_bsg_job *bsg_job)
command_sent = INT_DEF_LB_LOOPBACK_CMD;
rval = qla2x00_loopback_test(vha, &elreq, response);
+ if (response[0] == MBS_COMMAND_ERROR &&
+ response[1] == MBS_LB_RESET) {
+ ql_log(ql_log_warn, vha, 0x7029,
+ "MBX command error, Aborting ISP.\n");
+ set_bit(ISP_ABORT_NEEDED, &vha->dpc_flags);
+ qla2xxx_wake_dpc(vha);
+ qla2x00_wait_for_chip_reset(vha);
+ /* Also reset the MPI */
+ if (IS_QLA81XX(ha)) {
+ if (qla81xx_restart_mpi_firmware(vha) !=
+ QLA_SUCCESS) {
+ ql_log(ql_log_warn, vha, 0x702a,
+ "MPI reset failed.\n");
+ }
+ }
+
+ rval = -EIO;
+ goto done_free_dma_rsp;
+ }
+
if (new_config[0]) {
int ret;
@@ -811,25 +831,6 @@ qla2x00_process_loopback(struct fc_bsg_job *bsg_job)
}
- if (response[0] == MBS_COMMAND_ERROR &&
- response[1] == MBS_LB_RESET) {
- ql_log(ql_log_warn, vha, 0x7029,
- "MBX command error, Aborting ISP.\n");
- set_bit(ISP_ABORT_NEEDED, &vha->dpc_flags);
- qla2xxx_wake_dpc(vha);
- qla2x00_wait_for_chip_reset(vha);
- /* Also reset the MPI */
- if (IS_QLA81XX(ha)) {
- if (qla81xx_restart_mpi_firmware(vha) !=
- QLA_SUCCESS) {
- ql_log(ql_log_warn, vha, 0x702a,
- "MPI reset failed.\n");
- }
- }
-
- rval = -EIO;
- goto done_free_dma_rsp;
- }
} else {
type = "FC_BSG_HST_VENDOR_LOOPBACK";
ql_dbg(ql_dbg_user, vha, 0x702b,
--
1.7.7
--
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 15/23] Revert "[SCSI] qla2xxx: Avoid losing any fc ports when loop id's are exhausted."
From: Joe Carnuccio
This reverts commit 4dc77c36f86c2dc4e3f483146d33b64d12c0da3f.
Signed-off-by: Joe Carnuccio
Signed-off-by: Saurav Kashyap
---
drivers/scsi/qla2xxx/qla_init.c | 83 +-
1 files changed, 63 insertions(+), 20 deletions(-)
diff --git a/drivers/scsi/qla2xxx/qla_init.c b/drivers/scsi/qla2xxx/qla_init.c
index d9b..51f007f 100644
--- a/drivers/scsi/qla2xxx/qla_init.c
+++ b/drivers/scsi/qla2xxx/qla_init.c
@@ -3159,7 +3159,7 @@ static int
qla2x00_configure_fabric(scsi_qla_host_t *vha)
{
int rval;
- fc_port_t *fcport;
+ fc_port_t *fcport, *fcptemp;
uint16_tnext_loopid;
uint16_tmb[MAILBOX_REGISTER_COUNT];
uint16_tloop_id;
@@ -3197,7 +3197,7 @@ qla2x00_configure_fabric(scsi_qla_host_t *vha)
0xfc, mb, BIT_1|BIT_0);
if (rval != QLA_SUCCESS) {
set_bit(LOOP_RESYNC_NEEDED, &vha->dpc_flags);
- break;
+ return rval;
}
if (mb[0] != MBS_COMMAND_COMPLETE) {
ql_dbg(ql_dbg_disc, vha, 0x2042,
@@ -3233,12 +3233,10 @@ qla2x00_configure_fabric(scsi_qla_host_t *vha)
if (rval != QLA_SUCCESS)
break;
- /* Add new ports to existing port list */
- list_splice_tail_init(&new_fcports, &vha->vp_fcports);
-
- /* Starting free loop ID. */
- next_loopid = ha->min_external_loopid;
-
+ /*
+* Logout all previous fabric devices marked lost, except
+* FCP2 devices.
+*/
list_for_each_entry(fcport, &vha->vp_fcports, list) {
if (test_bit(LOOP_RESYNC_NEEDED, &vha->dpc_flags))
break;
@@ -3246,7 +3244,6 @@ qla2x00_configure_fabric(scsi_qla_host_t *vha)
if ((fcport->flags & FCF_FABRIC_DEVICE) == 0)
continue;
- /* Logout lost/gone fabric devices (non-FCP2) */
if (fcport->scan_state != QLA_FCPORT_SCAN_FOUND &&
atomic_read(&fcport->state) == FCS_ONLINE) {
qla2x00_mark_device_lost(vha, fcport,
@@ -3260,30 +3257,76 @@ qla2x00_configure_fabric(scsi_qla_host_t *vha)
fcport->d_id.b.domain,
fcport->d_id.b.area,
fcport->d_id.b.al_pa);
+ fcport->loop_id = FC_NO_LOOP_ID;
}
continue;
}
fcport->scan_state = QLA_FCPORT_SCAN_NONE;
+ }
- /* Login fabric devices that need a login */
- if ((fcport->flags & FCF_LOGIN_NEEDED) != 0 &&
- atomic_read(&vha->loop_down_timer) == 0) {
- if (fcport->loop_id == FC_NO_LOOP_ID) {
- fcport->loop_id = next_loopid;
- rval = qla2x00_find_new_loop_id(
- base_vha, fcport);
- if (rval != QLA_SUCCESS) {
- /* Ran out of IDs to use */
- continue;
- }
+ /* Starting free loop ID. */
+ next_loopid = ha->min_external_loopid;
+
+ /*
+* Scan through our port list and login entries that need to be
+* logged in.
+*/
+ list_for_each_entry(fcport, &vha->vp_fcports, list) {
+ if (atomic_read(&vha->loop_down_timer) ||
+ test_bit(LOOP_RESYNC_NEEDED, &vha->dpc_flags))
+ break;
+
+ if ((fcport->flags & FCF_FABRIC_DEVICE) == 0 ||
+ (fcport->flags & FCF_LOGIN_NEEDED) == 0)
+ continue;
+
+ if (fcport->loop_id == FC_NO_LOOP_ID) {
+ fcport->loop_id = next_loopid;
+ rval = qla2x00_find_new_loop_id(
+ base_vha, fcport);
+ if (rval != QLA_SUCCESS) {
+ /* Ran out of IDs to use */
+ break;
}
}
+ /* Login and update database */
+ qla2x00_fabric_dev_login(vha, fcport, &next_loopid);
+ }
+
+ /* Exit if out of loo
[PATCH 14/23] qla2xxx: silence two GCC warnings.
From: Paul Bolle Compiling qla_gs.o (part of the qla2xxx module) triggers two GCC warnings: drivers/scsi/qla2xxx/qla_gs.c: In function ‘qla2x00_fdmi_rhba’: drivers/scsi/qla2xxx/qla_gs.c:1339:7: warning: array subscript is above array bounds [-Warray-bounds] drivers/scsi/qla2xxx/qla_gs.c: In function ‘qla2x00_fdmi_register’: drivers/scsi/qla2xxx/qla_gs.c:1663:15: warning: array subscript is above array bounds [-Warray-bounds] It seems that the sequence of a strcpy followed by a strlen confuses GCC when it is keeping track of array bounds here. (It is not clear to me which array triggers this warning and by how much GCC thinks the subscript is above its bounds. Neither is it clear to me why comparable code in these two functions doesn't trigger this warning.) An easy way to silence these warnings is to use preprocessor macros and strncpy, as that apparently gives GCC enough information to keep track of array bounds. Signed-off-by: Paul Bolle Signed-off-by: Saurav Kashyap --- drivers/scsi/qla2xxx/qla_def.h |1 + drivers/scsi/qla2xxx/qla_gs.c |8 2 files changed, 5 insertions(+), 4 deletions(-) diff --git a/drivers/scsi/qla2xxx/qla_def.h b/drivers/scsi/qla2xxx/qla_def.h index 5c1a865..3d980a2 100644 --- a/drivers/scsi/qla2xxx/qla_def.h +++ b/drivers/scsi/qla2xxx/qla_def.h @@ -37,6 +37,7 @@ #include "qla_nx.h" #define QLA2XXX_DRIVER_NAME"qla2xxx" #define QLA2XXX_APIDEV "ql2xapidev" +#define QLA2XXX_MANUFACTURER "QLogic Corporation" /* * We have MAILBOX_REGISTER_COUNT sized arrays in a few places, diff --git a/drivers/scsi/qla2xxx/qla_gs.c b/drivers/scsi/qla2xxx/qla_gs.c index 40c5933..9b45525 100644 --- a/drivers/scsi/qla2xxx/qla_gs.c +++ b/drivers/scsi/qla2xxx/qla_gs.c @@ -1328,8 +1328,8 @@ qla2x00_fdmi_rhba(scsi_qla_host_t *vha) /* Manufacturer. */ eiter = (struct ct_fdmi_hba_attr *) (entries + size); eiter->type = __constant_cpu_to_be16(FDMI_HBA_MANUFACTURER); - strcpy(eiter->a.manufacturer, "QLogic Corporation"); - alen = strlen(eiter->a.manufacturer); + alen = strlen(QLA2XXX_MANUFACTURER); + strncpy(eiter->a.manufacturer, QLA2XXX_MANUFACTURER, alen + 1); alen += (alen & 3) ? (4 - (alen & 3)) : 4; eiter->len = cpu_to_be16(4 + alen); size += 4 + alen; @@ -1649,8 +1649,8 @@ qla2x00_fdmi_rpa(scsi_qla_host_t *vha) /* OS device name. */ eiter = (struct ct_fdmi_port_attr *) (entries + size); eiter->type = __constant_cpu_to_be16(FDMI_PORT_OS_DEVICE_NAME); - strcpy(eiter->a.os_dev_name, QLA2XXX_DRIVER_NAME); - alen = strlen(eiter->a.os_dev_name); + alen = strlen(QLA2XXX_DRIVER_NAME); + strncpy(eiter->a.os_dev_name, QLA2XXX_DRIVER_NAME, alen + 1); alen += (alen & 3) ? (4 - (alen & 3)) : 4; eiter->len = cpu_to_be16(4 + alen); size += 4 + alen; -- 1.7.7 -- 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 16/23] Revert "[SCSI] qla2xxx: Optimize existing port name server query matching."
From: Joe Carnuccio
This reverts commit c0822b63ccbf3b019059f384c290b080cae859f1.
Signed-off-by: Joe Carnuccio
Signed-off-by: Saurav Kashyap
---
drivers/scsi/qla2xxx/qla_def.h |3 ---
drivers/scsi/qla2xxx/qla_init.c | 14 +-
2 files changed, 9 insertions(+), 8 deletions(-)
diff --git a/drivers/scsi/qla2xxx/qla_def.h b/drivers/scsi/qla2xxx/qla_def.h
index 3d980a2..a8d97f7 100644
--- a/drivers/scsi/qla2xxx/qla_def.h
+++ b/drivers/scsi/qla2xxx/qla_def.h
@@ -1848,9 +1848,6 @@ typedef struct fc_port {
uint8_t scan_state;
} fc_port_t;
-#define QLA_FCPORT_SCAN_NONE 0
-#define QLA_FCPORT_SCAN_FOUND 1
-
/*
* Fibre channel port/lun states.
*/
diff --git a/drivers/scsi/qla2xxx/qla_init.c b/drivers/scsi/qla2xxx/qla_init.c
index 51f007f..edb4f8e 100644
--- a/drivers/scsi/qla2xxx/qla_init.c
+++ b/drivers/scsi/qla2xxx/qla_init.c
@@ -2746,7 +2746,6 @@ qla2x00_alloc_fcport(scsi_qla_host_t *vha, gfp_t flags)
fcport->loop_id = FC_NO_LOOP_ID;
qla2x00_set_fcport_state(fcport, FCS_UNCONFIGURED);
fcport->supported_classes = FC_COS_UNSPECIFIED;
- fcport->scan_state = QLA_FCPORT_SCAN_NONE;
return fcport;
}
@@ -3229,6 +3228,13 @@ qla2x00_configure_fabric(scsi_qla_host_t *vha)
}
}
+#define QLA_FCPORT_SCAN1
+#define QLA_FCPORT_FOUND 2
+
+ list_for_each_entry(fcport, &vha->vp_fcports, list) {
+ fcport->scan_state = QLA_FCPORT_SCAN;
+ }
+
rval = qla2x00_find_all_fabric_devs(vha, &new_fcports);
if (rval != QLA_SUCCESS)
break;
@@ -3244,7 +3250,7 @@ qla2x00_configure_fabric(scsi_qla_host_t *vha)
if ((fcport->flags & FCF_FABRIC_DEVICE) == 0)
continue;
- if (fcport->scan_state != QLA_FCPORT_SCAN_FOUND &&
+ if (fcport->scan_state == QLA_FCPORT_SCAN &&
atomic_read(&fcport->state) == FCS_ONLINE) {
qla2x00_mark_device_lost(vha, fcport,
ql2xplogiabsentdevice, 0);
@@ -3259,9 +3265,7 @@ qla2x00_configure_fabric(scsi_qla_host_t *vha)
fcport->d_id.b.al_pa);
fcport->loop_id = FC_NO_LOOP_ID;
}
- continue;
}
- fcport->scan_state = QLA_FCPORT_SCAN_NONE;
}
/* Starting free loop ID. */
@@ -3516,7 +3520,7 @@ qla2x00_find_all_fabric_devs(scsi_qla_host_t *vha,
WWN_SIZE))
continue;
- fcport->scan_state = QLA_FCPORT_SCAN_FOUND;
+ fcport->scan_state = QLA_FCPORT_FOUND;
found++;
--
1.7.7
--
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 08/23] qla2xxx: Do MPI reset only for ISP81xx.
Signed-off-by: Giridhar Malavali
Signed-off-by: Saurav Kashyap
---
drivers/scsi/qla2xxx/qla_bsg.c | 10 ++
1 files changed, 6 insertions(+), 4 deletions(-)
diff --git a/drivers/scsi/qla2xxx/qla_bsg.c b/drivers/scsi/qla2xxx/qla_bsg.c
index 5b49766..525c339 100644
--- a/drivers/scsi/qla2xxx/qla_bsg.c
+++ b/drivers/scsi/qla2xxx/qla_bsg.c
@@ -796,10 +796,12 @@ qla2x00_process_loopback(struct fc_bsg_job *bsg_job)
qla2xxx_wake_dpc(vha);
qla2x00_wait_for_chip_reset(vha);
/* Also reset the MPI */
- if (qla81xx_restart_mpi_firmware(vha) !=
- QLA_SUCCESS) {
- ql_log(ql_log_warn, vha, 0x702a,
- "MPI reset failed.\n");
+ if (IS_QLA81XX(ha)) {
+ if (qla81xx_restart_mpi_firmware(vha) !=
+ QLA_SUCCESS) {
+ ql_log(ql_log_warn, vha, 0x702a,
+ "MPI reset failed.\n");
+ }
}
rval = -EIO;
--
1.7.7
--
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 18/23] qla2xxx: Correction of comment in MBC opcode defines.
From: Joe Carnuccio
Signed-off-by: Joe Carnuccio
Signed-off-by: Saurav Kashyap
---
drivers/scsi/qla2xxx/qla_def.h |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/scsi/qla2xxx/qla_def.h b/drivers/scsi/qla2xxx/qla_def.h
index a8d97f7..6550653 100644
--- a/drivers/scsi/qla2xxx/qla_def.h
+++ b/drivers/scsi/qla2xxx/qla_def.h
@@ -768,8 +768,8 @@ typedef struct {
#define MBC_PORT_LOGOUT0x56/* Port Logout request
*/
#define MBC_SEND_RNID_ELS 0x57/* Send RNID ELS request */
#define MBC_SET_RNID_PARAMS0x59/* Set RNID parameters */
-#define MBC_GET_RNID_PARAMS0x5a/* Data Rate */
-#define MBC_DATA_RATE 0x5d/* Get RNID parameters */
+#define MBC_GET_RNID_PARAMS0x5a/* Get RNID parameters */
+#define MBC_DATA_RATE 0x5d/* Data Rate */
#define MBC_INITIALIZE_FIRMWARE0x60/* Initialize firmware
*/
#define MBC_INITIATE_LIP 0x62/* Initiate Loop */
/* Initialization Procedure */
--
1.7.7
--
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 00/23] qla2xxx: Patches for scsi "misc" branch.
Hi James, Please apply the following patches to the scsi tree at your earliest convenience for inclusion in the next mainline merge window. This set needs to be applied on top of last submission. Thanks, ~Saurav Andrew Vasquez (2): qla2xxx: Correct race in loop_state assignment during reset handling. qla2xxx: Correct list-iteration bug in Report-ID Acquisition codes. Chad Dupuis (6): qla2xxx: Reject loopback request if one is already in progress. qla2xxx: Unload hangs after issuing BSG commands to vport. qla2xxx: Extra loopback error handling for ISP83xx. qla2xxx: Move loopback mode reset after chip reset check. qla2xxx: Don't process RSCNs for a vport on the same physical adapter. qla2xxx: Wait for IDC complete event to finish loopback operation. Giridhar Malavali (1): qla2xxx: Update the FTP site references in the driver sources. Joe Carnuccio (7): qla2xxx: Print thermal unsupported message. qla2xxx: Do link initialization on get loop id failure. Revert "[SCSI] qla2xxx: Avoid losing any fc ports when loop id's are exhausted." Revert "[SCSI] qla2xxx: Optimize existing port name server query matching." qla2xxx: Correction of comment in MBC opcode defines. qla2xxx: Add setting of driver version string for vendor application. qla2xxx: Integrate generic card temperature with mezz card temperature. Masanari Iida (1): qla2xxx: Avoid null pointer dereference in shutdown routine. Paul Bolle (1): qla2xxx: silence two GCC warnings. Saurav Kashyap (5): qla2xxx: Get VPD information from common location for CNA. qla2xxx: Do MPI reset only for ISP81xx. qla2xxx: Display the lock owner on lock acquire failure. qla2xxx: Update the copyright information. qla2xxx: Don't process state change aen for reset owner. drivers/scsi/qla2xxx/qla_attr.c | 35 --- drivers/scsi/qla2xxx/qla_bsg.c | 197 ++- drivers/scsi/qla2xxx/qla_bsg.h |2 +- drivers/scsi/qla2xxx/qla_dbg.c |8 +- drivers/scsi/qla2xxx/qla_dbg.h |2 +- drivers/scsi/qla2xxx/qla_def.h | 24 +++-- drivers/scsi/qla2xxx/qla_dfs.c |2 +- drivers/scsi/qla2xxx/qla_fw.h |4 +- drivers/scsi/qla2xxx/qla_gbl.h | 11 ++- drivers/scsi/qla2xxx/qla_gs.c | 10 +- drivers/scsi/qla2xxx/qla_init.c | 138 - drivers/scsi/qla2xxx/qla_inline.h |9 ++- drivers/scsi/qla2xxx/qla_iocb.c |2 +- drivers/scsi/qla2xxx/qla_isr.c | 52 - drivers/scsi/qla2xxx/qla_mbx.c | 199 ++ drivers/scsi/qla2xxx/qla_mid.c |2 +- drivers/scsi/qla2xxx/qla_nx.c | 11 ++- drivers/scsi/qla2xxx/qla_nx.h |4 +- drivers/scsi/qla2xxx/qla_os.c | 24 +++-- drivers/scsi/qla2xxx/qla_settings.h |2 +- drivers/scsi/qla2xxx/qla_sup.c | 18 +--- drivers/scsi/qla2xxx/qla_version.h |2 +- 22 files changed, 539 insertions(+), 219 deletions(-) -- 1.7.7 -- 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 01/23] qla2xxx: Correct race in loop_state assignment during reset handling.
From: Andrew Vasquez
There's a subtle race in the loop/bus-reset handling whereby a
VHA's loop-state can get incorrectly set to 'down' after the
loop-reset and firmware's completion of link re-negotiation. The
original code incorrectly assumes that firmware AENs would arrive
only after mailbox-command execution to initiate the link-flap.
Here's a good case with the old code (AENs arrive after
mailbox-command completion):
qla2xxx [:03:00.1]-8012:91: BUS RESET ISSUED nexus=91:0:4.
qla2xxx [:03:00.1]-287d:91: FCPort state transitioned from ONLINE
to LOST - portid=010100.
qla2xxx [:03:00.1]-580e:91: Asynchronous P2P MODE received.
qla2xxx [:03:00.1]-287d:91: FCPort state transitioned from ONLINE
to LOST - portid=010400.
qla2xxx [:03:00.1]-802b:91: BUS RESET SUCCEEDED nexus=91:0:4.
qla2xxx [:03:00.1]-480b:91: Reset marker scheduled.
qla2xxx [:03:00.1]-5812:91: Port database changed 0006 .
qla2xxx [:03:00.1]-505f:91: Link is operational (4 Gbps).
qla2xxx [:03:00.1]-480c:91: Reset marker end.
qla2xxx [:03:00.1]-480f:91: Loop resync scheduled.
qla2xxx [:03:00.1]-8837:91: F/W Ready - OK.
qla2xxx [:03:00.1]-883a:91: fw_state=3 (7, 0, 0, 0) curr
time=170b8f315.
qla2xxx [:03:00.1]-280e:91: HBA in F P2P topology.
qla2xxx [:03:00.1]-2812:91: qla2x00_configure_hba success
qla2xxx [:03:00.1]-2814:91: Configure loop -- dpc flags = 0x5260.
notice how the 'Port database changed' (8014) arrived after the
bus-reset handler completed 'BUS RESET SUCCEEDED'.
Now, here's a failing case with the old code (AENs arrive before
mailbox-command completion):
qla2xxx [:03:00.1]-8012:91: BUS RESET ISSUED nexus=91:0:0.
qla2xxx [:03:00.1]-580e:91: Asynchronous P2P MODE received.
qla2xxx [:03:00.1]-287d:91: FCPort state transitioned from ONLINE
to LOST - portid=010100.
qla2xxx [:03:00.1]-287d:91: FCPort state transitioned from ONLINE
to LOST - portid=010400.
qla2xxx [:03:00.1]-4800:91: DPC handler sleeping.
qla2xxx [:03:00.1]-5812:91: Port database changed 0006 .
qla2xxx [:03:00.1]-505f:91: Link is operational (4 Gbps).
qla2xxx [:03:00.1]-802b:91: BUS RESET SUCCEEDED nexus=91:0:0.
qla2xxx [:03:00.1]-480b:91: Reset marker scheduled.
qla2xxx [:03:00.1]-480c:91: Reset marker end.
qla2xxx [:03:00.1]-480f:91: Loop resync scheduled.
qla2xxx [:03:00.1]-8837:91: F/W Ready - OK.
qla2xxx [:03:00.1]-883a:91: fw_state=3 (7, 0, 0, 0) curr
time=170be9eb2.
qla2xxx [:03:00.1]-280e:91: HBA in F P2P topology.
qla2xxx [:03:00.1]-2812:91: qla2x00_configure_hba success
qla2xxx [:03:00.1]-2814:91: Configure loop -- dpc flags = 0x5260.
qla2xxx [:03:00.1]-281e:91: Needs RSCN update and loop transition.
qla2xxx [:03:00.1]-286a:91: qla2x00_configure_loop *** FAILED ***.
qla2xxx [:03:00.1]-4810:91: Loop resync end.
qla2xxx [:03:00.1]-4800:91: DPC handler sleeping.
This race would ultimately lead to devices go unexpectedly
offline until another link-flap or chip-reset would cause driver
re-discovery to take place.
Signed-off-by: Andrew Vasquez
Signed-off-by: Saurav Kashyap
---
drivers/scsi/qla2xxx/qla_os.c |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/scsi/qla2xxx/qla_os.c b/drivers/scsi/qla2xxx/qla_os.c
index 2d2afdb..0612d25 100644
--- a/drivers/scsi/qla2xxx/qla_os.c
+++ b/drivers/scsi/qla2xxx/qla_os.c
@@ -1305,14 +1305,14 @@ qla2x00_loop_reset(scsi_qla_host_t *vha)
}
if (ha->flags.enable_lip_full_login && !IS_CNA_CAPABLE(ha)) {
+ atomic_set(&vha->loop_state, LOOP_DOWN);
+ atomic_set(&vha->loop_down_timer, LOOP_DOWN_TIME);
+ qla2x00_mark_all_devices_lost(vha, 0);
ret = qla2x00_full_login_lip(vha);
if (ret != QLA_SUCCESS) {
ql_dbg(ql_dbg_taskm, vha, 0x802d,
"full_login_lip=%d.\n", ret);
}
- atomic_set(&vha->loop_state, LOOP_DOWN);
- atomic_set(&vha->loop_down_timer, LOOP_DOWN_TIME);
- qla2x00_mark_all_devices_lost(vha, 0);
}
if (ha->flags.enable_lip_reset) {
--
1.7.7
--
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 02/23] qla2xxx: Get VPD information from common location for CNA.
Signed-off-by: Giridhar Malavali
Signed-off-by: Saurav Kashyap
---
drivers/scsi/qla2xxx/qla_fw.h |2 --
drivers/scsi/qla2xxx/qla_nx.h |2 +-
drivers/scsi/qla2xxx/qla_sup.c | 16 ++--
3 files changed, 3 insertions(+), 17 deletions(-)
diff --git a/drivers/scsi/qla2xxx/qla_fw.h b/drivers/scsi/qla2xxx/qla_fw.h
index 7105d5e..da1a8da 100644
--- a/drivers/scsi/qla2xxx/qla_fw.h
+++ b/drivers/scsi/qla2xxx/qla_fw.h
@@ -1388,9 +1388,7 @@ struct qla_flt_header {
#define FLT_REG_FCP_PRIO_0 0x87
#define FLT_REG_FCP_PRIO_1 0x88
#define FLT_REG_FCOE_FW0xA4
-#define FLT_REG_FCOE_VPD_0 0xA9
#define FLT_REG_FCOE_NVRAM_0 0xAA
-#define FLT_REG_FCOE_VPD_1 0xAB
#define FLT_REG_FCOE_NVRAM_1 0xAC
struct qla_flt_region {
diff --git a/drivers/scsi/qla2xxx/qla_nx.h b/drivers/scsi/qla2xxx/qla_nx.h
index 6c953e8..5502732 100644
--- a/drivers/scsi/qla2xxx/qla_nx.h
+++ b/drivers/scsi/qla2xxx/qla_nx.h
@@ -897,7 +897,7 @@ struct ct6_dsd {
#define FLT_REG_BOOT_CODE_82XX 0x78
#define FLT_REG_FW_82XX0x74
#define FLT_REG_GOLD_FW_82XX 0x75
-#define FLT_REG_VPD_82XX 0x81
+#define FLT_REG_VPD_8XXX 0x81
#defineFA_VPD_SIZE_82XX0x400
diff --git a/drivers/scsi/qla2xxx/qla_sup.c b/drivers/scsi/qla2xxx/qla_sup.c
index 32fdc2a..f5a1a56 100644
--- a/drivers/scsi/qla2xxx/qla_sup.c
+++ b/drivers/scsi/qla2xxx/qla_sup.c
@@ -798,20 +798,8 @@ qla2xxx_get_flt_info(scsi_qla_host_t *vha, uint32_t
flt_addr)
case FLT_REG_BOOTLOAD_82XX:
ha->flt_region_bootload = start;
break;
- case FLT_REG_VPD_82XX:
- ha->flt_region_vpd = start;
- break;
- case FLT_REG_FCOE_VPD_0:
- if (!IS_QLA8031(ha))
- break;
- ha->flt_region_vpd_nvram = start;
- if (ha->flags.port0)
- ha->flt_region_vpd = start;
- break;
- case FLT_REG_FCOE_VPD_1:
- if (!IS_QLA8031(ha))
- break;
- if (!ha->flags.port0)
+ case FLT_REG_VPD_8XXX:
+ if (IS_CNA_CAPABLE(ha))
ha->flt_region_vpd = start;
break;
case FLT_REG_FCOE_NVRAM_0:
--
1.7.7
--
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 04/23] qla2xxx: Print thermal unsupported message.
From: Joe Carnuccio When the Read SFP mailbox command fails on the thermal device, print a message explaining that thermal is not supported. Signed-off-by: Joe Carnuccio Signed-off-by: Saurav Kashyap --- drivers/scsi/qla2xxx/qla_dbg.c |2 +- drivers/scsi/qla2xxx/qla_mbx.c |4 2 files changed, 5 insertions(+), 1 deletions(-) diff --git a/drivers/scsi/qla2xxx/qla_dbg.c b/drivers/scsi/qla2xxx/qla_dbg.c index ba2d7a8..af045ed 100644 --- a/drivers/scsi/qla2xxx/qla_dbg.c +++ b/drivers/scsi/qla2xxx/qla_dbg.c @@ -12,7 +12,7 @@ * | Level| Last Value Used | Holes | * -- * | Module Init and Probe| 0x0126 | 0x4b,0xba,0xfa | - * | Mailbox commands | 0x114f | 0x111a-0x111b | + * | Mailbox commands | 0x1150 | 0x111a-0x111b | * | || 0x112c-0x112e | * | || 0x113a | * | Device Discovery | 0x2087 | 0x2020-0x2022, | diff --git a/drivers/scsi/qla2xxx/qla_mbx.c b/drivers/scsi/qla2xxx/qla_mbx.c index 319b0f2..92d51fc 100644 --- a/drivers/scsi/qla2xxx/qla_mbx.c +++ b/drivers/scsi/qla2xxx/qla_mbx.c @@ -4446,7 +4446,11 @@ qla2x00_get_thermal_temp(scsi_qla_host_t *vha, uint16_t *temp, uint16_t *frac) ql_dbg(ql_dbg_mbx + ql_dbg_verbose, vha, 0x1018, "Done %s.\n", __func__); + return rval; fail: + ql_log(ql_log_warn, vha, 0x1150, + "Thermal not supported by this card " + "(ignoring further requests).\n"); return rval; } -- 1.7.7 -- 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/5] arcmsr: Support Hibernation
Please ignore the last mails with checkpatch file. Thanks, -Original Message- From: NickCheng [mailto:nick.ch...@areca.com.tw] Sent: Friday, February 08, 2013 2:03 PM To: 'linux-scsi@vger.kernel.org' Cc: 'linux-ker...@vger.kernel.org'; 'j...@kernel.org'; 黃清隆 Subject: [PATCH 2/5] arcmsr: Support Hibernation From: Nick Cheng Support hibernation for whole series of RAID controllers Signed-off-by: Nick Cheng --- -- 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 5/5] arcmsr: Modify ARC-1214 Inband Messages Behavior
From: Nick Cheng Modify ARC-1214 inband messages behavior to make up for HW seldom malfunction. Signed-off-by: Nick Cheng --- patch5 Description: Binary data
[PATCH 3/5] arcmsr: Support MSI and MSI-X
From: Nick Cheng Support MSI or MSI-X for whole series of RAID controllers. Meanwhile correct the register access as iowrite32/ioread32 Signed-off-by: Nick Cheng --- patch3 Description: Binary data
[PATCH 4/5] arcmsr: Support a New RAID Model, ARC-1214
From: Nick Cheng Add a New RAID Model, ARC-1214, which can support 8 SATA HDs at most, so far. Signed-off-by: Nick Cheng --- checkpatch4 Description: Binary data
[PATCH 2/5] arcmsr: Support Hibernation
From: Nick Cheng Support hibernation for whole series of RAID controllers Signed-off-by: Nick Cheng --- patch2 Description: Binary data
[PATCH 5/5] arcmsr: Modify ARC-1214 Inband Messages Behavior
From: Nick Cheng Modify ARC-1214 inband messages behavior to make up for HW seldom malfunction. Signed-off-by: Nick Cheng --- checkpatch5 Description: Binary data
[PATCH 3/5] arcmsr: Support MSI and MSI-X
From: Nick Cheng Support MSI or MSI-X for whole series of RAID controllers. Meanwhile correct the register access as iowrite32/ioread32 Signed-off-by: Nick Cheng --- checkpatch3 Description: Binary data
[PATCH 2/5] arcmsr: Support Hibernation
From: Nick Cheng Support hibernation for whole series of RAID controllers Signed-off-by: Nick Cheng --- checkpatch2 Description: Binary data
Re: [LSF/MM TOPIC][ATTEND] protection information and userspace
> "Darrick" == Darrick J Wong writes: Darrick> Is there a newer one than this? Darrick> https://oss.oracle.com/projects/oracleasm/files/sources/ UEK2 git. -- Martin K. Petersen Oracle Linux Engineering -- 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: [LSF/MM TOPIC][ATTEND] protection information and userspace
On Thu, Feb 07, 2013 at 02:09:17PM -0500, Martin K. Petersen wrote:
> > "Darrick" == Darrick J Wong writes:
>
> Darrick> and more recently I've theorized that we could add a magic
> Darrick> fcntl/ioctl to make the kernel recognize, say, the first iovec
> Darrick> of a O_DIRECT *{read,write}v call as the PI buffer, which I
> Darrick> think is similar to how DIX gets PI data to a disk. But it's
> Darrick> not like I have any code to show for it.
>
> I don't particularly like the "stick it in the first iovec" magic. Also,
> we need a bit more than this. A handful of knobs need to be present to
> convey how the PI should be sliced and diced. So then we get into the
> territory where the first iovec is a PI descriptor of some sort. And
> then the second entry is the PI buffer.
Hm, well if we're adding another IO_CMD_ anyway, it probably isn't that hard to
find space to stuff in an extra pointer or two to a PI descriptor + buffer.
(or a pointer to a descriptor that itself points to a buffer...)
> Darrick> I /think/ it's fairly straightforward to change the directio
> Darrick> submit code to find the userspace PI buffer and amend the block
> Darrick> integrity code to attach our own PI buffer.
>
> I recommend that you check out how I do this in oracleasm.
Is there a newer one than this?
https://oss.oracle.com/projects/oracleasm/files/sources/
(Nov. 2008?)
>
> Darrick> You'd still have to let the block layer set the sector # field,
> Darrick> but afaik that won't affect the crc or the app tag.
>
> Correct. But the right way would be to pass the ref tag seed in as part
> of the IOCB and let sd or the HBA hardware do the remapping.
--D
>
> --
> Martin K. PetersenOracle Linux Engineering
> --
> To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [LSF/MM TOPIC] Reducing the SRP initiator failover time
It is known that it takes about two to three minutes before the upstream SRP initiator fails over from a failed path to a working path. This is not only considered longer than acceptable but is also longer than other Linux SCSI initiators (e.g. iSCSI and FC). Progress so far with improving the fail-over SRP initiator has been slow. This is because the discussion about candidate patches occurred at two different levels: not only the patches itself were discussed but also the approach that should be followed. That last aspect is easier to discuss in a meeting than over a mailing list. Hence the proposal to discuss SRP initiator failover behavior during the LSF/MM summit. The topics that need further discussion are: * If a path fails, remove the entire SCSI host or preserve the SCSI host and only remove the SCSI devices associated with that host ? * Which software component should test the state of a path and should reconnect to an SRP target if a path is restored ? Should that be done by the user space process srp_daemon or by the SRP initiator kernel module ? * How should the SRP initiator behave after a path failure has been detected ? Should the behavior be similar to the FC initiator with its fast_io_fail_tmo and dev_loss_tmo parameters ? Dave, if this topic gets accepted, I really hope you will be able to attend the LSF/MM summit. Bart. Hello Bart, Thank you for taking the initiative. Mellanox think that this should be discussed. We'd be happy to attend. We also would like to discuss: * How and how fast does SRP detect a path failure besides RC error? * Role of srp_daemon, how often srp_daemon scan fabric for new/old targets, how-to scale srp_daemon discovery, traps. -vu -- 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: [LSF/MM TOPIC][ATTEND] protection information and userspace
On Thu, Feb 07, 2013 at 09:36:39AM -0800, Joel Becker wrote: > Dear LSF committee, > I'd like to explicitly request attendance for this discussion > :-) http://marc.info/?l=linux-fsdevel&m=135894412908342&w=2 "Also, the way I compile the list of requests is from thread heads ... that means don't send your attendee request as a reply to something else either otherwise it might get missed." --b. > > Joel > > On Thu, Feb 07, 2013 at 09:27:35AM -0800, Zach Brown wrote: > > On Thu, Feb 07, 2013 at 11:19:59AM -0500, Jeff Moyer wrote: > > > Boaz Harrosh writes: > > > >> > > > >> For aio we just need to add additional fields to an existing structure. > > > >> > > > >> So yeah, I'd be interested in that discussion as well. > > > > > > Sure, it's easy to start there, but then you eventually end up having to > > > add a non-aio interface as well. Let's not take the latter off the > > > table. > > > > I agree that a sync variant should't be ignored, but needing a sync > > interface with PI arguments also shouldn't get in the way of adding > > support to the aio+dio path. Simply because it's what people use :/. > > > > > I'm not sure how that's directly related to aio, but ok. If we're going > > > to rewrite the aio code, I think Zach's acall would be a good start, at > > > least on the API front: > > > http://lwn.net/Articles/316806/ > > > > Yeah, I'm happy to chat about this stuff if people are interested. I > > think I'd do things differently today than what was done in that aged > > acall prototype. > > > > - z > > -- > > 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 can get more with a kind word and a gun than you can with > a kind word alone." > - Al Capone > > http://www.jlbec.org/ > jl...@evilplan.org > -- > To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [SCSI] sd: Ensure we correctly disable devices with unknown protection type
> "Dan" == Dan Carpenter writes: Dan> This patch wasn't applied. Nope, but it hasn't been forgotten. I have it in my resubmit queue with a couple of other stable fixes. -- Martin K. Petersen Oracle Linux Engineering -- 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: [LSF/MM TOPIC][ATTEND] protection information and userspace
> "Ben" == Ben Myers writes: Ben> I'm interested in discussing how to pass protection information to Ben> and from userspace. Maybe Martin could be enlisted for the Ben> discussion. I'll be there, obviously. Ben> I read that some work has already been done in this area but have Ben> not been able to locate it. It looks like the bio-integrity code Ben> already makes it possible to generate the t10-dif crc in the Ben> filesystem. Yep. Although the block layer will generate the PI when the filesystem submits the bio. So until we have a userland conduit there hasn't been much point in the filesystems mucking with the PI explicitly. Ben> It would be good to be able to get the guard and application tags Ben> back out to backup applications such as xfsdump. Enabling other Ben> applications to generate their own tags in userspace is also Ben> interesting. However, the app tag is really only good for disk drives. Most array vendors use it internally. And going forward we're going to use it for access control instead of opaque storage. So exposing the application tag space to userland applications is of very limited use at this point. -- Martin K. Petersen Oracle Linux Engineering -- 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: [LSF/MM TOPIC][ATTEND] protection information and userspace
> "Joel" == Joel Becker writes: Joel> I'm happy to chat about it. Unfortunately, like Darrick says, Joel> sys_dio() coding hasn't happened. I do think we're better off Joel> with some kind of explicit API than some magic state on the file. Joel> I mean, even something like: Joel> ssize_t write_with_pi(int fd, const void *buf, size_t count, Joel> const void *pi, size_t pi_count); Joel> It's not as nice as a non-historical API (eg sys_dio), but it also Joel> probably plays nicer with buffered I/O. Pretty much everyone I have talked to that are interested in explicitly attaching PI (as opposed to relying on the kernel doing it) are using Linux aio. I am not opposed to having more read()/write() like interface as well. But I think it's important to cater to the I/O paradigm used by the applications interested in this. It's a lot easier to tweak a few IOCB fields than it is to rewrite how an application does I/O. -- Martin K. Petersen Oracle Linux Engineering -- 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: [LSF/MM TOPIC][ATTEND] protection information and userspace
> "Darrick" == Darrick J Wong writes:
Darrick> and more recently I've theorized that we could add a magic
Darrick> fcntl/ioctl to make the kernel recognize, say, the first iovec
Darrick> of a O_DIRECT *{read,write}v call as the PI buffer, which I
Darrick> think is similar to how DIX gets PI data to a disk. But it's
Darrick> not like I have any code to show for it.
I don't particularly like the "stick it in the first iovec" magic. Also,
we need a bit more than this. A handful of knobs need to be present to
convey how the PI should be sliced and diced. So then we get into the
territory where the first iovec is a PI descriptor of some sort. And
then the second entry is the PI buffer.
Darrick> I /think/ it's fairly straightforward to change the directio
Darrick> submit code to find the userspace PI buffer and amend the block
Darrick> integrity code to attach our own PI buffer.
I recommend that you check out how I do this in oracleasm.
Darrick> You'd still have to let the block layer set the sector # field,
Darrick> but afaik that won't affect the crc or the app tag.
Correct. But the right way would be to pass the ref tag seed in as part
of the IOCB and let sd or the HBA hardware do the remapping.
--
Martin K. Petersen Oracle Linux Engineering
--
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: [LSF/MM TOPIC][ATTEND] protection information and userspace
Dear LSF committee, I'd like to explicitly request attendance for this discussion :-) Joel On Thu, Feb 07, 2013 at 09:27:35AM -0800, Zach Brown wrote: > On Thu, Feb 07, 2013 at 11:19:59AM -0500, Jeff Moyer wrote: > > Boaz Harrosh writes: > > >> > > >> For aio we just need to add additional fields to an existing structure. > > >> > > >> So yeah, I'd be interested in that discussion as well. > > > > Sure, it's easy to start there, but then you eventually end up having to > > add a non-aio interface as well. Let's not take the latter off the > > table. > > I agree that a sync variant should't be ignored, but needing a sync > interface with PI arguments also shouldn't get in the way of adding > support to the aio+dio path. Simply because it's what people use :/. > > > I'm not sure how that's directly related to aio, but ok. If we're going > > to rewrite the aio code, I think Zach's acall would be a good start, at > > least on the API front: > > http://lwn.net/Articles/316806/ > > Yeah, I'm happy to chat about this stuff if people are interested. I > think I'd do things differently today than what was done in that aged > acall prototype. > > - z > -- > 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 can get more with a kind word and a gun than you can with a kind word alone." - Al Capone http://www.jlbec.org/ jl...@evilplan.org -- 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/5] arcmsr: Support Hibernation
On 02/06/2013 09:36 AM, NickCheng wrote: > From: Nick Cheng > > Support hibernation for whole series of RAID controllers > Signed-off-by: Nick Cheng > --- Hi Nick, this patch (2/5) already uses msi-x in the PM part, while the "Support MSI and MSI-X" is added in the patch 3/5. You should switch the order - the support for msi-x should precede the use of it in "Support Hibernation". Tomas -- 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: [LSF/MM TOPIC][ATTEND] protection information and userspace
On Thu, Feb 07, 2013 at 11:19:59AM -0500, Jeff Moyer wrote: > Boaz Harrosh writes: > >> > >> For aio we just need to add additional fields to an existing structure. > >> > >> So yeah, I'd be interested in that discussion as well. > > Sure, it's easy to start there, but then you eventually end up having to > add a non-aio interface as well. Let's not take the latter off the > table. I agree that a sync variant should't be ignored, but needing a sync interface with PI arguments also shouldn't get in the way of adding support to the aio+dio path. Simply because it's what people use :/. > I'm not sure how that's directly related to aio, but ok. If we're going > to rewrite the aio code, I think Zach's acall would be a good start, at > least on the API front: > http://lwn.net/Articles/316806/ Yeah, I'm happy to chat about this stuff if people are interested. I think I'd do things differently today than what was done in that aged acall prototype. - z -- 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: [LSF/MM TOPIC][ATTEND] protection information and userspace
Boaz Harrosh writes: >>> I also pondered simply adding a new io_prep_* function + IO_CMD_ code to >>> libaio >>> and all the other plumbing necessary to make that happen... >>> >>> void io_prep_preadv_pi(struct iocb *iocb, int fd, const struct iovec *iov, >>>int iovcnt, long long offset, const void *pi, >>>size_t pi_count); >>> >> This is also what I've envisioned. >> Updating io_prep / async I/O is reasonably easy as its been using a >> separate structure for passing in the I/O details. >> >> Normal read/write calls don't really map as you simply don't have >> enough parameter to feed PI information into the kernel. >> So for that you'd need to invent a new interface / syscall. >> >> For aio we just need to add additional fields to an existing structure. >> >> So yeah, I'd be interested in that discussion as well. Sure, it's easy to start there, but then you eventually end up having to add a non-aio interface as well. Let's not take the latter off the table. > Me too, in multiple fronts. It's part of my general concern about >"things we would like for user-mode servers" > > I think that the current aio and libaio Interface is broken for a long > time, for multitude of reasons. For instance the nested structure definitions > are COMPAT broken News to me. I run the libaio test harness built with -m32 on 64 bit regularly. What, exactly, is broken? > , and lots of missing pieces. (For example search in archives > for why bsg does not support sg-lists.) > And there are all these additions that everyone wants on top, that call for > a new interface anyway. What was proposed above does not require a new interface. It's just an additional IO_CMD_*. I'm not saying there aren't reasons for a new interface, it's just I didn't see any in this thread. > So I would like to see a deep fixup of this interface, with an aio version2 > that can take into considerations, all of future needs including these > above. Kernel code will be very happy to be implemented with the new, > interface > and a COMPAT layer could be put in place for the old interface. > > All interested parties should bring to the table what is the extension/changes > they need. And we can try and union all of them together. > > (My addition is for support of sg_lists to bsg, in a way that makes Tomo happy > I know that qemu was wanting this for a while as well as the multitude of > user-mode servers) I'm not sure how that's directly related to aio, but ok. If we're going to rewrite the aio code, I think Zach's acall would be a good start, at least on the API front: http://lwn.net/Articles/316806/ Cheers, Jeff -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] scsi: qla2xxx/qla_attr.c: fix undefined behavior in using snprintf
The original code
snprintf(buf, PAGE_SIZE, "%s\n", buf);
uses buf as both source and destination string, which is undefined behavior
based on C11:
If copying takes place between objects
that overlap, the behavior is undefined.
Signed-off-by: Cong Ding
---
drivers/scsi/qla2xxx/qla_attr.c |8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/drivers/scsi/qla2xxx/qla_attr.c b/drivers/scsi/qla2xxx/qla_attr.c
index 83d7984..ded7383 100644
--- a/drivers/scsi/qla2xxx/qla_attr.c
+++ b/drivers/scsi/qla2xxx/qla_attr.c
@@ -887,10 +887,16 @@ qla2x00_serial_num_show(struct device *dev, struct
device_attribute *attr,
scsi_qla_host_t *vha = shost_priv(class_to_shost(dev));
struct qla_hw_data *ha = vha->hw;
uint32_t sn;
+ ssize_t bn;
if (IS_FWI2_CAPABLE(ha)) {
qla2xxx_get_vpd_field(vha, "SN", buf, PAGE_SIZE);
- return snprintf(buf, PAGE_SIZE, "%s\n", buf);
+ bn = strlen(buf);
+ if (bn < PAGE_SIZE - 1) {
+ buf[bn] = '\n';
+ buf[bn + 1] = '\0';
+ }
+ return bn + 1;
}
sn = ((ha->serial0 & 0x1f) << 16) | (ha->serial2 << 8) | ha->serial1;
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [LSF/MM TOPIC] Thin provisioning SOFT_THRESHOLD error handling
On 02/07/2013 02:06 PM, Boaz Harrosh wrote: [ .. ] Hannes hi! This is received as an "unit attentions", right? Will it not be worth while to solve the general "unit attentions" under udev events, once and for all. Than such a btrfs GC above can just be a simple oneline udev rule. You might want to look at Ewan Milnes patch-set ... 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: [LSF/MM TOPIC] Thin provisioning SOFT_THRESHOLD error handling
On 01/29/2013 10:14 AM, Hannes Reinecke wrote: > Hi all, > > Thin-provisioned devices have the ability to set a 'soft threshold', > which is triggered if the real free space for this device is beyond > this mark. > > The intention behind this is to allow the system to induce some > garbage collection with possibly freeing up unused space. > > Initially it would be possible to execute garbage collection on > filesystems (eg for btrfs). > > However, as this concept applies to other areas within the kernel > (like dm-thinp or even btrfs itself) it might be an idea to have > a general mechanism / error handling etc in place. > > I would like to discuss at LSF the possible implementations > and handling mechanism for this kind of failure scenarios. > Hannes hi! This is received as an "unit attentions", right? Will it not be worth while to solve the general "unit attentions" under udev events, once and for all. Than such a btrfs GC above can just be a simple oneline udev rule. (I think that the event-storm problem you had at the time can be solved with some Kernel side "unit attentions" queue, and greatly reduce the chance for missed events) Thanks Boaz > Cheers, > > Hannes > -- 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: [LSF/MM TOPIC][ATTEND] protection information and userspace
On 02/07/2013 02:33 PM, Hannes Reinecke wrote: > On 02/07/2013 01:16 PM, Boaz Harrosh wrote: >> (Again libaio should be changed in concert with Kernel's new API, and we >> can sacrifice old user-mode performance, with a COMPAT layer. Distro >> maintainers should consider replacing libaio, together with the new >> Kernel, so it is only those that do their own mix-and-match, who can >> fix that mismatch too) >> > And while we're at it, I still would _love_ to connect aio_cancel() > and blk_abort_request(). > > That way we could sensibly abort an I/O and get out of the darn 'D' > state. > Yes!! Thanks. It is very interesting how the socket side of the world had it correct for ages, and the same "fd" object on disks is second grade citizen in UNIX land. (Anybody voting for epoll on async disk IO? ) Thanks Hannes yes that too. And wait_interuptable() too, at couple of places, will need some serious error handling audit for that. > Cheers, > > Hannes > Boaz -- 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: [LSF/MM TOPIC][ATTEND] protection information and userspace
On 02/07/2013 02:29 PM, Bart Van Assche wrote: > On 02/07/13 13:08, Boaz Harrosh wrote: >> (My addition is for support of sg_lists to bsg, in a way that makes Tomo >> happy >> I know that qemu was wanting this for a while as well as the multitude of >> user-mode servers) > > Do you think it would help / make sense if sg_alloc_table() would be > modified such that it allocates the entire scatterlist table via one > vmalloc() call instead of chaining several page-sized scatterlist tables > ? Note: such a change is not possible without modifying > scsi_alloc_sgtable(). > I don't think so, no. sg_alloc_table() is used not only for direct IO also for buffered, Now vmalloc() is terribly slow and would be a bottleneck in today's SSD performance. I love it that the Linux Kernel never uses vmalloc internally, and only ever chains everything to upto PAGE_SIZE sized objects. Coming from all these other OSs that don't, believe me, it is great great performance pain. (TLBs are a bitch) > Bart. > Thanks Boaz -- 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: [LSF/MM TOPIC][ATTEND] protection information and userspace
On 02/07/2013 01:16 PM, Boaz Harrosh wrote:
On 02/07/2013 02:08 PM, Boaz Harrosh wrote:
On 02/07/2013 01:27 PM, Hannes Reinecke wrote:
On 02/07/2013 11:01 AM, Darrick J. Wong wrote:
On Thu, Feb 07, 2013 at 01:40:14AM -0800, Joel Becker wrote:
On Wed, Feb 06, 2013 at 03:34:49PM -0500, Chuck Lever wrote:
On Feb 6, 2013, at 3:24 PM, "Darrick J. Wong" wrote:
On Wed, Feb 06, 2013 at 01:51:22PM -0600, Ben Myers wrote:
Hi,
I'm interested in discussing how to pass protection information to and from
userspace. Maybe Martin could be enlisted for the discussion.
I read that some work has already been done in this area but have not been able
to locate it. It looks like the bio-integrity code already makes it possible
to generate the t10-dif crc in the filesystem. It would be good to be able to
get the guard and application tags back out to backup applications such as
xfsdump. Enabling other applications to generate their own tags in userspace
is also interesting.
This one's been on my list for a couple of years (and companies) too. A few
years ago Joel Becker had support for it in his sys_dio proposal (that hasn't
gone anywhere), and more recently I've theorized that we could add a magic
fcntl/ioctl to make the kernel recognize, say, the first iovec of a O_DIRECT
*{read,write}v call as the PI buffer, which I think is similar to how DIX gets
PI data to a disk. But it's not like I have any code to show for it.
I /think/ it's fairly straightforward to change the directio submit code to
find the userspace PI buffer and amend the block integrity code to attach our
own PI buffer. You'd still have to let the block layer set the sector # field,
but afaik that won't affect the crc or the app tag.
I hear that the NFS guys want to propose some sort of protocol for transmitting
PI data (across NFS), but I haven't seen anything concrete yet.
I'm writing a requirements document for the NFS protocol which I can discuss at
LSF. The use cases for NFS for now would be virtual disk devices (hypervisors)
or direct NFS access to storage from user space.
Like everyone else we are waiting for a magical VFS and user space API to
appear that can pass PI to and from storage.
I'm happy to chat about it. Unfortunately, like Darrick says, sys_dio()
coding hasn't happened. I do think we're better off with some kind of
explicit API than some magic state on the file. I mean, even something
like:
ssize_t write_with_pi(int fd, const void *buf, size_t count,
const void *pi, size_t pi_count);
It's not as nice as a non-historical API (eg sys_dio), but it also
probably plays nicer with buffered I/O.
I also pondered simply adding a new io_prep_* function + IO_CMD_ code to libaio
and all the other plumbing necessary to make that happen...
void io_prep_preadv_pi(struct iocb *iocb, int fd, const struct iovec *iov,
int iovcnt, long long offset, const void *pi,
size_t pi_count);
This is also what I've envisioned.
Updating io_prep / async I/O is reasonably easy as its been using a
separate structure for passing in the I/O details.
Normal read/write calls don't really map as you simply don't have
enough parameter to feed PI information into the kernel.
So for that you'd need to invent a new interface / syscall.
For aio we just need to add additional fields to an existing structure.
So yeah, I'd be interested in that discussion as well.
Me too, in multiple fronts. It's part of my general concern about
"things we would like for user-mode servers"
I think that the current aio and libaio Interface is broken for a long
time, for multitude of reasons. For instance the nested structure definitions
are COMPAT broken, and lots of missing pieces. (For example search in archives
for why bsg does not support sg-lists.)
And there are all these additions that everyone wants on top, that call for
a new interface anyway.
So I would like to see a deep fixup of this interface, with an aio version2
that can take into considerations, all of future needs including these
above. Kernel code will be very happy to be implemented with the new, interface
and a COMPAT layer could be put in place for the old interface.
All interested parties should bring to the table what is the extension/changes
they need. And we can try and union all of them together.
(My addition is for support of sg_lists to bsg, in a way that makes Tomo happy
I know that qemu was wanting this for a while as well as the multitude of
user-mode servers)
I wanted to add that there is another LSF/MM thread going on about:
"[LSF TOPIC] What to do about O_DIRECT?"
All these guys should be participating here, so to change core structures
and behavior to a better model, that helps us here, and not against us.
(Again libaio should be changed in concert with Kernel's new API, and we
can sacrifice old user-mode performance, with a COMPAT layer. Distro
maintainers should
Re: [LSF/MM TOPIC][ATTEND] protection information and userspace
On 02/07/13 13:08, Boaz Harrosh wrote: (My addition is for support of sg_lists to bsg, in a way that makes Tomo happy I know that qemu was wanting this for a while as well as the multitude of user-mode servers) Do you think it would help / make sense if sg_alloc_table() would be modified such that it allocates the entire scatterlist table via one vmalloc() call instead of chaining several page-sized scatterlist tables ? Note: such a change is not possible without modifying scsi_alloc_sgtable(). 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: [LSF/MM TOPIC][ATTEND] protection information and userspace
On 02/07/2013 02:08 PM, Boaz Harrosh wrote:
> On 02/07/2013 01:27 PM, Hannes Reinecke wrote:
>> On 02/07/2013 11:01 AM, Darrick J. Wong wrote:
>>> On Thu, Feb 07, 2013 at 01:40:14AM -0800, Joel Becker wrote:
On Wed, Feb 06, 2013 at 03:34:49PM -0500, Chuck Lever wrote:
>
> On Feb 6, 2013, at 3:24 PM, "Darrick J. Wong"
> wrote:
>
>> On Wed, Feb 06, 2013 at 01:51:22PM -0600, Ben Myers wrote:
>>> Hi,
>>>
>>> I'm interested in discussing how to pass protection information to and
>>> from
>>> userspace. Maybe Martin could be enlisted for the discussion.
>>>
>>> I read that some work has already been done in this area but have not
>>> been able
>>> to locate it. It looks like the bio-integrity code already makes it
>>> possible
>>> to generate the t10-dif crc in the filesystem. It would be good to be
>>> able to
>>> get the guard and application tags back out to backup applications such
>>> as
>>> xfsdump. Enabling other applications to generate their own tags in
>>> userspace
>>> is also interesting.
>>
>> This one's been on my list for a couple of years (and companies) too. A
>> few
>> years ago Joel Becker had support for it in his sys_dio proposal (that
>> hasn't
>> gone anywhere), and more recently I've theorized that we could add a
>> magic
>> fcntl/ioctl to make the kernel recognize, say, the first iovec of a
>> O_DIRECT
>> *{read,write}v call as the PI buffer, which I think is similar to how
>> DIX gets
>> PI data to a disk. But it's not like I have any code to show for it.
>>
>> I /think/ it's fairly straightforward to change the directio submit code
>> to
>> find the userspace PI buffer and amend the block integrity code to
>> attach our
>> own PI buffer. You'd still have to let the block layer set the sector #
>> field,
>> but afaik that won't affect the crc or the app tag.
>>
>> I hear that the NFS guys want to propose some sort of protocol for
>> transmitting
>> PI data (across NFS), but I haven't seen anything concrete yet.
>
> I'm writing a requirements document for the NFS protocol which I can
> discuss at LSF. The use cases for NFS for now would be virtual disk
> devices (hypervisors) or direct NFS access to storage from user space.
>
> Like everyone else we are waiting for a magical VFS and user space API to
> appear that can pass PI to and from storage.
I'm happy to chat about it. Unfortunately, like Darrick says, sys_dio()
coding hasn't happened. I do think we're better off with some kind of
explicit API than some magic state on the file. I mean, even something
like:
ssize_t write_with_pi(int fd, const void *buf, size_t count,
const void *pi, size_t pi_count);
It's not as nice as a non-historical API (eg sys_dio), but it also
probably plays nicer with buffered I/O.
>>>
>>> I also pondered simply adding a new io_prep_* function + IO_CMD_ code to
>>> libaio
>>> and all the other plumbing necessary to make that happen...
>>>
>>> void io_prep_preadv_pi(struct iocb *iocb, int fd, const struct iovec *iov,
>>>int iovcnt, long long offset, const void *pi,
>>>size_t pi_count);
>>>
>> This is also what I've envisioned.
>> Updating io_prep / async I/O is reasonably easy as its been using a
>> separate structure for passing in the I/O details.
>>
>> Normal read/write calls don't really map as you simply don't have
>> enough parameter to feed PI information into the kernel.
>> So for that you'd need to invent a new interface / syscall.
>>
>> For aio we just need to add additional fields to an existing structure.
>>
>> So yeah, I'd be interested in that discussion as well.
>>
>
> Me too, in multiple fronts. It's part of my general concern about
>"things we would like for user-mode servers"
>
> I think that the current aio and libaio Interface is broken for a long
> time, for multitude of reasons. For instance the nested structure definitions
> are COMPAT broken, and lots of missing pieces. (For example search in archives
> for why bsg does not support sg-lists.)
>
> And there are all these additions that everyone wants on top, that call for
> a new interface anyway.
>
> So I would like to see a deep fixup of this interface, with an aio version2
> that can take into considerations, all of future needs including these
> above. Kernel code will be very happy to be implemented with the new,
> interface
> and a COMPAT layer could be put in place for the old interface.
>
> All interested parties should bring to the table what is the extension/changes
> they need. And we can try and union all of them together.
>
> (My addition is for support of sg_lists to bsg, in a way that makes Tomo happy
> I know that qemu was wanting this for a wh
Re: [LSF/MM TOPIC][ATTEND] protection information and userspace
On 02/07/2013 01:27 PM, Hannes Reinecke wrote:
> On 02/07/2013 11:01 AM, Darrick J. Wong wrote:
>> On Thu, Feb 07, 2013 at 01:40:14AM -0800, Joel Becker wrote:
>>> On Wed, Feb 06, 2013 at 03:34:49PM -0500, Chuck Lever wrote:
On Feb 6, 2013, at 3:24 PM, "Darrick J. Wong"
wrote:
> On Wed, Feb 06, 2013 at 01:51:22PM -0600, Ben Myers wrote:
>> Hi,
>>
>> I'm interested in discussing how to pass protection information to and
>> from
>> userspace. Maybe Martin could be enlisted for the discussion.
>>
>> I read that some work has already been done in this area but have not
>> been able
>> to locate it. It looks like the bio-integrity code already makes it
>> possible
>> to generate the t10-dif crc in the filesystem. It would be good to be
>> able to
>> get the guard and application tags back out to backup applications such
>> as
>> xfsdump. Enabling other applications to generate their own tags in
>> userspace
>> is also interesting.
>
> This one's been on my list for a couple of years (and companies) too. A
> few
> years ago Joel Becker had support for it in his sys_dio proposal (that
> hasn't
> gone anywhere), and more recently I've theorized that we could add a magic
> fcntl/ioctl to make the kernel recognize, say, the first iovec of a
> O_DIRECT
> *{read,write}v call as the PI buffer, which I think is similar to how DIX
> gets
> PI data to a disk. But it's not like I have any code to show for it.
>
> I /think/ it's fairly straightforward to change the directio submit code
> to
> find the userspace PI buffer and amend the block integrity code to attach
> our
> own PI buffer. You'd still have to let the block layer set the sector #
> field,
> but afaik that won't affect the crc or the app tag.
>
> I hear that the NFS guys want to propose some sort of protocol for
> transmitting
> PI data (across NFS), but I haven't seen anything concrete yet.
I'm writing a requirements document for the NFS protocol which I can
discuss at LSF. The use cases for NFS for now would be virtual disk
devices (hypervisors) or direct NFS access to storage from user space.
Like everyone else we are waiting for a magical VFS and user space API to
appear that can pass PI to and from storage.
>>>
>>> I'm happy to chat about it. Unfortunately, like Darrick says, sys_dio()
>>> coding hasn't happened. I do think we're better off with some kind of
>>> explicit API than some magic state on the file. I mean, even something
>>> like:
>>>
>>> ssize_t write_with_pi(int fd, const void *buf, size_t count,
>>> const void *pi, size_t pi_count);
>>>
>>> It's not as nice as a non-historical API (eg sys_dio), but it also
>>> probably plays nicer with buffered I/O.
>>
>> I also pondered simply adding a new io_prep_* function + IO_CMD_ code to
>> libaio
>> and all the other plumbing necessary to make that happen...
>>
>> void io_prep_preadv_pi(struct iocb *iocb, int fd, const struct iovec *iov,
>> int iovcnt, long long offset, const void *pi,
>> size_t pi_count);
>>
> This is also what I've envisioned.
> Updating io_prep / async I/O is reasonably easy as its been using a
> separate structure for passing in the I/O details.
>
> Normal read/write calls don't really map as you simply don't have
> enough parameter to feed PI information into the kernel.
> So for that you'd need to invent a new interface / syscall.
>
> For aio we just need to add additional fields to an existing structure.
>
> So yeah, I'd be interested in that discussion as well.
>
Me too, in multiple fronts. It's part of my general concern about
"things we would like for user-mode servers"
I think that the current aio and libaio Interface is broken for a long
time, for multitude of reasons. For instance the nested structure definitions
are COMPAT broken, and lots of missing pieces. (For example search in archives
for why bsg does not support sg-lists.)
And there are all these additions that everyone wants on top, that call for
a new interface anyway.
So I would like to see a deep fixup of this interface, with an aio version2
that can take into considerations, all of future needs including these
above. Kernel code will be very happy to be implemented with the new, interface
and a COMPAT layer could be put in place for the old interface.
All interested parties should bring to the table what is the extension/changes
they need. And we can try and union all of them together.
(My addition is for support of sg_lists to bsg, in a way that makes Tomo happy
I know that qemu was wanting this for a while as well as the multitude of
user-mode servers)
Thanks
Boaz
> Cheers,
>
> Hannes
>
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of
Re: [PATCH v8 0/10] More device removal fixes
On 02/06/13 23:31, Joe Lawrence wrote:
crash> list scsi_device.siblings -H 0x8808513a4290 -s scsi_device
880851232520
struct scsi_device {
is_visible = 0x1,
sdev_state = SDEV_DEL,
}
880851235388
struct scsi_device {
is_visible = 0x1,
sdev_state = SDEV_DEL,
}
This is interesting. This probably means that one or more threads got
stuck in __scsi_remove_device(). If you still have the crash dump
available it would be appreciated if you could verify whether this is
correct. If so, there might be an issue in the mpt2sas driver where
scsi_done() does not get invoked for all outstanding commands after a
surprise removal.
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: [LSF/MM TOPIC][ATTEND] protection information and userspace
On 02/07/2013 11:01 AM, Darrick J. Wong wrote:
On Thu, Feb 07, 2013 at 01:40:14AM -0800, Joel Becker wrote:
On Wed, Feb 06, 2013 at 03:34:49PM -0500, Chuck Lever wrote:
On Feb 6, 2013, at 3:24 PM, "Darrick J. Wong" wrote:
On Wed, Feb 06, 2013 at 01:51:22PM -0600, Ben Myers wrote:
Hi,
I'm interested in discussing how to pass protection information to and from
userspace. Maybe Martin could be enlisted for the discussion.
I read that some work has already been done in this area but have not been able
to locate it. It looks like the bio-integrity code already makes it possible
to generate the t10-dif crc in the filesystem. It would be good to be able to
get the guard and application tags back out to backup applications such as
xfsdump. Enabling other applications to generate their own tags in userspace
is also interesting.
This one's been on my list for a couple of years (and companies) too. A few
years ago Joel Becker had support for it in his sys_dio proposal (that hasn't
gone anywhere), and more recently I've theorized that we could add a magic
fcntl/ioctl to make the kernel recognize, say, the first iovec of a O_DIRECT
*{read,write}v call as the PI buffer, which I think is similar to how DIX gets
PI data to a disk. But it's not like I have any code to show for it.
I /think/ it's fairly straightforward to change the directio submit code to
find the userspace PI buffer and amend the block integrity code to attach our
own PI buffer. You'd still have to let the block layer set the sector # field,
but afaik that won't affect the crc or the app tag.
I hear that the NFS guys want to propose some sort of protocol for transmitting
PI data (across NFS), but I haven't seen anything concrete yet.
I'm writing a requirements document for the NFS protocol which I can discuss at
LSF. The use cases for NFS for now would be virtual disk devices (hypervisors)
or direct NFS access to storage from user space.
Like everyone else we are waiting for a magical VFS and user space API to
appear that can pass PI to and from storage.
I'm happy to chat about it. Unfortunately, like Darrick says, sys_dio()
coding hasn't happened. I do think we're better off with some kind of
explicit API than some magic state on the file. I mean, even something
like:
ssize_t write_with_pi(int fd, const void *buf, size_t count,
const void *pi, size_t pi_count);
It's not as nice as a non-historical API (eg sys_dio), but it also
probably plays nicer with buffered I/O.
I also pondered simply adding a new io_prep_* function + IO_CMD_ code to libaio
and all the other plumbing necessary to make that happen...
void io_prep_preadv_pi(struct iocb *iocb, int fd, const struct iovec *iov,
int iovcnt, long long offset, const void *pi,
size_t pi_count);
This is also what I've envisioned.
Updating io_prep / async I/O is reasonably easy as its been using a
separate structure for passing in the I/O details.
Normal read/write calls don't really map as you simply don't have
enough parameter to feed PI information into the kernel.
So for that you'd need to invent a new interface / syscall.
For aio we just need to add additional fields to an existing structure.
So yeah, I'd be interested in that discussion as well.
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 v8 0/10] More device removal fixes
On 02/06/13 23:31, Joe Lawrence wrote: On Tue, 5 Feb 2013, Bart Van Assche wrote: Fix a few race conditions that can be triggered by removing a device: - Fix a race between starved list processing and device removal. - Avoid that a SCSI LLD callback can get invoked after scsi_remove_host() finished. - Speed up device removal by stopping error handling as soon as the SHOST_DEL or SHOST_DEL_RECOVERY state has been reached. - Save and restore the host_scribble field during error handling These patches have been tested on top of kernel v3.8-rc6 and are also available here: http://github.com/bvanassche/linux/tree/device-removal-fixes. Hi Bart, I gave your patchset a spin on our ftServer, which supports hotplug of PCI devices. Before attempting a surprise HW removal of an LSI Fusion SAS-2 SCSI controller, I issued an orderly removal through our hotplug driver. The device removal appeared to hang (this does not occur with vanilla 3.8.0-rc6). Hello Joe, Thanks for running this test. I have had a quick look at the mpt2sas _scsih_remove() implementation but I have not yet had the time to analyze that function entirely. My proposal is to defer further analysis of the interaction between the two patches that make scsi_remove_host() wait and the mpt2sas driver until a later time. It would be appreciated if you could run the following test: * Revert the two patches that make scsi_remove_host() wait (these two patches should revert cleanly). * Repeat your device removal test. If that test runs fine, I will retest and repost this patch series without the two patches that make scsi_remove_host() wait. Thanks, 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: [LSF/MM TOPIC][ATTEND] protection information and userspace
On Thu, Feb 07, 2013 at 01:40:14AM -0800, Joel Becker wrote:
> On Wed, Feb 06, 2013 at 03:34:49PM -0500, Chuck Lever wrote:
> >
> > On Feb 6, 2013, at 3:24 PM, "Darrick J. Wong"
> > wrote:
> >
> > > On Wed, Feb 06, 2013 at 01:51:22PM -0600, Ben Myers wrote:
> > >> Hi,
> > >>
> > >> I'm interested in discussing how to pass protection information to and
> > >> from
> > >> userspace. Maybe Martin could be enlisted for the discussion.
> > >>
> > >> I read that some work has already been done in this area but have not
> > >> been able
> > >> to locate it. It looks like the bio-integrity code already makes it
> > >> possible
> > >> to generate the t10-dif crc in the filesystem. It would be good to be
> > >> able to
> > >> get the guard and application tags back out to backup applications such
> > >> as
> > >> xfsdump. Enabling other applications to generate their own tags in
> > >> userspace
> > >> is also interesting.
> > >
> > > This one's been on my list for a couple of years (and companies) too. A
> > > few
> > > years ago Joel Becker had support for it in his sys_dio proposal (that
> > > hasn't
> > > gone anywhere), and more recently I've theorized that we could add a magic
> > > fcntl/ioctl to make the kernel recognize, say, the first iovec of a
> > > O_DIRECT
> > > *{read,write}v call as the PI buffer, which I think is similar to how DIX
> > > gets
> > > PI data to a disk. But it's not like I have any code to show for it.
> > >
> > > I /think/ it's fairly straightforward to change the directio submit code
> > > to
> > > find the userspace PI buffer and amend the block integrity code to attach
> > > our
> > > own PI buffer. You'd still have to let the block layer set the sector #
> > > field,
> > > but afaik that won't affect the crc or the app tag.
> > >
> > > I hear that the NFS guys want to propose some sort of protocol for
> > > transmitting
> > > PI data (across NFS), but I haven't seen anything concrete yet.
> >
> > I'm writing a requirements document for the NFS protocol which I can
> > discuss at LSF. The use cases for NFS for now would be virtual disk
> > devices (hypervisors) or direct NFS access to storage from user space.
> >
> > Like everyone else we are waiting for a magical VFS and user space API to
> > appear that can pass PI to and from storage.
>
> I'm happy to chat about it. Unfortunately, like Darrick says, sys_dio()
> coding hasn't happened. I do think we're better off with some kind of
> explicit API than some magic state on the file. I mean, even something
> like:
>
> ssize_t write_with_pi(int fd, const void *buf, size_t count,
> const void *pi, size_t pi_count);
>
> It's not as nice as a non-historical API (eg sys_dio), but it also
> probably plays nicer with buffered I/O.
I also pondered simply adding a new io_prep_* function + IO_CMD_ code to libaio
and all the other plumbing necessary to make that happen...
void io_prep_preadv_pi(struct iocb *iocb, int fd, const struct iovec *iov,
int iovcnt, long long offset, const void *pi,
size_t pi_count);
--D
>
> Joel
>
> >
> > > Well, I hope I'll scrape together the time to hack together a PoC before
> > > LSF...
> > > on the other hand, I ran the discussion about PI userland interfaces at
> > > LPC2011
> > > and (shamefully) haven't done anything yet.
> > >
> > >
> > >
> > > --D
> > >>
> > >> Regards,
> > >> Ben
> > >> --
> > >> To unsubscribe from this list: send the line "unsubscribe linux-fsdevel"
> > >> 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-fsdevel"
> > > in
> > > the body of a message to majord...@vger.kernel.org
> > > More majordomo info at http://vger.kernel.org/majordomo-info.html
> >
> > --
> > Chuck Lever
> > chuck[dot]lever[at]oracle[dot]com
> >
> >
> >
> >
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
> > the body of a message to majord...@vger.kernel.org
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
>
> --
>
> "I think it would be a good idea."
> - Mahatma Ghandi, when asked what he thought of Western
> civilization
>
> http://www.jlbec.org/
> jl...@evilplan.org
--
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: [LSF/MM TOPIC][ATTEND] protection information and userspace
On Wed, Feb 06, 2013 at 03:34:49PM -0500, Chuck Lever wrote:
>
> On Feb 6, 2013, at 3:24 PM, "Darrick J. Wong" wrote:
>
> > On Wed, Feb 06, 2013 at 01:51:22PM -0600, Ben Myers wrote:
> >> Hi,
> >>
> >> I'm interested in discussing how to pass protection information to and from
> >> userspace. Maybe Martin could be enlisted for the discussion.
> >>
> >> I read that some work has already been done in this area but have not been
> >> able
> >> to locate it. It looks like the bio-integrity code already makes it
> >> possible
> >> to generate the t10-dif crc in the filesystem. It would be good to be
> >> able to
> >> get the guard and application tags back out to backup applications such as
> >> xfsdump. Enabling other applications to generate their own tags in
> >> userspace
> >> is also interesting.
> >
> > This one's been on my list for a couple of years (and companies) too. A few
> > years ago Joel Becker had support for it in his sys_dio proposal (that
> > hasn't
> > gone anywhere), and more recently I've theorized that we could add a magic
> > fcntl/ioctl to make the kernel recognize, say, the first iovec of a O_DIRECT
> > *{read,write}v call as the PI buffer, which I think is similar to how DIX
> > gets
> > PI data to a disk. But it's not like I have any code to show for it.
> >
> > I /think/ it's fairly straightforward to change the directio submit code to
> > find the userspace PI buffer and amend the block integrity code to attach
> > our
> > own PI buffer. You'd still have to let the block layer set the sector #
> > field,
> > but afaik that won't affect the crc or the app tag.
> >
> > I hear that the NFS guys want to propose some sort of protocol for
> > transmitting
> > PI data (across NFS), but I haven't seen anything concrete yet.
>
> I'm writing a requirements document for the NFS protocol which I can discuss
> at LSF. The use cases for NFS for now would be virtual disk devices
> (hypervisors) or direct NFS access to storage from user space.
>
> Like everyone else we are waiting for a magical VFS and user space API to
> appear that can pass PI to and from storage.
I'm happy to chat about it. Unfortunately, like Darrick says, sys_dio()
coding hasn't happened. I do think we're better off with some kind of
explicit API than some magic state on the file. I mean, even something
like:
ssize_t write_with_pi(int fd, const void *buf, size_t count,
const void *pi, size_t pi_count);
It's not as nice as a non-historical API (eg sys_dio), but it also
probably plays nicer with buffered I/O.
Joel
>
> > Well, I hope I'll scrape together the time to hack together a PoC before
> > LSF...
> > on the other hand, I ran the discussion about PI userland interfaces at
> > LPC2011
> > and (shamefully) haven't done anything yet.
> >
> >
> >
> > --D
> >>
> >> Regards,
> >>Ben
> >> --
> >> To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" 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-fsdevel" in
> > the body of a message to majord...@vger.kernel.org
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
>
> --
> Chuck Lever
> chuck[dot]lever[at]oracle[dot]com
>
>
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
"I think it would be a good idea."
- Mahatma Ghandi, when asked what he thought of Western
civilization
http://www.jlbec.org/
jl...@evilplan.org
--
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
