[PATCH 4/5] be2iscsi: Fix processing CQE before connection resources are freed
From: Jayamohan Kallickal Driver should process the completion queue entries before a connection resources are freed. While running mixed traffic due to latency, driver processes the CQE after the connection resources are freed. This fix processes all the completion queue before the connection resources are freed. Signed-off-by: John Soni Jose Signed-off-by: Jayamohan Kallickal --- drivers/scsi/be2iscsi/be_iscsi.c | 29 + drivers/scsi/be2iscsi/be_main.c | 15 ++- drivers/scsi/be2iscsi/be_main.h | 3 +++ 3 files changed, 46 insertions(+), 1 deletion(-) diff --git a/drivers/scsi/be2iscsi/be_iscsi.c b/drivers/scsi/be2iscsi/be_iscsi.c index e25203e..b7391a3 100644 --- a/drivers/scsi/be2iscsi/be_iscsi.c +++ b/drivers/scsi/be2iscsi/be_iscsi.c @@ -1274,6 +1274,31 @@ int beiscsi_ep_poll(struct iscsi_endpoint *ep, int timeout_ms) } /** + * beiscsi_flush_cq()- Flush the CQ created. + * @phba: ptr device priv structure. + * + * Before the connection resource are freed flush + * all the CQ enteries + **/ +static void beiscsi_flush_cq(struct beiscsi_hba *phba) +{ + uint16_t i; + struct be_eq_obj *pbe_eq; + struct hwi_controller *phwi_ctrlr; + struct hwi_context_memory *phwi_context; + + phwi_ctrlr = phba->phwi_ctrlr; + phwi_context = phwi_ctrlr->phwi_ctxt; + + for (i = 0; i < phba->num_cpus; i++) { + pbe_eq = &phwi_context->be_eq[i]; + blk_iopoll_disable(&pbe_eq->iopoll); + beiscsi_process_cq(pbe_eq); + blk_iopoll_enable(&pbe_eq->iopoll); + } +} + +/** * beiscsi_close_conn - Upload the connection * @ep: The iscsi endpoint * @flag: The type of connection closure @@ -1294,6 +1319,10 @@ static int beiscsi_close_conn(struct beiscsi_endpoint *beiscsi_ep, int flag) } ret = beiscsi_mccq_compl(phba, tag, NULL, NULL); + + /* Flush the CQ entries */ + beiscsi_flush_cq(phba); + return ret; } diff --git a/drivers/scsi/be2iscsi/be_main.c b/drivers/scsi/be2iscsi/be_main.c index 8f9f625..cbc9fc2 100644 --- a/drivers/scsi/be2iscsi/be_main.c +++ b/drivers/scsi/be2iscsi/be_main.c @@ -2068,7 +2068,7 @@ static void beiscsi_process_mcc_isr(struct beiscsi_hba *phba) * return * Number of Completion Entries processed. **/ -static unsigned int beiscsi_process_cq(struct be_eq_obj *pbe_eq) +unsigned int beiscsi_process_cq(struct be_eq_obj *pbe_eq) { struct be_queue_info *cq; struct sol_cqe *sol; @@ -2110,6 +2110,18 @@ static unsigned int beiscsi_process_cq(struct be_eq_obj *pbe_eq) cri_index = BE_GET_CRI_FROM_CID(cid); ep = phba->ep_array[cri_index]; + + if (ep == NULL) { + /* connection has already been freed +* just move on to next one +*/ + beiscsi_log(phba, KERN_WARNING, + BEISCSI_LOG_INIT, + "BM_%d : proc cqe of disconn ep: cid %d\n", + cid); + goto proc_next_cqe; + } + beiscsi_ep = ep->dd_data; beiscsi_conn = beiscsi_ep->conn; @@ -2219,6 +2231,7 @@ static unsigned int beiscsi_process_cq(struct be_eq_obj *pbe_eq) break; } +proc_next_cqe: AMAP_SET_BITS(struct amap_sol_cqe, valid, sol, 0); queue_tail_inc(cq); sol = queue_tail_node(cq); diff --git a/drivers/scsi/be2iscsi/be_main.h b/drivers/scsi/be2iscsi/be_main.h index 1e3428a..5f8b0fc 100644 --- a/drivers/scsi/be2iscsi/be_main.h +++ b/drivers/scsi/be2iscsi/be_main.h @@ -840,6 +840,9 @@ void beiscsi_free_mgmt_task_handles(struct beiscsi_conn *beiscsi_conn, void hwi_ring_cq_db(struct beiscsi_hba *phba, unsigned int id, unsigned int num_processed, unsigned char rearm, unsigned char event); + +unsigned int beiscsi_process_cq(struct be_eq_obj *pbe_eq); + static inline bool beiscsi_error(struct beiscsi_hba *phba) { return phba->ue_detected || phba->fw_timeout; -- 1.8.5.3 -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/5] be2iscsi: Fix updating the boot enteries in sysfs
From: Jayamohan Kallickal During port async event driver should check if there is any boot target configured on the adapter. Update sysfs enteries with the boot target parameters. Signed-off-by: Minh Tran Signed-off-by: John Soni Jose Signed-off-by: Jayamohan Kallickal --- drivers/scsi/be2iscsi/be_cmds.c | 38 -- drivers/scsi/be2iscsi/be_cmds.h | 8 drivers/scsi/be2iscsi/be_main.c | 17 + drivers/scsi/be2iscsi/be_main.h | 1 + 4 files changed, 62 insertions(+), 2 deletions(-) diff --git a/drivers/scsi/be2iscsi/be_cmds.c b/drivers/scsi/be2iscsi/be_cmds.c index ea4477f..80d97f3 100644 --- a/drivers/scsi/be2iscsi/be_cmds.c +++ b/drivers/scsi/be2iscsi/be_cmds.c @@ -275,6 +275,19 @@ bool is_link_state_evt(u32 trailer) ASYNC_EVENT_CODE_LINK_STATE); } +static bool is_iscsi_evt(u32 trailer) +{ + return ((trailer >> ASYNC_TRAILER_EVENT_CODE_SHIFT) & + ASYNC_TRAILER_EVENT_CODE_MASK) == + ASYNC_EVENT_CODE_ISCSI; +} + +static int iscsi_evt_type(u32 trailer) +{ + return (trailer >> ASYNC_TRAILER_EVENT_TYPE_SHIFT) & +ASYNC_TRAILER_EVENT_TYPE_MASK; +} + static inline bool be_mcc_compl_is_new(struct be_mcc_compl *compl) { if (compl->flags != 0) { @@ -438,7 +451,7 @@ void beiscsi_async_link_state_process(struct beiscsi_hba *phba, } else if ((evt->port_link_status & ASYNC_EVENT_LINK_UP) || ((evt->port_link_status & ASYNC_EVENT_LOGICAL) && (evt->port_fault == BEISCSI_PHY_LINK_FAULT_NONE))) { - phba->state = BE_ADAPTER_LINK_UP; + phba->state = BE_ADAPTER_LINK_UP | BE_ADAPTER_CHECK_BOOT; beiscsi_log(phba, KERN_ERR, BEISCSI_LOG_CONFIG | BEISCSI_LOG_INIT, @@ -461,7 +474,28 @@ int beiscsi_process_mcc(struct beiscsi_hba *phba) /* Interpret compl as a async link evt */ beiscsi_async_link_state_process(phba, (struct be_async_event_link_state *) compl); - else + else if (is_iscsi_evt(compl->flags)) { + switch (iscsi_evt_type(compl->flags)) { + case ASYNC_EVENT_NEW_ISCSI_TGT_DISC: + case ASYNC_EVENT_NEW_ISCSI_CONN: + case ASYNC_EVENT_NEW_TCP_CONN: + phba->state |= BE_ADAPTER_CHECK_BOOT; + beiscsi_log(phba, KERN_ERR, + BEISCSI_LOG_CONFIG | + BEISCSI_LOG_MBOX, + "BC_%d : Async iscsi Event," + " flags handled = 0x%08x\n", + compl->flags); + break; + default: + beiscsi_log(phba, KERN_ERR, + BEISCSI_LOG_CONFIG | + BEISCSI_LOG_MBOX, + "BC_%d : Unsupported Async" + " Event, flags = 0x%08x\n", + compl->flags); + } + } else beiscsi_log(phba, KERN_ERR, BEISCSI_LOG_CONFIG | BEISCSI_LOG_MBOX, diff --git a/drivers/scsi/be2iscsi/be_cmds.h b/drivers/scsi/be2iscsi/be_cmds.h index ccda0b6..9889743 100644 --- a/drivers/scsi/be2iscsi/be_cmds.h +++ b/drivers/scsi/be2iscsi/be_cmds.h @@ -118,6 +118,14 @@ struct be_mcc_compl { #define ASYNC_TRAILER_EVENT_CODE_SHIFT 8 /* bits 8 - 15 */ #define ASYNC_TRAILER_EVENT_CODE_MASK 0xFF #define ASYNC_EVENT_CODE_LINK_STATE0x1 +#define ASYNC_EVENT_CODE_ISCSI 0x4 + +#define ASYNC_TRAILER_EVENT_TYPE_SHIFT 16 /* bits 16 - 23 */ +#define ASYNC_TRAILER_EVENT_TYPE_MASK 0xF +#define ASYNC_EVENT_NEW_ISCSI_TGT_DISC 0x4 +#define ASYNC_EVENT_NEW_ISCSI_CONN 0x5 +#define ASYNC_EVENT_NEW_TCP_CONN 0x7 + struct be_async_event_trailer { u32 code; }; diff --git a/drivers/scsi/be2iscsi/be_main.c b/drivers/scsi/be2iscsi/be_main.c index d6465ed..8f9f625 100644 --- a/drivers/scsi/be2iscsi/be_main.c +++ b/drivers/scsi/be2iscsi/be_main.c @@ -4379,6 +4379,10 @@ static int beiscsi_setup_boot_info(struct beiscsi_hba *phba) { struct iscsi_boot_kobj *boot_kobj; + /* it has been created previously */ + if (phba->boot_kset) + return 0; + /* get boot info using mgmt cmd */
[PATCH 0/5] be2iscsi: Update to 10.4.74.0
From: Jayamohan Kallickal This patchset updates be2iscsi driver to 10.4.74.0 These patches are based on for-next branch of scsi.git. 0001 - Fix the sparse warning 0002 - Update the copyright year 0003 - Fix updating the boot enteries in sysfs 0004 - Fix processing CQE before freeing connection resources 0005 - Bump the driver version Thanks Jay Signed-off-by: Jayamohan Kallickal --- -- 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] be2iscsi: Bump the driver version
From: Jayamohan Kallickal Bump the driver version Signed-off-by: John Soni Jose Signed-off-by: Jayamohan Kallickal --- drivers/scsi/be2iscsi/be_main.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/scsi/be2iscsi/be_main.h b/drivers/scsi/be2iscsi/be_main.h index 5f8b0fc..3605631 100644 --- a/drivers/scsi/be2iscsi/be_main.h +++ b/drivers/scsi/be2iscsi/be_main.h @@ -36,7 +36,7 @@ #include #define DRV_NAME "be2iscsi" -#define BUILD_STR "10.2.273.0" +#define BUILD_STR "10.4.74.0" #define BE_NAME"Emulex OneConnect" \ "Open-iSCSI Driver version" BUILD_STR #define DRV_DESC BE_NAME " " "Driver" -- 1.8.5.3 -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/5] be2iscsi: Fix the sparse warning introduced in previous submission
From: Jayamohan Kallickal commit 73af08e11c6638e2abd6b1fa13cdab58c2bbdbf8 Author: Jayamohan Kallickal Date: Mon May 5 21:41:26 2014 -0400 be2iscsi: Fix interrupt Coalescing mechanism. Signed-off-by: John Soni Jose Signed-off-by: Jayamohan Kallickal --- drivers/scsi/be2iscsi/be_cmds.h | 14 +++--- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/drivers/scsi/be2iscsi/be_cmds.h b/drivers/scsi/be2iscsi/be_cmds.h index cc7405c..4e8cb61 100644 --- a/drivers/scsi/be2iscsi/be_cmds.h +++ b/drivers/scsi/be2iscsi/be_cmds.h @@ -26,9 +26,9 @@ * The commands are serviced by the ARM processor in the OneConnect's MPU. */ struct be_sge { - u32 pa_lo; - u32 pa_hi; - u32 len; + __le32 pa_lo; + __le32 pa_hi; + __le32 len; }; #define MCC_WRB_SGE_CNT_SHIFT 3/* bits 3 - 7 of dword 0 */ @@ -624,11 +624,11 @@ static inline struct be_sge *nonembedded_sgl(struct be_mcc_wrb *wrb) / Modify EQ Delay ***/ struct be_cmd_req_modify_eq_delay { struct be_cmd_req_hdr hdr; - u32 num_eq; + __le32 num_eq; struct { - u32 eq_id; - u32 phase; - u32 delay_multiplier; + __le32 eq_id; + __le32 phase; + __le32 delay_multiplier; } delay[MAX_CPUS]; } __packed; -- 1.8.5.3 -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/5] be2iscsi: Fix the copyright year
From: Jayamohan Kallickal Change the copyright year to 2014 Signed-off-by: John Soni Jose Signed-off-by: Jayamohan Kallickal --- drivers/scsi/be2iscsi/be.h | 2 +- drivers/scsi/be2iscsi/be_cmds.c | 2 +- drivers/scsi/be2iscsi/be_cmds.h | 2 +- drivers/scsi/be2iscsi/be_iscsi.c | 2 +- drivers/scsi/be2iscsi/be_iscsi.h | 2 +- drivers/scsi/be2iscsi/be_main.c | 2 +- drivers/scsi/be2iscsi/be_main.h | 2 +- drivers/scsi/be2iscsi/be_mgmt.c | 2 +- drivers/scsi/be2iscsi/be_mgmt.h | 2 +- 9 files changed, 9 insertions(+), 9 deletions(-) diff --git a/drivers/scsi/be2iscsi/be.h b/drivers/scsi/be2iscsi/be.h index 860f527..81e83a6 100644 --- a/drivers/scsi/be2iscsi/be.h +++ b/drivers/scsi/be2iscsi/be.h @@ -1,5 +1,5 @@ /** - * Copyright (C) 2005 - 2013 Emulex + * Copyright (C) 2005 - 2014 Emulex * All rights reserved. * * This program is free software; you can redistribute it and/or diff --git a/drivers/scsi/be2iscsi/be_cmds.c b/drivers/scsi/be2iscsi/be_cmds.c index 1432ed5..ea4477f 100644 --- a/drivers/scsi/be2iscsi/be_cmds.c +++ b/drivers/scsi/be2iscsi/be_cmds.c @@ -1,5 +1,5 @@ /** - * Copyright (C) 2005 - 2013 Emulex + * Copyright (C) 2005 - 2014 Emulex * All rights reserved. * * This program is free software; you can redistribute it and/or diff --git a/drivers/scsi/be2iscsi/be_cmds.h b/drivers/scsi/be2iscsi/be_cmds.h index 4e8cb61..ccda0b6 100644 --- a/drivers/scsi/be2iscsi/be_cmds.h +++ b/drivers/scsi/be2iscsi/be_cmds.h @@ -1,5 +1,5 @@ /** - * Copyright (C) 2005 - 2013 Emulex + * Copyright (C) 2005 - 2014 Emulex * All rights reserved. * * This program is free software; you can redistribute it and/or diff --git a/drivers/scsi/be2iscsi/be_iscsi.c b/drivers/scsi/be2iscsi/be_iscsi.c index 8616281..e25203e 100644 --- a/drivers/scsi/be2iscsi/be_iscsi.c +++ b/drivers/scsi/be2iscsi/be_iscsi.c @@ -1,5 +1,5 @@ /** - * Copyright (C) 2005 - 2013 Emulex + * Copyright (C) 2005 - 2014 Emulex * All rights reserved. * * This program is free software; you can redistribute it and/or diff --git a/drivers/scsi/be2iscsi/be_iscsi.h b/drivers/scsi/be2iscsi/be_iscsi.h index 31ddc84..e0b3b2d 100644 --- a/drivers/scsi/be2iscsi/be_iscsi.h +++ b/drivers/scsi/be2iscsi/be_iscsi.h @@ -1,5 +1,5 @@ /** - * Copyright (C) 2005 - 2013 Emulex + * Copyright (C) 2005 - 2014 Emulex * All rights reserved. * * This program is free software; you can redistribute it and/or diff --git a/drivers/scsi/be2iscsi/be_main.c b/drivers/scsi/be2iscsi/be_main.c index 56467df..d6465ed 100644 --- a/drivers/scsi/be2iscsi/be_main.c +++ b/drivers/scsi/be2iscsi/be_main.c @@ -1,5 +1,5 @@ /** - * Copyright (C) 2005 - 2013 Emulex + * Copyright (C) 2005 - 2014 Emulex * All rights reserved. * * This program is free software; you can redistribute it and/or diff --git a/drivers/scsi/be2iscsi/be_main.h b/drivers/scsi/be2iscsi/be_main.h index 9ceab42..0ca9d2d 100644 --- a/drivers/scsi/be2iscsi/be_main.h +++ b/drivers/scsi/be2iscsi/be_main.h @@ -1,5 +1,5 @@ /** - * Copyright (C) 2005 - 2013 Emulex + * Copyright (C) 2005 - 2014 Emulex * All rights reserved. * * This program is free software; you can redistribute it and/or diff --git a/drivers/scsi/be2iscsi/be_mgmt.c b/drivers/scsi/be2iscsi/be_mgmt.c index a3e5648..785deb3 100644 --- a/drivers/scsi/be2iscsi/be_mgmt.c +++ b/drivers/scsi/be2iscsi/be_mgmt.c @@ -1,5 +1,5 @@ /** - * Copyright (C) 2005 - 2013 Emulex + * Copyright (C) 2005 - 2014 Emulex * All rights reserved. * * This program is free software; you can redistribute it and/or diff --git a/drivers/scsi/be2iscsi/be_mgmt.h b/drivers/scsi/be2iscsi/be_mgmt.h index 24a8fc5..bd81446 100644 --- a/drivers/scsi/be2iscsi/be_mgmt.h +++ b/drivers/scsi/be2iscsi/be_mgmt.h @@ -1,5 +1,5 @@ /** - * Copyright (C) 2005 - 2013 Emulex + * Copyright (C) 2005 - 2014 Emulex * All rights reserved. * * This program is free software; you can redistribute it and/or -- 1.8.5.3 -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] libsas: modify SATA error handler
[ adding yuxia...@marvell.com ] On Tue, Jun 3, 2014 at 6:41 PM, Dan Williams wrote: > Hi, some notes below: > > On Thu, Apr 24, 2014 at 6:27 AM, Xiangliang Yu wrote: >> Add support for SATA port softreset and port multiplier error >> handling. > > Some more detailed notes about the approach and any caveats would be > appreciated. > >> >> Signed-off-by: Xiangliang Yu >> --- >> drivers/scsi/libsas/sas_ata.c | 226 >> - >> include/scsi/libsas.h |6 + >> 2 files changed, 231 insertions(+), 1 deletions(-) >> >> diff --git a/drivers/scsi/libsas/sas_ata.c b/drivers/scsi/libsas/sas_ata.c >> index 766098a..29a19fd 100644 >> --- a/drivers/scsi/libsas/sas_ata.c >> +++ b/drivers/scsi/libsas/sas_ata.c >> @@ -442,6 +442,226 @@ static int sas_ata_hard_reset(struct ata_link *link, >> unsigned int *class, >> return ret; >> } >> >> +static void sas_ata_freeze(struct ata_port *ap) >> +{ >> + struct domain_device *dev = ap->private_data; >> + struct sas_ha_struct *sas_ha = dev->port->ha; >> + struct Scsi_Host *host = sas_ha->core.shost; >> + struct sas_internal *i = to_sas_internal(host->transportt); >> + >> + if (i->dft->lldd_dev_freeze) >> + i->dft->lldd_dev_freeze(dev); >> +} >> + >> +static void sas_ata_thaw(struct ata_port *ap) >> +{ >> + struct domain_device *dev = ap->private_data; >> + struct sas_ha_struct *sas_ha = dev->port->ha; >> + struct Scsi_Host *host = sas_ha->core.shost; >> + struct sas_internal *i = to_sas_internal(host->transportt); >> + >> + if (i->dft->lldd_dev_thaw) >> + i->dft->lldd_dev_thaw(dev); >> +} >> + >> +static int sas_ata_wait_task_done(struct sas_task *task, unsigned long >> timeout, >> + int (*check_done)(struct sas_task *task)) >> +{ > > Why do we need a custom check_done() routine? Since we have a > sas_task we can use the normal completion infrastructure. See > smp_execute_task(). > >> + struct ata_port *ap = task->uldd_task; >> + unsigned long deadline; >> + int done; >> + >> + if (!check_done) { >> + SAS_DPRINTK("check function is null.\n"); >> + return -1; >> + } >> + >> + deadline = ata_deadline(jiffies, timeout); >> + done = check_done(task); >> + >> + while (done && time_before(jiffies, deadline)) { >> + ata_msleep(ap, 1); >> + >> + done = check_done(task); > > This can simply be: > > completion_done(&task->slow_task->completion) > >> + } >> + >> + return done; >> +} >> + >> +static int sas_ata_exec_polled_cmd(struct ata_port *ap, struct ata_taskfile >> *tf, >> + int pmp, unsigned long timeout) >> +{ >> + struct domain_device *dev = ap->private_data; >> + struct sas_ha_struct *sas_ha = dev->port->ha; >> + struct Scsi_Host *host = sas_ha->core.shost; >> + struct sas_internal *i = to_sas_internal(host->transportt); >> + struct sas_task *task = NULL; >> + int ret = -1; >> + >> + if (!i->dft->lldd_execute_task) { >> + SAS_DPRINTK("execute function is null.\n"); >> + return ret; >> + } >> + >> + task = sas_alloc_task(GFP_ATOMIC); > > I think this can be downgraded to GFP_NOIO. We're in a sleepable context. > >> + if (!task) { >> + SAS_DPRINTK("failed to alloc sas task.\n"); >> + goto fail; >> + } >> + >> + task->dev = dev; >> + task->task_proto = SAS_PROTOCOL_SATA; >> + task->uldd_task = ap; >> + >> + ata_tf_to_fis(tf, pmp, 0, (u8 *)&task->ata_task.fis); >> + task->ata_task.retry_count = 1; >> + task->task_state_flags = SAS_TASK_STATE_PENDING; >> + task->task_state_flags |= SAS_TASK_NEED_DEV_RESET; >> + >> + ret = i->dft->lldd_execute_task(task, 1, GFP_ATOMIC); > > Same here. > >> + if (ret) { >> + SAS_DPRINTK("failed to send internal task.\n"); >> + goto fail; >> + } >> + >> + if (timeout) { >> + ret = sas_ata_wait_task_done(task, timeout, >> + i->dft->lldd_wait_task_done); >> + if (ret) { >> + SAS_DPRINTK("get wrong status.\n"); >> + goto fail; >> + } >> + } >> + list_del_init(&task->list); >> + sas_free_task(task); >> + >> + return 0; >> +fail: >> + if (task) { >> + list_del_init(&task->list); >> + sas_free_task(task); >> + } >> + >> + return ret; >> +} >> + >> +static int sas_ata_soft_reset(struct ata_link *link, unsigned int *class, >> + unsigned long deadline) >> +{ >> + struct ata_taskfile tf; >> + struct ata_port *ap = link->ap; >> + struct domain_device *dev = ap->private_data; >> + struct sas_ha_struct *sas_ha = dev->port->ha; >> +
[Bug 81861] mvsas.ko v0.8.16 error messages and kernel crashes attaching 4 SATA drives to specific HP SAS expander ports
https://bugzilla.kernel.org/show_bug.cgi?id=81861 linux-...@crashplan.pro changed: What|Removed |Added Kernel Version|3.16.0-031600rc6|3.16.0-031600rc6.x86_64 -- You are receiving this mail because: You are watching the assignee of the bug. -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[Bug 81861] New: mvsas.ko v0.8.16 error messages and kernel crashes attaching 4 SATA drives to specific HP SAS expander ports
https://bugzilla.kernel.org/show_bug.cgi?id=81861 Bug ID: 81861 Summary: mvsas.ko v0.8.16 error messages and kernel crashes attaching 4 SATA drives to specific HP SAS expander ports Product: SCSI Drivers Version: 2.5 Kernel Version: 3.16.0-031600rc6 Hardware: x86-64 OS: Linux Tree: Mainline Status: NEW Severity: blocking Priority: P1 Component: Other Assignee: scsi_drivers-ot...@kernel-bugs.osdl.org Reporter: linux-...@crashplan.pro Regression: No The issues are (1) error messages and (2) kernel crashes when attaching 4 drives (1 SFF SAS cable) to specific ports of a SAS expander. The issue is only tested with HP SAS port expander (PMC Sierra PM8005 chip) running firmware 2.08. This expander has 36/4=9 SAS ports. 1 port of type SFF-8088, labelled 1C on the PCB. 8 port of type SFF-8087, labelled 2C till 9C on the PCB. Port “1C” is connected to a Supermicro SAS2LP-MV8, Marvell 88SE9485 based chip, lspci output is inserted below. The issue is not always identical. When attaching the 4 drives to different port numbers on the port multiplier, this is what happens in this order: 2C, 3C, 4C = ok 5C = error 6C, 7C, 8C = kernel crash 9C = error After that first run from port 2 till 9, the issue seems more random: 9C = kernel crash 4C = kernel crash 3C = error 9C = error 7C = kernel crash 3C = error 2C = ok 4C = kernel crash The “error message” on ports 5C and 9C is: scsi 5:0:4:0: Failed to get diagnostic page 0x802 scsi 5:0:4:0: Failed to bind enclosure -19 Most testing is done with Ubuntu 14.04.1 running Ubuntu’s supplied mainline kernel 3.16.0-rc6. # modprobe -v mvsas insmod /lib/modules/3.16.0-031600rc6-generic/kernel/drivers/scsi/scsi_transport_sas.ko insmod /lib/modules/3.16.0-031600rc6-generic/kernel/drivers/scsi/libsas/libsas.ko insmod /lib/modules/3.16.0-031600rc6-generic/kernel/drivers/scsi/mvsas/mvsas.ko = Other tested kernels, with similar results = kernel Mainline 3.16-20140724 kernel Ubuntu 3.13.11 kernel Ubuntu 3.13.0-24 kernel Ubuntu 3.12.25 kernel Ubuntu 2.6.32 = no SAS expander detected -> no further testing = No drives attached to expander # lsscsi [4:0:0:0]diskATA OCZ-VERTEX 1.3 /dev/sda [5:0:0:0]enclosu HP HP SAS EXP Card 2.08 - With 4 drives (brown#4) attached to expander port 2C # lsscsi [4:0:0:0]diskATA OCZ-VERTEX 1.3 /dev/sda [6:0:0:0]diskATA Hitachi HDS5C302 AAB0 /dev/sdb [6:0:1:0]diskATA Hitachi HDS5C302 AAB0 /dev/sdc [6:0:2:0]diskATA Hitachi HDS5C302 AAB0 /dev/sdd [6:0:3:0]diskATA Hitachi HDS5C302 AAB0 /dev/sde [6:0:4:0]enclosu HP HP SAS EXP Card 2.08 - With 4 drives (brown#4) attached to expander port 3C # lsscsi [4:0:0:0]diskATA OCZ-VERTEX 1.3 /dev/sda [6:0:4:0]enclosu HP HP SAS EXP Card 2.08 - [6:0:5:0]diskATA Hitachi HDS5C302 AAB0 /dev/sdb [6:0:6:0]diskATA Hitachi HDS5C302 AAB0 /dev/sdc [6:0:7:0]diskATA Hitachi HDS5C302 AAB0 /dev/sdd [6:0:8:0]diskATA Hitachi HDS5C302 AAB0 /dev/sde With 4 drives (brown#4) attached to expander port 4C # lsscsi [4:0:0:0]diskATA OCZ-VERTEX 1.3 /dev/sda [6:0:4:0]enclosu HP HP SAS EXP Card 2.08 - [6:0:9:0]diskATA Hitachi HDS5C302 AAB0 /dev/sdb [6:0:10:0] diskATA Hitachi HDS5C302 AAB0 /dev/sdc [6:0:11:0] diskATA Hitachi HDS5C302 AAB0 /dev/sdd [6:0:12:0] diskATA Hitachi HDS5C302 AAB0 /dev/sde With 4 drives (brown#4) attached to expander port 5C scsi 5:0:4:0: Failed to get diagnostic page 0x802 scsi 5:0:4:0: Failed to bind enclosure -19 # lsscsi [4:0:0:0]diskATA OCZ-VERTEX 1.3 /dev/sda [5:0:4:0]enclosu HP HP SAS EXP Card 2.08 - With 4 drives (brown#4) attached to expander port 6C Kernel crash (data from OCR-ed screenshot): [ 263.190030] R13 88020e837808 R14: 88021b4a0080 R15: 880036cll200 [ 269.130052] FS: 7f9ef5abb740() GS:88021b20() knlGS: [ 269.190074] CS: 0010 DS: ES: CR0: 80050033 [ 269.190091] CR2 7f9ef5ac2000 CR3: 00020fbd8000 CR4: 000407f0 [ 269.190111] Stack: [ 269.190118] 0002 88021f5f7f08 dead00200200 [ 269.190145] 38020dl037b0 0046 88020eb81e38 811b06ae [ 269.190171] 38020e837798 88020d69bl40 88020dl037b0 88020dl0 [ 269.190197] Call Trace: [ 269.190210] [] ? dma_pool_alloc+0xce/0x100 [ 269.190229] [] mvs_task_prep+0x58b/0x620 [
[Bug 80711] [PATCH]SG_FLAG_LUN_INHIBIT is no longer implemented and there's not way to prevent the kernel from using the 2nd cdb byte for the LUN
https://bugzilla.kernel.org/show_bug.cgi?id=80711 --- Comment #9 from Tiziano Bacocco --- (In reply to Alan Stern from comment #8) > On Wed, 6 Aug 2014, Christoph Hellwig wrote: > > > On Wed, Aug 06, 2014 at 04:02:22PM -0400, Alan Stern wrote: > > > > I doubt either of them forces users to hack up flags for these cases. > > > > > > Why was this change needed in the first place? There's no explanation > > > in the patch itself. > > > > Which chance? The one to not support SG_FLAG_LUN_INHIBIT? > > No, the patch that started this Bugzilla entry. Tiziano says it is > needed in order to send vendor-specific commands that use the LUN bits > in CDB[1]. > > > > > At least for windows I suspect it just never sends the LUN encoded > > > > in the CDB and treats USB devices special instead of our insistance > > > > on pretending they are SCSI-2. > > > > > > We no longer pretend that USB mass-storage devices have any particular > > > SCSI level. See commit 09b6b51b0b6c. > > > > So the origina reported device must report SCSI-2 all by itself if he's > > running a recent kernel, ok. > > > > > > Maybe some of the USB people have on the wire traces or access to > > > > device or windows documentation on this? > > > > > > Most likely it varies with the version of Windows and the INQUIRY data > > > returned by the device. > > > > > > I can obtain hardware traces for the kinds of devices and computers > > > lying around here. But what sort of combinations should I test? > > > > I'd mostly be interested to see if it actualy encodes the LUN in the CDB > > for any USB multi-LUN device. > > I tried connecting a Linux mass-storage gadget with two logical units > to a host PC running Windows 7. The host scanned the first logical > unit and completely ignored the second! Didn't even send an INQUIRY > command. > > So the question remains unanswered... > > Can someone tell me if anything special is needed to make Windows > recognize logical units beyond the first? > > Alan Stern That's weird , old android phones which use multiple LUNs and Linux usb gadgets , had internal memory and SD card , and they worked on windows -- You are receiving this mail because: You are the assignee for the bug. -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[Bug 80711] [PATCH]SG_FLAG_LUN_INHIBIT is no longer implemented and there's not way to prevent the kernel from using the 2nd cdb byte for the LUN
https://bugzilla.kernel.org/show_bug.cgi?id=80711 --- Comment #8 from Alan Stern --- On Wed, 6 Aug 2014, Christoph Hellwig wrote: > On Wed, Aug 06, 2014 at 04:02:22PM -0400, Alan Stern wrote: > > > I doubt either of them forces users to hack up flags for these cases. > > > > Why was this change needed in the first place? There's no explanation > > in the patch itself. > > Which chance? The one to not support SG_FLAG_LUN_INHIBIT? No, the patch that started this Bugzilla entry. Tiziano says it is needed in order to send vendor-specific commands that use the LUN bits in CDB[1]. > > > At least for windows I suspect it just never sends the LUN encoded > > > in the CDB and treats USB devices special instead of our insistance > > > on pretending they are SCSI-2. > > > > We no longer pretend that USB mass-storage devices have any particular > > SCSI level. See commit 09b6b51b0b6c. > > So the origina reported device must report SCSI-2 all by itself if he's > running a recent kernel, ok. > > > > Maybe some of the USB people have on the wire traces or access to > > > device or windows documentation on this? > > > > Most likely it varies with the version of Windows and the INQUIRY data > > returned by the device. > > > > I can obtain hardware traces for the kinds of devices and computers > > lying around here. But what sort of combinations should I test? > > I'd mostly be interested to see if it actualy encodes the LUN in the CDB > for any USB multi-LUN device. I tried connecting a Linux mass-storage gadget with two logical units to a host PC running Windows 7. The host scanned the first logical unit and completely ignored the second! Didn't even send an INQUIRY command. So the question remains unanswered... Can someone tell me if anything special is needed to make Windows recognize logical units beyond the first? Alan Stern -- You are receiving this mail because: You are the assignee for the bug. -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Bug 80711] [PATCH]SG_FLAG_LUN_INHIBIT is no longer implemented and there's not way to prevent the kernel from using the 2nd cdb byte for the LUN
On Wed, 6 Aug 2014, Christoph Hellwig wrote: > On Wed, Aug 06, 2014 at 04:02:22PM -0400, Alan Stern wrote: > > > I doubt either of them forces users to hack up flags for these cases. > > > > Why was this change needed in the first place? There's no explanation > > in the patch itself. > > Which chance? The one to not support SG_FLAG_LUN_INHIBIT? No, the patch that started this Bugzilla entry. Tiziano says it is needed in order to send vendor-specific commands that use the LUN bits in CDB[1]. > > > At least for windows I suspect it just never sends the LUN encoded > > > in the CDB and treats USB devices special instead of our insistance > > > on pretending they are SCSI-2. > > > > We no longer pretend that USB mass-storage devices have any particular > > SCSI level. See commit 09b6b51b0b6c. > > So the origina reported device must report SCSI-2 all by itself if he's > running a recent kernel, ok. > > > > Maybe some of the USB people have on the wire traces or access to > > > device or windows documentation on this? > > > > Most likely it varies with the version of Windows and the INQUIRY data > > returned by the device. > > > > I can obtain hardware traces for the kinds of devices and computers > > lying around here. But what sort of combinations should I test? > > I'd mostly be interested to see if it actualy encodes the LUN in the CDB > for any USB multi-LUN device. I tried connecting a Linux mass-storage gadget with two logical units to a host PC running Windows 7. The host scanned the first logical unit and completely ignored the second! Didn't even send an INQUIRY command. So the question remains unanswered... Can someone tell me if anything special is needed to make Windows recognize logical units beyond the first? Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v1.3 3/18] arcmsr: Add code to support system hibernation
On 08/01/2014 10:36 AM, Ching Huang wrote: > This patch adds code to support system hibernation. > > Signed-off-by: Ching > --- > > diff -uprN a/drivers/scsi/arcmsr/arcmsr_hba.c > b/drivers/scsi/arcmsr/arcmsr_hba.c > --- a/drivers/scsi/arcmsr/arcmsr_hba.c2014-08-01 11:03:00.0 > +0800 > +++ b/drivers/scsi/arcmsr/arcmsr_hba.c2014-08-01 11:04:28.0 > +0800 > @@ -89,11 +89,15 @@ static int arcmsr_bios_param(struct scsi > static int arcmsr_queue_command(struct Scsi_Host *h, struct scsi_cmnd *cmd); > static int arcmsr_probe(struct pci_dev *pdev, > const struct pci_device_id *id); > +static int arcmsr_suspend(struct pci_dev *pdev, pm_message_t state); > +static int arcmsr_resume(struct pci_dev *pdev); > static void arcmsr_remove(struct pci_dev *pdev); > static void arcmsr_shutdown(struct pci_dev *pdev); > static void arcmsr_iop_init(struct AdapterControlBlock *acb); > static void arcmsr_free_ccb_pool(struct AdapterControlBlock *acb); > static u32 arcmsr_disable_outbound_ints(struct AdapterControlBlock *acb); > +static void arcmsr_enable_outbound_ints(struct AdapterControlBlock *acb, > + u32 intmask_org); > static void arcmsr_stop_adapter_bgrb(struct AdapterControlBlock *acb); > static void arcmsr_flush_hba_cache(struct AdapterControlBlock *acb); > static void arcmsr_flush_hbb_cache(struct AdapterControlBlock *acb); > @@ -167,6 +171,8 @@ static struct pci_driver arcmsr_pci_driv > .id_table = arcmsr_device_id_table, > .probe = arcmsr_probe, > .remove = arcmsr_remove, > + .suspend= arcmsr_suspend, > + .resume = arcmsr_resume, > .shutdown = arcmsr_shutdown, > }; > /* > @@ -776,6 +782,77 @@ static void arcmsr_free_irq(struct pci_d > free_irq(pdev->irq, acb); > } > > +static int arcmsr_suspend(struct pci_dev *pdev, pm_message_t state) > +{ > + uint32_t intmask_org; > + struct Scsi_Host *host = pci_get_drvdata(pdev); > + struct AdapterControlBlock *acb = > + (struct AdapterControlBlock *)host->hostdata; > + > + intmask_org = arcmsr_disable_outbound_ints(acb); > + arcmsr_free_irq(pdev, acb); > + del_timer_sync(&acb->eternal_timer); > + flush_scheduled_work(); > + arcmsr_stop_adapter_bgrb(acb); > + arcmsr_flush_adapter_cache(acb); > + arcmsr_enable_outbound_ints(acb, intmask_org); > + pci_set_drvdata(pdev, host); > + pci_save_state(pdev); > + pci_disable_device(pdev); > + pci_set_power_state(pdev, pci_choose_state(pdev, state)); > + return 0; its' probably better to disable interrupts on card (arcmsr_enable_outbound_ints) and after that deregister the isr functions (arcmsr_free_irq) > +} > + > +static int arcmsr_resume(struct pci_dev *pdev) > +{ > + int error; > + struct Scsi_Host *host = pci_get_drvdata(pdev); > + struct AdapterControlBlock *acb = > + (struct AdapterControlBlock *)host->hostdata; > + > + pci_set_power_state(pdev, PCI_D0); > + pci_enable_wake(pdev, PCI_D0, 0); > + pci_restore_state(pdev); > + if (pci_enable_device(pdev)) { > + pr_warn("%s: pci_enable_device error\n", __func__); > + return -ENODEV; > + } a significant part of this code is equal to what is done in arcmsr_probe is it possible to do it in an special function in one place ? > + error = pci_set_dma_mask(pdev, DMA_BIT_MASK(64)); > + if (error) { > + error = pci_set_dma_mask(pdev, DMA_BIT_MASK(32)); > + if (error) { > + pr_warn("scsi%d: No suitable DMA mask available\n", > +host->host_no); > + goto controller_unregister; > + } > + } > + pci_set_master(pdev); > + if (arcmsr_request_irq(pdev, acb) == ARC_FAILURE) > + goto controller_stop; > + arcmsr_iop_init(acb); > + INIT_WORK(&acb->arcmsr_do_message_isr_bh, arcmsr_message_isr_bh_fn); > + atomic_set(&acb->rq_map_token, 16); > + atomic_set(&acb->ante_token_value, 16); > + acb->fw_flag = FW_NORMAL; > + init_timer(&acb->eternal_timer); > + acb->eternal_timer.expires = jiffies + msecs_to_jiffies(6 * HZ); > + acb->eternal_timer.data = (unsigned long) acb; > + acb->eternal_timer.function = &arcmsr_request_device_map; > + add_timer(&acb->eternal_timer); > + return 0; > +controller_stop: > + arcmsr_stop_adapter_bgrb(acb); > + arcmsr_flush_adapter_cache(acb); > +controller_unregister: > + scsi_remove_host(host); > + arcmsr_free_ccb_pool(acb); > + arcmsr_unmap_pciregion(acb); > + pci_release_regions(pdev); > + scsi_host_put(host); > + pci_disable_device(pdev); > + return -ENODEV; > +} > + > static uint8_t arcmsr_abort_hba_allcmd(struct AdapterControlBlock *acb) > { > struct MessageUnit_A __iomem *reg = acb->pmuA; If
Re: [PATCH] scsi: Check if WSR already defined
On 08/07/2014 07:38 AM, Nick Krause wrote: On xtensa arch there is this warning drivers/scsi/sym53c8xx_2/sym_defs.h:109:0: warning: "WSR" redefined [enabled by default] arch/xtensa/include/asm/processor.h:188:0: note: this is the location of the previous definition I can remove WSR since it is not being used but more documentation purpose, so undefining is enough. Signed-off-by: Nick Krause --- drivers/scsi/sym53c8xx_2/sym_defs.h | 4 1 file changed, 4 insertions(+) diff --git a/drivers/scsi/sym53c8xx_2/sym_defs.h b/drivers/scsi/sym53c8xx_2/sym_defs.h index defccc4..68334a5 100644 --- a/drivers/scsi/sym53c8xx_2/sym_defs.h +++ b/drivers/scsi/sym53c8xx_2/sym_defs.h @@ -91,6 +91,10 @@ struct sym_chip { #define FE_CACHE0_SET (FE_CACHE_SET & ~FE_ERL) }; +#ifdef WSR +#undef WSR +#endif + /* *SYM53C8XX IO register data structure. */ Ouch. Certainly not. Who knows for which odd function the 'WSR' definition is used. Better to redefine WSR in sym_defs.h. 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 v1.3 4/18] arcmsr: limit max. number of SCSI command request
On 08/04/2014 06:00 AM, Ching Huang wrote: > On Fri, 2014-08-01 at 05:35 -0700, Christoph Hellwig wrote: >>> @@ -2220,8 +2220,7 @@ static int arcmsr_queue_command_lck(stru >>> arcmsr_handle_virtual_command(acb, cmd); >>> return 0; >>> } >>> - if (atomic_read(&acb->ccboutstandingcount) >= >>> - ARCMSR_MAX_OUTSTANDING_CMD) >>> + if (atomic_read(&acb->ccboutstandingcount) >= acb->maxOutstanding) >>> return SCSI_MLQUEUE_HOST_BUSY; >> The scsi midlayer already takes care of this check for you. >> > Hello Christoph, > > We have 4 types of Adapter that some adpaters have command queue less > than ARCMSR_MAX_OUTSTANDING_CMD. > So we have to check outstanding command number here. I think you could set the correct value of can_queue in arcmsr_probe after you have read the firmware spec. > > Thanks for your comment. > Ching > > -- > To unsubscribe from this list: send the line "unsubscribe linux-scsi" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v1.3 1/18] arcmsr: Revised interrupt service routine relate function to fix bug
On 08/01/2014 10:28 AM, Ching Huang wrote: > This patch rewrite the interrupt service routine relate function to fix > command timeout when controller has very > heavy loading. > > Signed-off-by: Ching > --- > > diff -uprN a/drivers/scsi/arcmsr/arcmsr.h b/drivers/scsi/arcmsr/arcmsr.h > --- a/drivers/scsi/arcmsr/arcmsr.h2014-07-30 10:33:02.0 +0800 > +++ b/drivers/scsi/arcmsr/arcmsr.h2014-04-28 16:02:46.0 +0800 > @@ -51,7 +51,7 @@ struct device_attribute; > #else > #define ARCMSR_MAX_FREECCB_NUM 320 > #endif > -#define ARCMSR_DRIVER_VERSION "Driver Version 1.20.00.15 > 2010/08/05" > +#define ARCMSR_DRIVER_VERSION"v1.30.00.04-20140428" > #define ARCMSR_SCSI_INITIATOR_ID > 255 > #define ARCMSR_MAX_XFER_SECTORS > 512 > #define ARCMSR_MAX_XFER_SECTORS_B > 4096 > diff -uprN a/drivers/scsi/arcmsr/arcmsr_hba.c > b/drivers/scsi/arcmsr/arcmsr_hba.c > --- a/drivers/scsi/arcmsr/arcmsr_hba.c2014-07-30 10:32:28.0 > +0800 > +++ b/drivers/scsi/arcmsr/arcmsr_hba.c2014-08-01 11:02:44.0 > +0800 > @@ -1441,14 +1441,15 @@ static void arcmsr_hba_doorbell_isr(stru > uint32_t outbound_doorbell; > struct MessageUnit_A __iomem *reg = acb->pmuA; > outbound_doorbell = readl(®->outbound_doorbell); > - writel(outbound_doorbell, ®->outbound_doorbell); > - if (outbound_doorbell & ARCMSR_OUTBOUND_IOP331_DATA_WRITE_OK) { > - arcmsr_iop2drv_data_wrote_handle(acb); > - } > - > - if (outbound_doorbell & ARCMSR_OUTBOUND_IOP331_DATA_READ_OK) { > - arcmsr_iop2drv_data_read_handle(acb); > - } > + do { > + writel(outbound_doorbell, ®->outbound_doorbell); > + if (outbound_doorbell & ARCMSR_OUTBOUND_IOP331_DATA_WRITE_OK) > + arcmsr_iop2drv_data_wrote_handle(acb); > + if (outbound_doorbell & ARCMSR_OUTBOUND_IOP331_DATA_READ_OK) > + arcmsr_iop2drv_data_read_handle(acb); > + outbound_doorbell = readl(®->outbound_doorbell); > + } while (outbound_doorbell & (ARCMSR_OUTBOUND_IOP331_DATA_WRITE_OK > + | ARCMSR_OUTBOUND_IOP331_DATA_READ_OK)); > } > static void arcmsr_hbc_doorbell_isr(struct AdapterControlBlock *pACB) > { > @@ -1462,17 +1463,19 @@ static void arcmsr_hbc_doorbell_isr(stru > *** > */ > outbound_doorbell = readl(®->outbound_doorbell); > - writel(outbound_doorbell, ®->outbound_doorbell_clear);/*clear > interrupt*/ > - if (outbound_doorbell & ARCMSR_HBCMU_IOP2DRV_DATA_WRITE_OK) { > - arcmsr_iop2drv_data_wrote_handle(pACB); > - } > - if (outbound_doorbell & ARCMSR_HBCMU_IOP2DRV_DATA_READ_OK) { > - arcmsr_iop2drv_data_read_handle(pACB); > - } > - if (outbound_doorbell & ARCMSR_HBCMU_IOP2DRV_MESSAGE_CMD_DONE) { > - arcmsr_hbc_message_isr(pACB);/* messenger of "driver to iop > commands" */ > - } > - return; > + do { > + writel(outbound_doorbell, ®->outbound_doorbell_clear); > + readl(®->outbound_doorbell_clear); > + if (outbound_doorbell & ARCMSR_HBCMU_IOP2DRV_DATA_WRITE_OK) > + arcmsr_iop2drv_data_wrote_handle(pACB); > + if (outbound_doorbell & ARCMSR_HBCMU_IOP2DRV_DATA_READ_OK) > + arcmsr_iop2drv_data_read_handle(pACB); > + if (outbound_doorbell & ARCMSR_HBCMU_IOP2DRV_MESSAGE_CMD_DONE) > + arcmsr_hbc_message_isr(pACB); > + outbound_doorbell = readl(®->outbound_doorbell); > + } while (outbound_doorbell & (ARCMSR_HBCMU_IOP2DRV_DATA_WRITE_OK > + | ARCMSR_HBCMU_IOP2DRV_DATA_READ_OK > + | ARCMSR_HBCMU_IOP2DRV_MESSAGE_CMD_DONE)); > } > static void arcmsr_hba_postqueue_isr(struct AdapterControlBlock *acb) > { > @@ -1521,21 +1524,22 @@ static void arcmsr_hbc_postqueue_isr(str > /* areca cdb command done */ > /* Use correct offset and size for syncing */ > > - while (readl(&phbcmu->host_int_status) & > - ARCMSR_HBCMU_OUTBOUND_POSTQUEUE_ISR){ > - /* check if command done with no error*/ > - flag_ccb = readl(&phbcmu->outbound_queueport_low); > - ccb_cdb_phy = (flag_ccb & 0xFFF0);/*frame must be 32 bytes aligned*/ > - arcmsr_cdb = (struct ARCMSR_CDB *)(acb->vir2phy_offset + ccb_cdb_phy); > - ccb = container_of(arcmsr_cdb, struct CommandControlBlock, arcmsr_cdb); > - error = (flag_ccb & ARCMSR_CCBREPLY_FLAG_ERROR_MODE1) ? true : false; > - /* check if command done with no error */ > - arcmsr_drain_donequeue(acb, ccb, error); > - if (throttling == ARCMSR_HBC_ISR_THROTTLING_LEVEL) { > - writel(ARCMSR_HBCMU_DRV2IOP_POSTQUEUE_THROTTLING, > &phbcmu->inbound_do