Re: iscsi_trx going into D state

OK, I've drilled down a little more and timeout = action(timeout); in do_wait_for_common() in kernel/sched/completion.c is not returning. I'll have to see if I can make more progress tomorrow. Robert LeBlanc PGP Fingerprint 79A2 9CA4 6CC4 45DD A904 C70E E654 3BB2 FA62 B9F1 On

Re: [PATCH v2 03/11] lpfc: Deprecate lpfc_soft_wwn parameter

James, thank you for taking the time to answer me. James Smart wrote: > Sebastian, > > "not portable" isn't the right way to describe it. It's not a > chip-architecture issue, but rather that some oem platforms have > side-band management that overrides anything that could have been > done in

[PATCH] qla2xxx: rename {vendor|hba}_indentifer to {vendor|hba}_identifer

From: Colin Ian King Rename the vendor_indentifer and hba_indentifer fields to correct spelling. Signed-off-by: Colin Ian King --- drivers/scsi/qla2xxx/qla_def.h | 4 ++-- drivers/scsi/qla2xxx/qla_gs.c | 6 +++--- 2 files changed, 5

Re: iscsi_trx going into D state

I know most people are ignoring this thread by now, but I hope someone is still reading and can offer some ideas. It looks like ib_drain_qp_done() is not being called the first time that __ib_drain_sq() is called from iscsit_close_connection(). I tried to debug wait_for_completion() and friends,

RE: [Open-FCoE] [PATCH RFC net-next 1/5] qed: Add support for hardware offloaded FCoE.

> > +struct fcoe_tstorm_fcoe_task_st_ctx_read_write { > > + union fcoe_cleanup_addr_exp_ro_union > cleanup_addr_exp_ro_union; > > + __le16 flags; > > +#define > FCOE_TSTORM_FCOE_TASK_ST_CTX_READ_WRITE_RX_SGL_MODE_MASK > 0x7 > > +#define >

Re: [PATCH v2 03/11] lpfc: Deprecate lpfc_soft_wwn parameter

ok.. I'll submit a patch to re-add the parameters, and add an appropriate "deprecation" warning -- james On 12/28/2016 11:41 PM, Christoph Hellwig wrote: Hi James, in Linux we have a pretty clear policy to avoid breaking existing real life userspace. Given that Sebastian (and probably

Re: [PATCH] scsi: mpt3sas: fix hang on ata passthru commands

From: Jason Baron Date: Wed, 28 Dec 2016 23:30:24 -0500 > On ata passthru commands scsih_qcmd() ends up spinning in > scsi_wait_for_queuecommand() indefinitely. scsih_qcmd() is called from > __blk_run_queue_uncond() which first increments request_fn_active to a > non-zero

Re: [PATCH] scsi: mpt3sas: fix hang on ata passthru commands

On 12/29/2016 03:02 AM, Christoph Hellwig wrote: > On Wed, Dec 28, 2016 at 11:30:24PM -0500, Jason Baron wrote: >> Add a new parameter to scsi_internal_device_block() to decide whether >> or not to invoke scsi_wait_for_queuecommand(). > We'll also need to deal with the blk-mq wait path that Bart

[Bug 191471] New: Mp2Sas and Mpt3Sas (now mpxsas) drivers are spinning forever in the IRQ handler under load condition

https://bugzilla.kernel.org/show_bug.cgi?id=191471 Bug ID: 191471 Summary: Mp2Sas and Mpt3Sas (now mpxsas) drivers are spinning forever in the IRQ handler under load condition Product: IO/Storage Version: 2.5 Kernel Version: 4.7

Re: JMS56x not working reliably with uas driver

On Tue, 2016-12-27 at 21:19 -0500, Alan Stern wrote: > On Tue, 27 Dec 2016, George Cherian wrote: > > True. I am afraid that there necessarily is a window for resetting a > > disconnected device. But the check you proposed is better. > > however, I'd like to encapsulate that together with a test

Re: [PATCH] scsi: mpt3sas: fix hang on ata passthru commands

On Wed, Dec 28, 2016 at 11:30:24PM -0500, Jason Baron wrote: > Add a new parameter to scsi_internal_device_block() to decide whether > or not to invoke scsi_wait_for_queuecommand(). We'll also need to deal with the blk-mq wait path that Bart has been working on (I think it's already in the scsi