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
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
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 insertions(+), 5 deletions(-)
diff --git a/drivers/scsi/qla
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, b
> > +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
> FCOE_TSTORM_FCOE_TASK_ST_CTX_READ_WRITE_RX_SGL_MODE_SHIF
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 other
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 value. Thus, scsi_wait_f
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 h
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
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 f
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 tr
11 matches
Mail list logo
