rmance
>>> issues.
>>
>> It would be an interesting topic to discuss, as it is a shame that
>> blk-iopoll isn't used more widely.
>>
>> --
>> Jens Axboe
>>
>
> I'd also be interested in this topic. Given that iopoll only really ma
atch 1
> more widely.
Added for this series, thanks.
--
Jens Axboe
--
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
can see where the printks are coming from. If we get a
BUSY with nothing pending, the driver should be ensuring that the queue
gets run again later through blk_mq_delay_queue(), for instance.
When the device is stuck, does it restart if you send it IO?
--
Jens Axboe
--
To unsubscribe from this
On 01/19/2017 06:24 AM, Hannes Reinecke wrote:
> On 01/19/2017 03:09 PM, Jens Axboe wrote:
>> On 01/19/2017 04:27 AM, Hannes Reinecke wrote:
>>> Hi Jens,
>>>
>>> upon further testing with your blk-mq-sched branch I hit a queue stall
>>> during requein
at one
as-is for now, but add the stop to the delay. If the above stop-all is
indeed buggy, then it can later just be removed.
--
Jens Axboe
--
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
> They are _always_ 4, irrespective of the hardware and/or tests which I
> run. Jens, what are these numbers supposed to mean?
> Is this intended?
It's bucketized. 0=0.0% means that 0% of the submissions didn't submit
anything (unsurprisingly), and ditto for the complete side.
ithout the patch there is a lot of wrong stuff like
> complains about a kobject initialized again. This leads to a double free
> at some point.
And what patch are we talking about? I don't mind being CC'ed into a thread,
but some context and background would be immensely helpful here...
--
Jens Axboe
--
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
9:
[ 18.248027] R10: 0009 R11: 0246 R12: 555737e82b30
[ 18.248028] R13: 555737e71200 R14: 555737e82b30 R15:
[ 18.248030] ---[ end trace b0ae5eae3430d5d6 ]---
and it's even more downhill from there. That option is marked unstable
On 01/20/2017 09:09 AM, Sebastian Andrzej Siewior wrote:
> On 2017-01-20 08:32:37 [-0800], Jens Axboe wrote:
>> That's alright, sounds like it's not a -next regression, but rather something
>> that is already broken. I can reproduce a lot of breakage if I enable
>>
to use the same clone and map method as the blk-mq version.
I'd like to get this in sooner rather than later, so I'll spend some
time reviewing and testing it start this week. I'm assuming you are
targeting 4.11 with this change, right?
--
Jens Axboe
--
To unsubscribe from this
d idea to keep the helper but just make it take the opf and fix
up the other locations too. The fact that PREFLUSH|FUA is the magic to
check for is somewhat tribal knowledge.
--
Jens Axboe
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to m
ould you mind reverting it? I'd
> prefer to avoid rebasing my fixes branch.
>
> Acked-by: Martin K. Petersen
Yep, I have added it, thanks.
--
Jens Axboe
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...
REQ_FUA);
struct blk_plug *plug;
unsigned int request_count = 0;
- struct blk_mq_alloc_data data;
+ struct blk_mq_alloc_data data = { 0, };
struct request *rq;
blk_qc_t cookie;
unsigned int wb_acct;
--
Jens Axboe
--
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
On 01/26/2017 11:52 AM, Bart Van Assche wrote:
> On Thu, 2017-01-26 at 11:44 -0700, Jens Axboe wrote:
>> I think this may be my bug - does the below help?
>
> Hello Jens,
>
> What tree has that patch been generated against? It does not apply
> cleanly on top of Chri
ations.
>
> Jens, any opinion on just removing the printout of the SCSI CDB
> for blktrace?
Kill it with fire, I don't think there's much value to having it
there to begin with.
--
Jens Axboe
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
On 01/26/2017 11:59 AM, h...@lst.de wrote:
> On Thu, Jan 26, 2017 at 11:57:36AM -0700, Jens Axboe wrote:
>> It's against my for-4.11/block, which you were running under Christoph's
>> patches. Maybe he's using an older version? In any case, should be
>> pretty
On 01/26/2017 01:47 PM, Bart Van Assche wrote:
> On 01/26/2017 11:01 AM, Jens Axboe wrote:
>> On 01/26/2017 11:59 AM, h...@lst.de wrote:
>>> On Thu, Jan 26, 2017 at 11:57:36AM -0700, Jens Axboe wrote:
>>>> It's against my for-4.11/block, which you were running un
On 01/26/2017 02:01 PM, Bart Van Assche wrote:
> On Thu, 2017-01-26 at 13:54 -0700, Jens Axboe wrote:
>> Your call path has blk_get_request() in it, I don't have
>> that in my tree. Is it passing in the right mask?
>
> Hello Jens,
>
> There is only one blk_get
rq = __blk_mq_alloc_request(data, op);
} else {
rq = __blk_mq_alloc_request(data, op);
- data->hctx->tags->rqs[rq->tag] = rq;
+ if (rq)
+ data->hctx->tags->rqs[rq->tag] = rq;
}
if (rq)
On 01/26/2017 04:14 PM, Bart Van Assche wrote:
> On Thu, 2017-01-26 at 14:51 -0700, Jens Axboe wrote:
>> That is exactly what it means, looks like that one path doesn't handle
>> that. You'd have to exhaust the pool with atomic allocs for this to
>> trigger, we don
On 01/26/2017 04:47 PM, Bart Van Assche wrote:
> On Thu, 2017-01-26 at 16:26 -0700, Jens Axboe wrote:
>> What device is stuck? Is it running with an mq scheduler attached, or
>> with "none"?
>>
>> Would also be great to see the output of /sys/block/*/mq/*/ta
On 01/26/2017 04:50 PM, Jens Axboe wrote:
> On 01/26/2017 04:47 PM, Bart Van Assche wrote:
>> On Thu, 2017-01-26 at 16:26 -0700, Jens Axboe wrote:
>>> What device is stuck? Is it running with an mq scheduler attached, or
>>> with "none"?
>>>
>>&
On 01/26/2017 05:38 PM, Bart Van Assche wrote:
> On Thu, 2017-01-26 at 16:50 -0700, Jens Axboe wrote:
>> Clearly we are missing some requests. How do I setup dm similarly to
>> you?
>>
>> Does it reproduce without Christoph's patchset?
>
> Hello Jens,
>
On 01/26/2017 06:15 PM, Bart Van Assche wrote:
> On Thu, 2017-01-26 at 17:41 -0700, Jens Axboe wrote:
>> On 01/26/2017 05:38 PM, Bart Van Assche wrote:
>>> I see similar behavior with the blk-mq-sched branch of
>>> git://git.kernel.dk/linux-block.git (git commit ID
On 01/26/2017 06:22 PM, Jens Axboe wrote:
> On 01/26/2017 06:15 PM, Bart Van Assche wrote:
>> On Thu, 2017-01-26 at 17:41 -0700, Jens Axboe wrote:
>>> On 01/26/2017 05:38 PM, Bart Van Assche wrote:
>>>> I see similar behavior with the blk-mq-sched branch of
>>&g
On 01/26/2017 11:40 PM, Jens Axboe wrote:
> On 01/26/2017 06:22 PM, Jens Axboe wrote:
>> On 01/26/2017 06:15 PM, Bart Van Assche wrote:
>>> On Thu, 2017-01-26 at 17:41 -0700, Jens Axboe wrote:
>>>> On 01/26/2017 05:38 PM, Bart Van Assche wrote:
>>>>>
nal small cleanup in dm-rq
I've queued this up for 4.11. Since some of the patches had dependencies
on changes in master since for-4.11/block was forked, they are sitting
in a separate branch that has both for-4.11/block and v4.10-rc5 pulled
in first. for-next has everything, as usual.
--
On 01/27/2017 09:23 AM, Christoph Hellwig wrote:
> On Fri, Jan 27, 2017 at 09:21:46AM -0700, Jens Axboe wrote:
>> On 01/27/2017 09:17 AM, Christoph Hellwig wrote:
>>> On Fri, Jan 27, 2017 at 09:11:14AM -0700, Jens Axboe wrote:
>>>> I've queued this up for
On 01/27/2017 09:17 AM, Christoph Hellwig wrote:
> On Fri, Jan 27, 2017 at 09:11:14AM -0700, Jens Axboe wrote:
>> I've queued this up for 4.11. Since some of the patches had dependencies
>> on changes in master since for-4.11/block was forked, they are sitting
>> in a sep
On 01/27/2017 09:52 AM, Bart Van Assche wrote:
> On Fri, 2017-01-27 at 01:04 -0700, Jens Axboe wrote:
>> The previous patch had a bug if you didn't use a scheduler, here's a
>> version that should work fine in both cases. I've also updated the
>> above mention
Hello Christoph and Martin,
>
> How about using the function names alloc_full_request() / free_full_request()
> together with a comment that mentions that cmd_size is set by the LLD?
Since we use pdu in other places, how about alloc_request_pdu() or
alloc_request_with_pdu()?
And since it's all
On 01/27/2017 09:34 AM, Christoph Hellwig wrote:
> On Fri, Jan 27, 2017 at 09:27:02AM -0700, Jens Axboe wrote:
>> Feel free to repost it, I have no problem rebasing that branch as it's
>> standalone for now.
>
> Ok, I'll repost what I have right now, which is on top
On 01/27/2017 10:30 AM, Bart Van Assche wrote:
> On Fri, 2017-01-27 at 10:26 -0700, Jens Axboe wrote:
>> On 01/27/2017 10:21 AM, Bart Van Assche wrote:
>>> On Fri, 2017-01-27 at 17:12 +0100, Christoph Hellwig wrote:
>>>> On Wed, Jan 25, 2017 at 10:15:55PM -
On 01/27/2017 09:42 AM, Christoph Hellwig wrote:
> On Fri, Jan 27, 2017 at 09:38:40AM -0700, Jens Axboe wrote:
>>> Ok, I'll repost what I have right now, which is on top of a merge
>>> of your block/for-4.11/next and your for-next from this morning
>>> my time.
&
}
>
> The SCSI core does not allow to sleep inside the queuecommand() callback
> function.
udelay() is a busy loop, so it's not sleeping. That said, it's obviously
NOT a great idea. We want to fix the reordering due to requeues, not
introduce random busy delays to work around it.
On 01/30/2017 11:28 AM, Kashyap Desai wrote:
>> -Original Message-
>> From: Jens Axboe [mailto:ax...@kernel.dk]
>> Sent: Monday, January 30, 2017 10:03 PM
>> To: Bart Van Assche; osan...@osandov.com; kashyap.de...@broadcom.com
>> Cc: linux-scsi@vger.kernel.org
> On Jan 30, 2017, at 5:12 PM, Bart Van Assche
> wrote:
>
>> On Fri, 2017-01-27 at 09:56 -0700, Jens Axboe wrote:
>>> On 01/27/2017 09:52 AM, Bart Van Assche wrote:
>>> [ 215.724452] general protection fault: [#1] SMP
>>> [ 215.725060] Call Tra
On 01/30/2017 05:38 PM, Jens Axboe wrote:
>
>
>> On Jan 30, 2017, at 5:12 PM, Bart Van Assche
>> wrote:
>>
>>> On Fri, 2017-01-27 at 09:56 -0700, Jens Axboe wrote:
>>>> On 01/27/2017 09:52 AM, Bart Van Assche wrote:
>>>> [ 215.724452] g
ing through
libata that would need to be added, before we can git rm drivers/ide/ ?
--
Jens Axboe
--
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
make life easier I also have a git
> tree available here:
>
> git://git.infradead.org/users/hch/block.git cmd_type
>
>
> http://git.infradead.org/users/hch/block.git/shortlog/refs/heads/cmd_type
Looks good to me, applied for 4.11.
--
Jens Axboe
--
To unsubscribe
sed to you? ;-)
> I'd gladly wrote one, getting tired of my current OSS work... :-)
Pretty sure I told Jeff originally that libata should only go into the
kernel, if there was a plan to make it independent of SCSI. A promise
was made that of course it would, but that promise was never he
On 01/31/2017 01:55 PM, Bart Van Assche wrote:
> On Tue, 2017-01-31 at 13:34 -0800, Bart Van Assche wrote:
>> On Mon, 2017-01-30 at 17:38 -0800, Jens Axboe wrote:
>>> That's a known bug in mainline. Pull it into 4.10-rc6,
>>> or use my for-next where everything is a
and unregister the bdi, blk_cleanup_queue().
>
> Thanks to Omar for the quick reproducer script [2]. This patch survives
> where an unmodified kernel fails in a few seconds.
What is the patch against? Doesn't seem to apply cleanly for me on
master, nor the 4.11 block tree.
--
Jens Axboe
On 02/01/2017 02:40 PM, Dan Williams wrote:
> On Wed, Feb 1, 2017 at 2:35 PM, Jens Axboe wrote:
>> On 02/01/2017 02:05 PM, Dan Williams wrote:
>>> Warnings of the following form occur because scsi reuses a devt number
>>> while the block layer still has it referenced as
On 02/01/2017 03:43 PM, Jens Axboe wrote:
> On 02/01/2017 02:40 PM, Dan Williams wrote:
>> On Wed, Feb 1, 2017 at 2:35 PM, Jens Axboe wrote:
>>> On 02/01/2017 02:05 PM, Dan Williams wrote:
>>>> Warnings of the following form occur because scsi reuses a devt number
&g
riant of blkdev_issue_zeroout"). Before the commit, blkdev_issue_zeroout
> fell back to normal zero writing when WRITE SAME failed and it seems
> sd driver's heuristics depends on that behaviour.
CC Christoph and Chaitanya.
--
Jens Axboe
On 02/03/2017 09:12 AM, Christoph Hellwig wrote:
> On Fri, Feb 03, 2017 at 08:21:31AM -0700, Jens Axboe wrote:
>>> Error 121 (EREMOTEIO) was returned from blkdev_issue_zeroout().
>>> That came from sd driver because WRITE SAME was sent to the device
>>> which didn
On 02/03/2017 03:45 PM, Martin K. Petersen wrote:
>>>>>> "Jens" == Jens Axboe writes:
>
>>> I think we should fix sd.c to only send WRITE SAME if either of the
>>> variants are explicitly listed as supported through REPORT SUPPORTED
>>>
he: enabled, read cache: enabled,
> supports DPO and FUA
> [6.647077] kobject (d5078ca4): tried to init an initialized object,
> something is seriously wrong.
So sda is probed twice, and hilarity ensues when we try to register it
twice. I can't reproduce this, using scsi_debug and with scsi_async
enabled.
This is running linux-next? What's your .config?
--
Jens Axboe
sets the only user of cdrom_dummy_generic_packet explicitly so the
> variables can all be const.
Agree, it's a good change. Applied for 4.11.
--
Jens Axboe
here is
it merged? Don't send code like this without the necessary
infrastructure being in mainline.
--
Jens Axboe
On 02/20/2017 08:41 AM, James Bottomley wrote:
> On Mon, 2017-02-20 at 08:15 -0700, Jens Axboe wrote:
>> On 02/20/2017 04:16 AM, Elena Reshetova wrote:
>>> Now when new refcount_t type and API are finally merged
>>> (see include/linux/refcount.h), the following
7e6 ("scsi: allocate scsi_cmnd structures as part of struct
> request")
> Signed-off-by: Christoph Hellwig
> Reported-by: Dexuan Cui
> Tested-by: Dexuan Cui
> ---
>
> Changes since V1:
> - use a single memset as suggested by Bart
That's much better. I'll
> clean up opening brace position. Remove unnecessary cast on kmalloc().
>
> Tobin C. Harding (3):
> cciss: Fix checkpatch TRAILING_WHITESPACE
> cciss: Fix checkpatch OPEN_BRACE
> cciss: Remove kmalloc cast
Applied, thanks.
--
Jens Axboe
er functionality to allocate additional driver
>> specific data behind struct request instead of implementing it in SCSI
>> itѕelf.
>>
>> Signed-off-by: Christoph Hellwig
>> Acked-by: Martin K. Petersen
>> Reviewed-by: Hannes Reinecke
h scsi_mod.use_blk_mq=true. In a previous email, I asked if turning
on MQ makes a difference.
--
Jens Axboe
On 02/28/2017 10:16 AM, Stephen Hemminger wrote:
> On Tue, 28 Feb 2017 09:06:13 -0800
> James Bottomley wrote:
>
>> On Tue, 2017-02-28 at 08:32 -0700, Jens Axboe wrote:
>>> On 02/28/2017 07:08 AM, Christoph Hellwig wrote:
>>>> On Mon, Feb 27, 2017 at 05:19
ssage should explain WHY the change is made, not detail the code
implementation of it.
--
Jens Axboe
--
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
On 10/13/2016 02:19 PM, Dan Williams wrote:
On Thu, Oct 13, 2016 at 1:09 PM, Jens Axboe wrote:
On 10/13/2016 02:06 PM, Dan Williams wrote:
On Thu, Oct 13, 2016 at 12:53 PM, Adam Manzanares
wrote:
Patch adds an association between iocontext ioprio and the ioprio of a
request. This value is
On 10/13/2016 02:59 PM, Dan Williams wrote:
On Thu, Oct 13, 2016 at 1:24 PM, Jens Axboe wrote:
On 10/13/2016 02:19 PM, Dan Williams wrote:
On Thu, Oct 13, 2016 at 1:09 PM, Jens Axboe wrote:
On 10/13/2016 02:06 PM, Dan Williams wrote:
On Thu, Oct 13, 2016 at 12:53 PM, Adam Manzanares
Looks like 6/7 should go through the SCSI tree, but I
can queue up the rest.
--
Jens Axboe
--
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
On 10/18/2016 06:46 PM, Martin K. Petersen wrote:
"Jens" == Jens Axboe writes:
Jens> This is starting to look mergeable to me.
Yup.
Jens> Any objections in getting this applied for 4.10? Looks like 6/7
Jens> should go through the SCSI tree, but I can queue up the rest.
On 10/18/2016 07:53 PM, Martin K. Petersen wrote:
"Jens" == Jens Axboe writes:
Jens> I already queued up the other bits, if it's fine with you I'll add
Jens> 6/7 as well.
Sure. Feel free to add by Acked-by:.
Thanks, added and committed the sd bit. I'll
rough
libata/for-4.10, or this can be applied to block and libata tree can
pull from it.
I'm fine with that, add my Reviewed-by and funnel it through the libata
tree.
--
Jens Axboe
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of
rough the Red Hat SRP and NVMe test suites.
This looks pretty good, I'll run some testing on it tomorrow and do a
full review, hopefully we can get it applied sooner rather than later
for the next series.
--
Jens Axboe
--
To unsubscribe from this list: send the line "unsubscribe lin
the first request
* immediately, even if we have more pending.
*/
--
Jens Axboe
--
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
Christoph> or use the default.
>
> Jens, any objection to me funneling this change through the SCSI tree?
No, that's fine, you can add my reviewed-by.
--
Jens Axboe
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to ma
hrough the block tree, but they can go through the SCSI
tree as well. Let me know what folks think.
--
Jens Axboe
--
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
:0:0:0: Attached scsi generic sg1 type 5
--
Jens Axboe
--
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
On 11/08/2016 05:20 PM, Kashyap Desai wrote:
-Original Message-
From: Martin K. Petersen [mailto:martin.peter...@oracle.com]
Sent: Wednesday, November 09, 2016 4:45 AM
To: Jens Axboe
Cc: linux-scsi; Kashyap Desai; Martin K. Petersen
Subject: Re: [REGRESSION] 4.9-rc4+ doesn't boot
was exposing lot of non-existing SCSI devices(all SCSI
commands to channels-1,2,3 was
returned as SUCCESS-DID_OK by driver).
Fixes: 1e793f6fc0db920400574211c48f9157a37e3945
Reported-by: Jens Axboe
CC: sta...@vger.kernel.org
Signed-off-by: Kashyap Desai
Signed-off-by: Sumit Saxena
Tested-by
ay morning November 3 at 10
AM such that you can publish these?
I don't think it's related to this thread, but yes, that would be great.
--
Jens Axboe
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.or
I/O scheduler is critical, even for the scsi-mq case.
Each of these sections is a single job. For some reason we are not
merging as well as we should, that's the reason for the performance
loss. In fact, we're not merging at all. That's not IO scheduling.
--
Jens Axboe
--
To unsubs
to the hardware DOES matter, it's the
whole point of multiple submission queues. Trying to make up some
imaginary 1:1 mapping between submission and completion queues is
nonsensical, when it doesn't exist.
We still should benefit from scsi-mq, though.
Sure, but with 1 submission queue.
E16 commands anyway, make sure that use_16_for_rw is set.
Added to the 4.10 branch, thanks.
--
Jens Axboe
--
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
intrusive.
I think we should clean it up. But you should split this patch in two -
one for NVMe, and one for SCSI.
And it should be against for-4.10/block, the nvme parts don't apply
without fuzz.
--
Jens Axboe
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi"
On 11/15/2016 12:11 PM, Omar Sandoval wrote:
From: Omar Sandoval
Let's not depend on any of the BLK_MQ_RQ_QUEUE_* constants having
specific values. No functional change.
Thanks Omar, applied both for 4.10.
--
Jens Axboe
--
To unsubscribe from this list: send the line "unsubsc
ose.
I've added the series, except 6-8, the dm parts. I updated some of the
descriptions/subjects to read a little better.
--
Jens Axboe
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More major
is for me ;-)"
>
> Now the last time this caused a bit of a stir, but still no actual users,
> not even for SG_IO passthrough commands. So here we go again, this time
> including removing everything in the scsi and block layer supporting it,
> and thus shrinking struct request.
I&#
aker (Filesystems)
Josef Bacik (Filesystems)
Martin K. Petersen (Storage)
Jens Axboe (Storage)
Michal Hocko (MM)
Rik van Riel (MM)
Johannes Weiner (MM)
Alexei Starovoitov (BPF)
--
Jens Axboe
On 2/11/19 7:13 PM, James Bottomley wrote:
> On Mon, 2019-02-11 at 09:31 -0700, Jens Axboe wrote:
>> On 2/11/19 9:28 AM, James Bottomley wrote:
>>> On Mon, 2019-02-11 at 08:46 -0700, Jens Axboe wrote:
>>>> On 2/11/19 8:42 AM, James Bottomley wrote:
>>>>
On 2/12/19 8:24 AM, James Bottomley wrote:
> On Mon, 2019-02-11 at 19:50 -0700, Jens Axboe wrote:
>> On 2/11/19 7:13 PM, James Bottomley wrote:
>>> On Mon, 2019-02-11 at 09:31 -0700, Jens Axboe wrote:
>>>> On 2/11/19 9:28 AM, James Bottomley wrote:
>>>>
nly if the device actually reports being non-rotational via
> the VPD page.
Reviewed-by: Jens Axboe
--
Jens Axboe
useful error.
>
> Patch below does not show this (unchanged) line:
>ret =__blk_rq_map_user_iov(rq, map_data, &i, gfp_mask, copy);
> That 'ret' was being overridden when that function failed.
Thanks, applied.
--
Jens Axboe
to iron out the last kinks with it being off
by default, I think we should attempt to flip the switch again
for 4.16.
--
Jens Axboe
On 1/29/18 4:46 PM, James Bottomley wrote:
> On Mon, 2018-01-29 at 14:00 -0700, Jens Axboe wrote:
>> On 1/29/18 1:56 PM, James Bottomley wrote:
>>>
>>> On Mon, 2018-01-29 at 23:46 +0800, Ming Lei wrote:
>>> [...]
>>>>
>>>> 2. When to e
rce. For resources of wider scope, allocation
failure can happen without having pending IO. This means that we can't
rely on request completions freeing these resources, as IO may not be in
flight. Examples of that are kernel memory allocations, DMA mappings, or
any other system wide resources.
--
Jens Axboe
ers easier to
> read or to implement. So why is this patch considered useful?
It does fix the run bug on global resources, I'm assuming you mean
it doesn't fix any EXTRA bugs compared to just use the delayed
run?
--
Jens Axboe
ted via blk_mq_sched_restart()
>
> 3) if SCHED_RESTART is set concurently in context because of
> BLK_STS_RESOURCE, blk_mq_delay_run_hw_queue() will cover the above two
> cases and make sure IO hang can be avoided.
>
> One invariant is that queue will be rerun if SCHED_RESTART is set.
Applied, thanks.
--
Jens Axboe
On 1/30/18 8:21 PM, Bart Van Assche wrote:
> On Tue, 2018-01-30 at 20:17 -0700, Jens Axboe wrote:
>> BLK_STS_RESOURCE should always be safe to return, and it should work
>> the same as STS_DEV_RESOURCE, except it may cause an extra queue
>> run.
>>
>>
On 1/30/18 8:27 PM, Bart Van Assche wrote:
> On Tue, 2018-01-30 at 20:22 -0700, Jens Axboe wrote:
>> On 1/30/18 8:21 PM, Bart Van Assche wrote:
>>> On Tue, 2018-01-30 at 20:17 -0700, Jens Axboe wrote:
>>>> BLK_STS_RESOURCE should always be safe to return, and i
fied that this patch makes HPSA working with the linus
> tree with this patchset.
Do you have any performance numbers for this patchset? I'd be curious
to know how big the hit is.
--
Jens Axboe
data is provided, no obvious performance loss is observed when the whole
> hw queue depth is same.
GLOBAL implies that it's, strangely enough, global. That isn't really the
case. Why not call this BLK_MQ_F_HOST_TAGS or something like that? I'd
welcome better names, but global doesn't seem to be a great choice.
BLK_MQ_F_SET_TAGS?
--
Jens Axboe
t task acquires the s_umount lock and then the sr_mutex_lock;
> the second task acquires the sr_mutex_lock and then the s_umount lock.
>
> This patch fixes the issue by moving check_disk_change() out of
> cdrom_open() and let the caller take care of it.
Looks good to me, applied.
--
Jens Axboe
onfusing, and also makes sure we can sanity check the requests
> we get. The current code will happily execute scsi commands against
> bsg-lib queues, and transport pass through against scsi nodes, without
> any indication to the driver that we are doing the wrong thing.
Applied for 4.17, thanks.
--
Jens Axboe
ng that Martin will eventually queue this up. But probably
for 4.17, then we can always flag it for a backport to stable once
it's been thoroughly tested.
--
Jens Axboe
rivers using this API accordingly.
Looks good to me, I'll queue it up for 4.17.
--
Jens Axboe
guess that this is dying inside
> blkg_rwstat_add, which calls percpu_counter_add_batch, which is what RIP
> is pointing at.
Leaving the whole thing here for Paolo - it's crashing off insertion of
a request coming out of SG_IO. Don't think we've seen this BFQ failure
case before.
You can mitigate this by switching the scsi-mq devices to mq-deadline
instead.
--
Jens Axboe
On 3/28/18 9:13 PM, Zephaniah E. Loss-Cutler-Hull wrote:
> On 03/28/2018 06:02 PM, Jens Axboe wrote:
>> On 3/28/18 5:03 PM, Zephaniah E. Loss-Cutler-Hull wrote:
>>> I am not subscribed to any of the lists on the To list here, please CC
>>> me on any replies.
>>
anks for debugging this. However, the scsi code looks a bit dangerous,
if it assumes that ->sense_len is >= SCSI_SENSE_BUFFERSIZE. I think the
correct fix would be to fix that assumption, and ensure that the path
of sr is correctly setting sense_len.
--
Jens Axboe
601 - 700 of 1039 matches
Mail list logo
