From: Ching Huang
replace constant ARCMSR_MAX_FREECCB_NUM by variable acb->maxFreeCCB that was
got from firmware
Signed-off-by: Ching Huang
---
diff -uprN a/drivers/scsi/arcmsr/arcmsr.h b/drivers/scsi/arcmsr/arcmsr.h
--- a/drivers/scsi/arcmsr/arcmsr.h 2017-08-04 11:19:22.0 +0800
From: Ching Huang
add codes for ACB_ADAPTER_TYPE_E to support new adapter ARC-1884
Signed-off-by: Ching Huang
---
diff -uprN a/drivers/scsi/arcmsr/arcmsr.h b/drivers/scsi/arcmsr/arcmsr.h
--- a/drivers/scsi/arcmsr/arcmsr.h 2017-08-03 18:54:46.0 +0800
+++ b/drivers/scsi/arcmsr/arcms
From: Ching Huang
simplify arcmsr_iop_init function
Signed-off-by: Ching Huang
---
diff -uprN a/drivers/scsi/arcmsr/arcmsr_hba.c b/drivers/scsi/arcmsr/arcmsr_hba.c
--- a/drivers/scsi/arcmsr/arcmsr_hba.c 2017-11-08 18:46:42.0 +0800
+++ b/drivers/scsi/arcmsr/arcmsr_hba.c 2017-11-08 18:
From: Ching Huang
Hi all,
The following patches apply to Martin's 4.15/scsi-queue.
Patch 1: redefine ACB_ADAPTER_TYPE_A, _B, _C, _D and subsequent changes.
Patch 2: simplify arcmsr_iop_init function.
Patch 3: add codes for ACB_ADAPTER_TYPE_E to support new adapter ARC-1884
Patch 4: replace c
From: Ching Huang
redefine ACB_ADAPTER_TYPE_A, _B, _C, _D and subsequent changes.
Signed-off-by: Ching Huang
---
diff -uprN a/drivers/scsi/arcmsr/arcmsr.h b/drivers/scsi/arcmsr/arcmsr.h
--- a/drivers/scsi/arcmsr/arcmsr.h 2017-07-31 11:50:44.0 +0800
+++ b/drivers/scsi/arcmsr/arcmsr
From: Ching Huang
Hi all,
The following patches apply to Martin's 4.15/scsi-queue.
Patch 1: redefine ACB_ADAPTER_TYPE_A, _B, _C, _D and subsequent changes.
Patch 2: simplify arcmsr_iop_init function.
Patch 3: add codes for ACB_ADAPTER_TYPE_E to support new adapter ARC-1884
Patch 4: replace c
Avoid directly referencing the next_rq and fifo_list arrays using the
helper functions deadline_next_request() and deadline_fifo_request() to
facilitate changes in the dispatch request selection in
__dd_dispatch_request() for zoned block devices.
Signed-off-by: Damien Le Moal
Reviewed-by: Bart Va
Avoid directly referencing the next_rq and fifo_list arrays using the
helper functions deadline_next_request() and deadline_fifo_request() to
facilitate changes in the dispatch request selection in
deadline_dispatch_requests() for zoned block devices.
While at it, also remove the unnecessary forwa
Initialize the seq_zones_bitmap, seq_zones_wlock and nr_zones fields of
the disk request queue on disk revalidate. As the seq_zones_bitmap
and seq_zones_wlock allocations are identical, introduce the helper
sd_zbc_alloc_zone_bitmap(). Using this helper, reallocate the bitmaps
whenever the disk capa
This series, formerly titled "scsi-mq support for ZBC disks", implements
support for ZBC disks for system using the scsi-mq I/O path.
The current scsi level support of ZBC disks guarantees write request ordering
using a per-zone write lock which prevents issuing simultaneously multiple
write comma
Introduce zone write locking to avoid write request reordering with
zoned block devices. This is achieved using a finer selection of the
next request to dispatch:
1) Any non-write request is always allowed to proceed.
2) Any write to a conventional zone is always allowed to proceed.
3) For a write
From: Christoph Hellwig
Components relying only on the request_queue structure for accessing
block devices (e.g. I/O schedulers) have a limited knowledged of the
device characteristics. In particular, the device capacity cannot be
easily discovered, which for a zoned block device also result in t
The block layer now handles zone write locking.
Signed-off-by: Damien Le Moal
Reviewed-by: Christoph Hellwig
Reviewed-by: Martin K. Petersen
---
drivers/scsi/sd.c| 41 +++-
drivers/scsi/sd.h| 11 ---
drivers/scsi/sd_zbc.c| 83
Introduce zone write locking to avoid write request reordering with
zoned block devices. This is achieved using a finer selection of the
next request to dispatch:
1) Any non-write request is always allowed to proceed.
2) Any write to a conventional zone is always allowed to proceed.
3) For a write
Bart,
is this something known to you, or it is just my fault applying this series to
v4.13? Except having this warning, suspend/resume works for me:
===
[ 27.383846] sd 0:0:0:0: [sda] Starting disk
[ 27.383976] sd 1:0:0:0: [sdb] Starting disk
[ 27.451218] sdb: Attempt to allocate non-preem
On Wed, 2017-11-08 at 01:37 -0800, Nicholas A. Bellinger wrote:
> On Sun, 2017-11-05 at 08:05 -0800, James Bottomley wrote:
> >
> > On Sat, 2017-11-04 at 18:14 -0700, Nicholas A. Bellinger wrote:
> > >
> > > Hi all,
> > >
> > > Just a friendly email after catching up on patches this week, the
>
Are there any issues with this patch
(https://patchwork.kernel.org/patch/9938919/) that Pavel Tikhomirov submitted
back in September? I am willing to help if there's anything I can do to help
get it accepted.
The failing case I'm working on involves lots of servers with disk read/write
activ
On Wed, Nov 08, 2017 at 10:57:23AM -0700, Jens Axboe wrote:
> On 11/08/2017 09:41 AM, Bart Van Assche wrote:
> > On Tue, 2017-11-07 at 20:06 -0700, Jens Axboe wrote:
> >> At this point, I have no idea what Bart's setup looks like. Bart, it
> >> would be REALLY helpful if you could tell us how you a
From: Anil Gurumurthy
Signed-off-by: Anil Gurumurthy
Signed-off-by: Giridhar Malavali
Signed-off-by: Darren Trapp
Signed-off-by: Himanshu Madhani
---
drivers/scsi/qla2xxx/qla_nvmet.c | 783 +++
drivers/scsi/qla2xxx/qla_nvmet.h | 130 +++
2 files change
From: Anil Gurumurthy
This patch Adds following code in the driver to
support FC-NVMe Target
- Updated ql2xenablenvme to allow FC-NVMe Target operation
- Added LS Request handling for NVMe Target
- Added passthr IOCB for LS4 request
- Added CTIO for sending response to FW
- Added FC4 Registratio
From: Anil Gurumurthy
Signed-off-by: Anil Gurumurthy
Signed-off-by: Giridhar Malavali
Signed-off-by: Himanshu Madhani
---
drivers/scsi/qla2xxx/Kconfig | 1 +
drivers/scsi/qla2xxx/Makefile | 3 ++-
2 files changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/scsi/qla2xxx/Kconfig b/dr
From: Anil Gurumurthy
Signed-off-by: Anil Gurumurthy
Signed-off-by: Giridhar Malavali
Signed-off-by: Darren Trapp
Signed-off-by: Himanshu Madhani
---
drivers/scsi/qla2xxx/qla_dbg.c | 1 +
drivers/scsi/qla2xxx/qla_dbg.h | 2 ++
drivers/scsi/qla2xxx/qla_iocb.c | 42
Hi Christoph/Sagi,
I've corrected the mailing list and maintainers for this series.
This series adds support for FC-NVMe Target.
Patch #1 addes new qla_nvmet files for FC-NVMe Target support.
Patch #2 adds Kconfig and Makefile changes to prepare code compile.
Patch #3 and #4 has bulk of change
On Wed, Nov 08, 2017 at 04:41:35PM +, Bart Van Assche wrote:
> On Tue, 2017-11-07 at 20:06 -0700, Jens Axboe wrote:
> > At this point, I have no idea what Bart's setup looks like. Bart, it
> > would be REALLY helpful if you could tell us how you are reproducing
> > your hang. I don't know why t
Please check whether an unlock is needed before the return on line 891.
julia
-- Forwarded message --
Date: Wed, 8 Nov 2017 15:05:33 +0800
From: kbuild test robot
To: kbu...@01.org
Cc: Julia Lawall
Subject: [target:for-next 17/33] drivers/target/target_core_user.c:891:2-8:
p
Martin,
On 11/9/17 08:41, Martin K. Petersen wrote:
>
> Damien,
>
>> wait for the disk capacity and number of zones to stabilize on the
>> second revalidation pass to allocate and initialize the bitmaps.
>
> Stabilize how?
If RC_BASIS is 0, the capacity changes after the first report zones...
Damien,
> Make sure that the device request queue zone information (number of
> zones and zone bitmaps) are reinitialized if the number of zones
> changes (e.g. on a drive capacity change on revalidate).
This should probably be part of patch 6.
Reviewed-by: Martin K. Petersen
--
Martin K. Pe
Damien,
> The block layer now handles zone write locking.
Looks OK.
Reviewed-by: Martin K. Petersen
--
Martin K. Petersen Oracle Linux Engineering
Damien,
> wait for the disk capacity and number of zones to stabilize on the
> second revalidation pass to allocate and initialize the bitmaps.
Stabilize how?
--
Martin K. Petersen Oracle Linux Engineering
Damien,
> Introduce zone write locking to avoid write request reordering with
> zoned block devices. This is achieved using a finer selection of the
> next request to dispatch:
> 1) Any non-write request is always allowed to proceed.
> 2) Any write to a conventional zone is always allowed to proc
Damien,
> Avoid directly referencing the next_rq and fifo_list arrays using the
> helper functions deadline_next_request() and deadline_fifo_request() to
> facilitate changes in the dispatch request selection in
> deadline_dispatch_requests() for zoned block devices.
>
> While at it, also remove
Damien,
> Introduce zone write locking to avoid write request reordering with
> zoned block devices. This is achieved using a finer selection of the
> next request to dispatch:
> 1) Any non-write request is always allowed to proceed.
> 2) Any write to a conventional zone is always allowed to proc
Damien,
> Avoid directly referencing the next_rq and fifo_list arrays using the
> helper functions deadline_next_request() and deadline_fifo_request()
> to facilitate changes in the dispatch request selection in
> __dd_dispatch_request() for zoned block devices.
Reviewed-by: Martin K. Petersen
Damien,
> + * Zoned block device information for request dispatch control.
> + * nr_zones is the total number of zones of the device. This is always
> + * 0 for regular block devices. seq_zones_bitmap is a bitmap of nr_zones
> + * bits which indicates if a zone is conventional
Kees,
>> Kees Cook (1):
>> zfcp: convert timers to use timer_setup()
>>
>> Steffen Maier (2):
>> zfcp: purely mechanical update using timer API, plus blank lines
>> zfcp: drop open coded assignments of timer_list.function
>
> These looks great, thanks!
These look good to me too.
Reviewed-
James,
> System crashed due to a hard lockup at lpfc_els_timeout_handler+0x128.
>
> The els ring's txcmplq list is corrupted: the last element in the list
> does not point back the the head causing a loop. Issue is the
> els processing path for sli4 hbas are using the hbalock instead of
> the rin
Dan,
> pr_info() has a KERN_INFO already so the second KERN_INFO isn't needed.
>
> Signed-off-by: Dan Carpenter
Applied to 4.15/scsi-queue.
--
Martin K. Petersen Oracle Linux Engineering
Dan,
> The indenting wasn't right, because the last two prints weren't
> indented far enough. Also it used pr_info() where it was supposed to
> use pr_cont(). I reversed the if statement and pulled the code in one
> tab and did a couple other minor cleanups.
Applied to 4.15/scsi-queue. Thank y
Arnd,
> aacraid passes the current time to the firmware in one of two ways,
> either as year/month/day/... or as 32-bit unsigned seconds.
>
> The first one is broken on 32-bit architectures as it cannot go past
> year 2038. Using timespec64 here makes it behave properly on both
> 32-bit and 64-bi
James,
> Add 64GBIT and 128GBIT port speed definitions.
>
> Upcoming hardware will reference these speeds.
Applied to 4.15/scsi-queue. Thanks!
--
Martin K. Petersen Oracle Linux Engineering
> On 11/08/2017 04:39 PM, Bryant G. Ly wrote:
>> On 7/30/17 5:19 PM, Nicholas A. Bellinger wrote:
>>
>>> On Thu, 2017-07-13 at 14:33 +0800, lixi...@cmss.chinamobile.com wrote:
From: Xiubo Li
Add some comments to make the scatter code to be more readable.
Signed-off-by: Xi
On 11/08/2017 04:39 PM, Bryant G. Ly wrote:
> On 7/30/17 5:19 PM, Nicholas A. Bellinger wrote:
>
>> On Thu, 2017-07-13 at 14:33 +0800, lixi...@cmss.chinamobile.com wrote:
>>> From: Xiubo Li
>>>
>>> Add some comments to make the scatter code to be more readable.
>>>
>>> Signed-off-by: Xiubo Li
>>
On 11/08/2017 04:35 PM, Bryant G. Ly wrote:
>
> On 7/30/17 5:10 PM, Nicholas A. Bellinger wrote:
>
>> Hi Xiubo,
>>
>> Apologies for the delayed response. Comments below.
>>
>> On Wed, 2017-07-12 at 15:16 +0800, lixi...@cmss.chinamobile.com wrote:
>>> From: Xiubo Li
>>>
>>> The fifo type waiter
On 8/6/17 6:27 PM, Nicholas A. Bellinger wrote:
> On Tue, 2017-08-01 at 23:09 +0300, Dan Carpenter wrote:
>> Calling list_del() on the iterator pointer in list_for_each_entry() will
>> cause an oops. We need to user the _safe() version for that.
>>
>> Fixes: c73d02f63c16 ("tcmu: Add fifo type wa
On 7/30/17 5:19 PM, Nicholas A. Bellinger wrote:
> On Thu, 2017-07-13 at 14:33 +0800, lixi...@cmss.chinamobile.com wrote:
>> From: Xiubo Li
>>
>> Add some comments to make the scatter code to be more readable.
>>
>> Signed-off-by: Xiubo Li
>> ---
>> drivers/target/target_core_user.c | 30 ++
On 7/30/17 5:10 PM, Nicholas A. Bellinger wrote:
> Hi Xiubo,
>
> Apologies for the delayed response. Comments below.
>
> On Wed, 2017-07-12 at 15:16 +0800, lixi...@cmss.chinamobile.com wrote:
>> From: Xiubo Li
>>
>> The fifo type waiter list will hold the udevs who are waiting for the
>> blocks
> From: Nicholas Bellinger
>
> This patch fixes a bug during QUEUE_FULL where transport_complete_qf()
> calls transport_complete_task_attr() after it's already been invoked
> by target_complete_ok_work() or transport_generic_request_failure()
> during initial completion, preceeding QUEUE_FULL.
>
> From: Nicholas Bellinger
>
> This patch fixes a potential end-less loop during QUEUE_FULL,
> where cmd->se_tfo->write_pending() callback fails repeatedly
> but __transport_wait_for_tasks() has already been invoked to
> quiese the outstanding se_cmd descriptor.
>
> To address this bug, this patc
On Wed, Nov 8, 2017 at 6:17 AM, Steffen Maier wrote:
> Hi all,
>
> here is a small series for the timer_setup() refactoring of zfcp.
> We target it for the merge window to land in v4.15-rc1.
>
> Unfortunately, they don't seem to apply to the current state of neither
> James' misc branch nor Martin
On 11/8/2017 1:05 AM, Hannes Reinecke wrote:
Isn't that a bit excessive?
Printing the same message _two_ times, and not providing additional info?
Please do only duplicate message if there is new information printed;
otherwise we might as well skip the second message.
Cheers,
Hannes
yep. will
On Tue, 2017-11-07 at 12:59 -0800, James Smart wrote:
> From: Dick Kennedy
>
> System crashed due to a hard lockup at lpfc_els_timeout_handler+0x128.
>
> The els ring's txcmplq list is corrupted: the last element in the list
> does not point back the the head causing a loop. Issue is the
> els p
On 11/08/2017 11:23 AM, Bart Van Assche wrote:
> Avoid that removal of a request queue sporadically triggers the
> following warning:
>
> list_del corruption. next->prev should be 8807d649b970, but was
> 6b6b6b6b6b6b6b6b
> WARNING: CPU: 3 PID: 342 at lib/list_debug.c:56
> __list_del_entry_va
On 11/08/2017 11:22 AM, Laurence Oberman wrote:
> On Wed, 2017-11-08 at 10:57 -0700, Jens Axboe wrote:
>> On 11/08/2017 09:41 AM, Bart Van Assche wrote:
>>> On Tue, 2017-11-07 at 20:06 -0700, Jens Axboe wrote:
At this point, I have no idea what Bart's setup looks like. Bart,
it
would
Looks good:
Reviewed-by: Christoph Hellwig
Looks good:
Reviewed-by: Christoph Hellwig
A bit of duplication vs the existing ZBC code here, but it seems the
old code is going away later in the series, so:
Reviewed-by: Christoph Hellwig
Avoid that removal of a request queue sporadically triggers the
following warning:
list_del corruption. next->prev should be 8807d649b970, but was
6b6b6b6b6b6b6b6b
WARNING: CPU: 3 PID: 342 at lib/list_debug.c:56 __list_del_entry_valid+0x92/0xa0
Call Trace:
process_one_work+0x11b/0x660
worke
On Wed, 2017-11-08 at 10:57 -0700, Jens Axboe wrote:
> On 11/08/2017 09:41 AM, Bart Van Assche wrote:
> > On Tue, 2017-11-07 at 20:06 -0700, Jens Axboe wrote:
> > > At this point, I have no idea what Bart's setup looks like. Bart,
> > > it
> > > would be REALLY helpful if you could tell us how you
Looks good,
Reviewed-by: Christoph Hellwig
Looks good,
Reviewed-by: Christoph Hellwig
Looks good:
Reviewed-by: Christoph Hellwig
On 11/08/2017 08:59 AM, Ming Lei wrote:
> On Wed, Nov 08, 2017 at 02:20:41PM +0800, Ming Lei wrote:
>> On Tue, Nov 07, 2017 at 08:17:59PM -0700, Jens Axboe wrote:
>>> On 11/07/2017 08:12 PM, Ming Lei wrote:
On Tue, Nov 07, 2017 at 08:01:48PM -0700, Jens Axboe wrote:
> On 11/07/2017 06:03 P
Except for a bit of mis-spelling in the Subject this looks fine
to me:
Reviewed-by: Christoph Hellwig
FYI, I would just simplify the subject to
mq-deadline: Introduce dispatch helpers
and similar in the other patches.
In preparation to enabling -Wimplicit-fallthrough, mark switch cases
where we are expecting to fall through.
Addresses-Coverity-ID: 114988
Addresses-Coverity-ID: 114989
Addresses-Coverity-ID: 114990
Addresses-Coverity-ID: 114991
Signed-off-by: Gustavo A. R. Silva
---
drivers/scsi/ppa.c | 4
On 11/08/2017 09:41 AM, Bart Van Assche wrote:
> On Tue, 2017-11-07 at 20:06 -0700, Jens Axboe wrote:
>> At this point, I have no idea what Bart's setup looks like. Bart, it
>> would be REALLY helpful if you could tell us how you are reproducing
>> your hang. I don't know why this has to be dragged
Hi James,
> On Nov 7, 2017, at 9:05 AM, James Smart wrote:
>
> On 11/6/2017 11:55 AM, Himanshu Madhani wrote:
>> From: Anil Gurumurthy
>>
>> +static struct nvmet_fc_target_template qla_nvmet_fc_transport = {
>> +.targetport_delete = qla_nvmet_targetport_delete,
>> +.xmt_ls_rsp
On Tue, 2017-11-07 at 20:06 -0700, Jens Axboe wrote:
> At this point, I have no idea what Bart's setup looks like. Bart, it
> would be REALLY helpful if you could tell us how you are reproducing
> your hang. I don't know why this has to be dragged out.
Hello Jens,
It is a disappointment to me tha
On Wed, 2017-11-08 at 09:12 +0100, Hannes Reinecke wrote:
> You know, this actually looks like the same issue I'm chasing with iser;
> we have a customer who regularly sees lockups during scanning.
> As it turns out, iser is calling scsi_device_del() from the RX thread.
> Which in turn needs to cal
On Wed, Nov 08, 2017 at 08:01:08AM -0800, James Bottomley wrote:
> On Wed, 2017-11-08 at 21:21 +0800, Ming Lei wrote:
> > cmd->cmnd can be allocated/freed dynamically in case of
> > T10_PI_TYPE2_PROTECTION,
> > so we should check it in scsi_show_rq() because this request may have
> > been freed in
> -Original Message-
> From: Sumit Saxena [mailto:sumit.sax...@broadcom.com]
> Sent: Wednesday, November 1, 2017 12:18 AM
> To: Kees Cook; Martin K. Petersen
> Cc: Kashyap Desai; Shivasharan Srikanteshwara; James E.J. Bottomley;
> PDL,MEGARAIDLINUX; linux-scsi@vger.kernel.org; linux-
> ker.
Thanks.
Acked-by: Sathya Prakash Veerichetty
-Original Message-
From: Dan Carpenter [mailto:dan.carpen...@oracle.com]
Sent: Wednesday, November 8, 2017 1:38 AM
To: Sathya Prakash; Suganath Prabu Subramani
Cc: Chaitra P B; James E.J. Bottomley; Martin K. Petersen;
mpt-fusionlinux@broad
Thanks.
Acked-by: Sathya Prakash Veerichetty
-Original Message-
From: Dan Carpenter [mailto:dan.carpen...@oracle.com]
Sent: Wednesday, November 8, 2017 1:38 AM
To: Sathya Prakash; Suganath Prabu Subramani
Cc: Chaitra P B; James E.J. Bottomley; Martin K. Petersen;
mpt-fusionlinux@broa
On Wed, 2017-11-08 at 21:21 +0800, Ming Lei wrote:
> cmd->cmnd can be allocated/freed dynamically in case of
> T10_PI_TYPE2_PROTECTION,
> so we should check it in scsi_show_rq() because this request may have
> been freed in scsi_show_rq().
>
> This patch fixs the following kernel crash when dumpin
On Wed, Nov 08, 2017 at 02:20:41PM +0800, Ming Lei wrote:
> On Tue, Nov 07, 2017 at 08:17:59PM -0700, Jens Axboe wrote:
> > On 11/07/2017 08:12 PM, Ming Lei wrote:
> > > On Tue, Nov 07, 2017 at 08:01:48PM -0700, Jens Axboe wrote:
> > >> On 11/07/2017 06:03 PM, Ming Lei wrote:
> > >>> On Tue, Nov 07
Hi all,
here is a small series for the timer_setup() refactoring of zfcp.
We target it for the merge window to land in v4.15-rc1.
Unfortunately, they don't seem to apply to the current state of neither
James' misc branch nor Martin's 4.15/scsi-queue branch,
because they depend on:
v4.14-rc3 686fe
From: Kees Cook
In preparation for unconditionally passing the struct timer_list pointer to
all timer callbacks, switch to using the new timer_setup() and from_timer()
to pass the timer pointer explicitly.
Cc: Steffen Maier
Cc: Benjamin Block
Cc: Martin Schwidefsky
Cc: Heiko Carstens
Cc: lin
erp_memwait only occurs in seldom memory pressure situations.
The typical case never uses the associated timer and thus also
does not need to initialize the timer.
Also, we don't want to re-initialize the timer each time we re-use an
erp_action in zfcp_erp_setup_act() [see also v4.14-rc7 commit ab3
The majority of requests is regular SCSI I/O on the hot path.
Since these use a timeout owned by the block layer, zfcp does not use
zfcp_fsf_req.timer. Hence, the very early unconditional and even
incomplete (handler function yet unknown) timer initialization in
zfcp_fsf_req_create() is not necessa
cmd->cmnd can be allocated/freed dynamically in case of T10_PI_TYPE2_PROTECTION,
so we should check it in scsi_show_rq() because this request may have
been freed in scsi_show_rq().
This patch fixs the following kernel crash when dumping request via block's
debugfs interface:
[ 252.962045] BUG: u
On Wed, 2017-11-08 at 11:43 +0300, Dan Carpenter wrote:
> "udev->nl_reply_supported" is an int but on 64 bit arches we are writing
> 8 bytes of data to it so it corrupts four bytes beyond the end of the
> struct.
>
> Fixes: b849b4567549 ("target: Add netlink command reply supported option for
> e
On Wed, 2017-11-08 at 11:44 +0300, Dan Carpenter wrote:
> We added a new error path here but we forgot to drop the lock first
> before returning.
>
> Fixes: 0d44374c1aae ("tcmu: fix double se_cmd completion")
> Signed-off-by: Dan Carpenter
Applied to target-pending/for-next.
Thanks DanC !
Hello,
after upgrading some servers from 4.9 to a kernel > 4.11 i saw a
regression where i cannot boot into the os.
The kernel is crashing in the isci (NOT iscsi) driver in task abort.
Message:
Unable to handle kernel NULL pointer dereference at isci_task_abort_task
git bisect detected the foll
On 11/03/2017 11:56 PM, James Smart wrote:
> The current default for async hw receive queues is 1, which presents
> issues under heavy load as number of queues influence the available
> async receive buffer limits.
>
> Raise the default to the either the current hw limit (16) or the number
> of hw
On Sun, 2017-11-05 at 08:05 -0800, James Bottomley wrote:
> On Sat, 2017-11-04 at 18:14 -0700, Nicholas A. Bellinger wrote:
> > Hi all,
> >
> > Just a friendly email after catching up on patches this week, the
> > majority of those outstanding on the list have been merged into
> > target-pending/f
On 11/03/2017 11:56 PM, James Smart wrote:
> Display for lpfc/fnX/iDiag/queInfo isn't formatted perfectly.
> Corrected the format strings for the queue info debug messages.
>
> Signed-off-by: Dick Kennedy
> Signed-off-by: James Smart
> ---
> drivers/scsi/lpfc/lpfc_debugfs.c | 14 +++---
On 11/03/2017 11:56 PM, James Smart wrote:
> The driver does not respond to PLOGI from the direct attach target.
> The driver uses incorrect S_ID in CONFIG_LINK, after FLOGI completion
>
> Correct by issuing CONFIG_LINK with the correct S_ID after receiving
> the PLOGI from the target
>
> Signed-
On 11/03/2017 11:56 PM, James Smart wrote:
> Raise the maximum NVME sg list size allowed to 256 elements.
>
> Signed-off-by: Dick Kennedy
> Signed-off-by: James Smart
> ---
> drivers/scsi/lpfc/lpfc.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/scsi/lpfc/lpf
On 11/03/2017 11:56 PM, James Smart wrote:
> performing an LS abort results in the following message being seen:
> 0603 Invalid CQ subtype 6: 0300 2202 0016 d005
> and the associated exchange is not properly freed.
>
> The code did not recognize the exchange type that was aborted
On 11/03/2017 11:56 PM, James Smart wrote:
> In test cases where an instance of the driver is detached and
> reattached, the driver will crash on reattachment. There is a
> compound if statement that will skip over the bar setup if
> the pci_resource_start call is not successful. The driver
> erron
On 11/03/2017 11:56 PM, James Smart wrote:
> XRI_ABORTED_CQE completions were not being handled in the fast path.
> They were being queued and deferred to the lpfc worker thread
> for processing. This is an artifact of the driver design prior
> to moving queue processing out of the isr and into a w
On 11/03/2017 11:56 PM, James Smart wrote:
> Hardware queues are a fast staging area to push commands into the adapter.
> The adapter should drain them extremely quickly. However, under heavy
> io load, the host cpu is pushing commands faster than the drain rate of
> the adapter causing the driver
On 11/03/2017 11:56 PM, James Smart wrote:
> When the HBA is connected to a private loop, the driver
> reports FLOGI loop-open failure as functional error. This is
> an expected condition.
>
> Mark loop-open failure as a warning instead of error.
>
> Signed-off-by: Dick Kennedy
> Signed-off-by:
We added a new error path here but we forgot to drop the lock first
before returning.
Fixes: 0d44374c1aae ("tcmu: fix double se_cmd completion")
Signed-off-by: Dan Carpenter
diff --git a/drivers/target/target_core_user.c
b/drivers/target/target_core_user.c
index 07f2d95f7ae7..cc2468a299d3 10064
"udev->nl_reply_supported" is an int but on 64 bit arches we are writing
8 bytes of data to it so it corrupts four bytes beyond the end of the
struct.
Fixes: b849b4567549 ("target: Add netlink command reply supported option for
each device")
Signed-off-by: Dan Carpenter
diff --git a/drivers/tar
pr_info() has a KERN_INFO already so the second KERN_INFO isn't needed.
Signed-off-by: Dan Carpenter
diff --git a/drivers/scsi/mpt3sas/mpt3sas_scsih.c
b/drivers/scsi/mpt3sas/mpt3sas_scsih.c
index 3a9438a1704e..b258f210120a 100644
--- a/drivers/scsi/mpt3sas/mpt3sas_scsih.c
+++ b/drivers/scsi/mpt
The indenting wasn't right, because the last two prints weren't
indented far enough. Also it used pr_info() where it was supposed to
use pr_cont(). I reversed the if statement and pulled the code in one
tab and did a couple other minor cleanups.
Fixes: 4318c7347847 ("scsi: mpt3sas: Handle NVMe P
On 11/07/2017 11:57 PM, James Bottomley wrote:
> On Tue, 2017-11-07 at 22:42 +, Bart Van Assche wrote:
>> On Tue, 2017-11-07 at 10:09 -0800, James Bottomley wrote:
>>>
>>> but can you investigate the root cause rather than trying this
>>> bandaid?
>>
>> Hello James,
>>
>> Thanks for your reply.
Introduce zone write locking to avoid write request reordering with
zoned block devices. This is achieved using a finer selection of the
next request to dispatch:
1) Any non-write request is always allowed to proceed.
2) Any write to a conventional zone is always allowed to proceed.
3) For a write
Make sure that the device request queue zone information (number of
zones and zone bitmaps) are reinitialized if the number of zones
changes (e.g. on a drive capacity change on revalidate).
Signed-off-by: Damien Le Moal
---
drivers/scsi/sd_zbc.c | 36 ++--
1 file
From: Christoph Hellwig
Components relying only on the request_queue structure for accessing
block devices (e.g. I/O schedulers) have a limited knowledged of the
device characteristics. In particular, the device capacity cannot be
easily discovered, which for a zoned block device also result in t
1 - 100 of 107 matches
Mail list logo