On Sun, 2017-05-07 at 11:22 +0200, h...@lst.de wrote:
> On Tue, May 02, 2017 at 08:33:15PM -0700, Nicholas A. Bellinger wrote:
> > The larger target/iblock conversion patch looks like post v4.12 material
> > at this point, so to avoid breakage wrt to existing LBPRZ behavior, I'll
> > plan to push t
On 2017.05.08 at 20:22 -0600, Jens Axboe wrote:
>
> > On May 8, 2017, at 8:18 PM, Elliott, Robert (Persistent Memory)
> > wrote:
> >> +printk(KERN_ERR "elevator: type %s not found\n", name);
> > ...
> >> +printk(KERN_ERR "elevator: switch to %s failed\n",
> >
> > That leaves two line
Hi Keith.
On Tue, May 09, 2017 at 09:10:30AM +0800, Ming Lei wrote:
> Hi Keith,
>
> Thanks for looking at this issue!
>
> On Mon, May 08, 2017 at 01:25:12PM -0400, Keith Busch wrote:
> > On Tue, May 09, 2017 at 12:15:25AM +0800, Ming Lei wrote:
> > > This patch looks working, but seems any 'goto
> On May 8, 2017, at 8:18 PM, Elliott, Robert (Persistent Memory)
> wrote:
>
>
>
>> -Original Message-
>> From: linux-block-ow...@vger.kernel.org [mailto:linux-block-
>> ow...@vger.kernel.org] On Behalf Of mar...@trippelsdorf.de
>> Sent: Saturday, May 06, 2017 12:23 AM
>> To: Bart Van
> -Original Message-
> From: linux-block-ow...@vger.kernel.org [mailto:linux-block-
> ow...@vger.kernel.org] On Behalf Of mar...@trippelsdorf.de
> Sent: Saturday, May 06, 2017 12:23 AM
> To: Bart Van Assche
> Cc: linux-block@vger.kernel.org; ax...@kernel.dk
> Subject: [PATCH] block: Remo
Christoph,
> Any chance to get a sneak preview of that work?
I have been on the road since LSF/MM and just got back home. I'll make
it a priority.
--
Martin K. Petersen Oracle Linux Engineering
Hi Keith,
Thanks for looking at this issue!
On Mon, May 08, 2017 at 01:25:12PM -0400, Keith Busch wrote:
> On Tue, May 09, 2017 at 12:15:25AM +0800, Ming Lei wrote:
> > This patch looks working, but seems any 'goto out' in this function
> > may have rick to cause the same race too.
>
> The goto
Hi Dan,
[auto build test ERROR on linus/master]
[also build test ERROR on next-20170508]
[cannot apply to v4.11]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits/Dan-Williams/block-dax-move
For configurations that do not enable DAX filesystems or drivers, do not
require the DAX core to be built.
The only core block routine that calls a DAX routine is
bdev_dax_supported(), that now fails by default as expected if FS_DAX=n,
or no DAX-capable drivers are configured.
Reported-by: Geert
There is no point to ask how many device-dax instances the kernel should
support. Since we are already using a dynamic major number, just allow
the max number of minors by default and be done. This also fixes the
fact that the proposed max for the NR_DEV_DAX range was larger than what
could be supp
On Mon, May 8, 2017 at 1:32 PM, Ross Zwisler
wrote:
> On Fri, Apr 28, 2017 at 12:39:12PM -0700, Dan Williams wrote:
>> The pmem driver has a need to transfer data with a persistent memory
>> destination and be able to rely on the fact that the destination writes
>> are not cached. It is sufficient
On Fri, Apr 28, 2017 at 12:39:12PM -0700, Dan Williams wrote:
> The pmem driver has a need to transfer data with a persistent memory
> destination and be able to rely on the fact that the destination writes
> are not cached. It is sufficient for the writes to be flushed to a
> cpu-store-buffer (non
On Tue, May 09, 2017 at 12:15:25AM +0800, Ming Lei wrote:
> This patch looks working, but seems any 'goto out' in this function
> may have rick to cause the same race too.
The goto was really intended for handling totally broken contronllers,
which isn't the case if someone requested to remove the
On 05/05/2017 11:22 PM, mar...@trippelsdorf.de wrote:
>
> Trying to switch to a non-existing elevator currently results in garbled
> dmesg output, e.g.:
>
> # echo " foo" > /sys/block/sda/queue/scheduler
>
> elevator: type foo not found
> elevator: switch to foo
> failed
>
> (note the l
On Mon, 2017-05-08 at 18:48 +0200, mar...@trippelsdorf.de wrote:
> On 2017.05.08 at 15:47 +, Bart Van Assche wrote:
> > On Sat, 2017-05-06 at 07:22 +0200, mar...@trippelsdorf.de wrote:
> > > - ret = __elevator_change(q, name);
> > > + strlcpy(elevator_name, skip_spaces(name), sizeof(elevator_na
On 2017.05.08 at 15:47 +, Bart Van Assche wrote:
> On Sat, 2017-05-06 at 07:22 +0200, mar...@trippelsdorf.de wrote:
> > - ret = __elevator_change(q, name);
> > + strlcpy(elevator_name, skip_spaces(name), sizeof(elevator_name));
>
> Please include the version number of a patch in the e-mail
> On 8 May 2017, at 18.06, Jens Axboe wrote:
>
> On 05/08/2017 09:49 AM, Javier González wrote:
>>> On 8 May 2017, at 17.40, Jens Axboe wrote:
>>>
>>> On 05/08/2017 09:38 AM, Javier González wrote:
> On 8 May 2017, at 17.25, Jens Axboe wrote:
>
> On 05/08/2017 09:22 AM, Javier Gon
On Mon, May 08, 2017 at 11:11:24AM -0400, Keith Busch wrote:
> On Mon, May 08, 2017 at 11:07:20AM -0400, Keith Busch wrote:
> > I'm almost certain the remove_work shouldn't even be running in this
> > case. If the reset work can't transition the controller state correctly,
> > it should assume some
On 05/08/2017 09:49 AM, Javier González wrote:
>> On 8 May 2017, at 17.40, Jens Axboe wrote:
>>
>> On 05/08/2017 09:38 AM, Javier González wrote:
On 8 May 2017, at 17.25, Jens Axboe wrote:
On 05/08/2017 09:22 AM, Javier González wrote:
> Javier
>
>> On 8 May 2017, at 17
> On 8 May 2017, at 17.40, Jens Axboe wrote:
>
> On 05/08/2017 09:38 AM, Javier González wrote:
>>> On 8 May 2017, at 17.25, Jens Axboe wrote:
>>>
>>> On 05/08/2017 09:22 AM, Javier González wrote:
Javier
> On 8 May 2017, at 17.14, Jens Axboe wrote:
>
> On 05/08/2017 09
On Sat, 2017-05-06 at 07:22 +0200, mar...@trippelsdorf.de wrote:
> - ret = __elevator_change(q, name);
> + strlcpy(elevator_name, skip_spaces(name), sizeof(elevator_name));
Hello Markus,
Please include the version number of a patch in the e-mail subject line when
posting a second or later
On 05/08/2017 09:38 AM, Javier González wrote:
>> On 8 May 2017, at 17.25, Jens Axboe wrote:
>>
>> On 05/08/2017 09:22 AM, Javier González wrote:
>>> Javier
>>>
On 8 May 2017, at 17.14, Jens Axboe wrote:
On 05/08/2017 09:08 AM, Jens Axboe wrote:
> On 05/08/2017 09:02 AM, Javier
> On 8 May 2017, at 17.25, Jens Axboe wrote:
>
> On 05/08/2017 09:22 AM, Javier González wrote:
>> Javier
>>
>>> On 8 May 2017, at 17.14, Jens Axboe wrote:
>>>
>>> On 05/08/2017 09:08 AM, Jens Axboe wrote:
On 05/08/2017 09:02 AM, Javier González wrote:
>> On 8 May 2017, at 16.52, Jens
On 05/08/2017 09:22 AM, Javier González wrote:
>
> Javier
>
>> On 8 May 2017, at 17.14, Jens Axboe wrote:
>>
>> On 05/08/2017 09:08 AM, Jens Axboe wrote:
>>> On 05/08/2017 09:02 AM, Javier González wrote:
> On 8 May 2017, at 16.52, Jens Axboe wrote:
>
> On 05/08/2017 08:46 AM, Javie
Javier
> On 8 May 2017, at 17.14, Jens Axboe wrote:
>
> On 05/08/2017 09:08 AM, Jens Axboe wrote:
>> On 05/08/2017 09:02 AM, Javier González wrote:
On 8 May 2017, at 16.52, Jens Axboe wrote:
On 05/08/2017 08:46 AM, Javier González wrote:
>> On 8 May 2017, at 16.23, Jens Axb
On 05/08/2017 09:08 AM, Jens Axboe wrote:
> On 05/08/2017 09:02 AM, Javier González wrote:
>>> On 8 May 2017, at 16.52, Jens Axboe wrote:
>>>
>>> On 05/08/2017 08:46 AM, Javier González wrote:
> On 8 May 2017, at 16.23, Jens Axboe wrote:
>
> On 05/08/2017 08:20 AM, Javier González wro
On 05/08/2017 09:02 AM, Javier González wrote:
>> On 8 May 2017, at 16.52, Jens Axboe wrote:
>>
>> On 05/08/2017 08:46 AM, Javier González wrote:
On 8 May 2017, at 16.23, Jens Axboe wrote:
On 05/08/2017 08:20 AM, Javier González wrote:
>> On 8 May 2017, at 16.13, Jens Axboe wr
On Mon, May 08, 2017 at 11:07:20AM -0400, Keith Busch wrote:
> I'm almost certain the remove_work shouldn't even be running in this
> case. If the reset work can't transition the controller state correctly,
> it should assume something is handling the controller.
Here's the more complete version o
> On 8 May 2017, at 16.52, Jens Axboe wrote:
>
> On 05/08/2017 08:46 AM, Javier González wrote:
>>> On 8 May 2017, at 16.23, Jens Axboe wrote:
>>>
>>> On 05/08/2017 08:20 AM, Javier González wrote:
> On 8 May 2017, at 16.13, Jens Axboe wrote:
>
> On 05/08/2017 07:44 AM, Javier Gon
On Mon, May 08, 2017 at 08:46:39PM +0800, Ming Lei wrote:
> On Mon, May 08, 2017 at 07:24:57PM +0800, Ming Lei wrote:
> > diff --git a/drivers/nvme/host/pci.c b/drivers/nvme/host/pci.c
> > index c8541c3dcd19..ebe13e157c00 100644
> > --- a/drivers/nvme/host/pci.c
> > +++ b/drivers/nvme/host/pci.c
>
On 05/08/2017 08:46 AM, Javier González wrote:
>> On 8 May 2017, at 16.23, Jens Axboe wrote:
>>
>> On 05/08/2017 08:20 AM, Javier González wrote:
On 8 May 2017, at 16.13, Jens Axboe wrote:
On 05/08/2017 07:44 AM, Javier González wrote:
>> On 8 May 2017, at 14.27, Ming Lei wrot
> On 8 May 2017, at 16.23, Jens Axboe wrote:
>
> On 05/08/2017 08:20 AM, Javier González wrote:
>>> On 8 May 2017, at 16.13, Jens Axboe wrote:
>>>
>>> On 05/08/2017 07:44 AM, Javier González wrote:
> On 8 May 2017, at 14.27, Ming Lei wrote:
>
> On Mon, May 08, 2017 at 01:54:58PM +
On 05/08/2017 08:20 AM, Javier González wrote:
>> On 8 May 2017, at 16.13, Jens Axboe wrote:
>>
>> On 05/08/2017 07:44 AM, Javier González wrote:
On 8 May 2017, at 14.27, Ming Lei wrote:
On Mon, May 08, 2017 at 01:54:58PM +0200, Javier González wrote:
> Hi,
>
> I find a
> On 8 May 2017, at 16.13, Jens Axboe wrote:
>
> On 05/08/2017 07:44 AM, Javier González wrote:
>>> On 8 May 2017, at 14.27, Ming Lei wrote:
>>>
>>> On Mon, May 08, 2017 at 01:54:58PM +0200, Javier González wrote:
Hi,
I find an unusual added latency(~20-30ms) on blk_queue_enter
On 05/08/2017 07:44 AM, Javier González wrote:
>> On 8 May 2017, at 14.27, Ming Lei wrote:
>>
>> On Mon, May 08, 2017 at 01:54:58PM +0200, Javier González wrote:
>>> Hi,
>>>
>>> I find an unusual added latency(~20-30ms) on blk_queue_enter when
>>> allocating a request directly from the NVMe driver
On 05/08/2017 04:44 AM, Colin King wrote:
> From: Colin Ian King
>
> Making __blk_mq_stop_hw_queues static fixes sparse warning:
>
> block/blk-mq.c:6: warning: symbol '__blk_mq_stop_hw_queues' was not
> declared. Should it be static?
Thanks, added.
--
Jens Axboe
On 05/08/2017 01:13 AM, Abdul Haleem wrote:
> On Fri, 2017-05-05 at 08:02 -0600, Jens Axboe wrote:
>> On 05/05/2017 12:25 AM, Abdul Haleem wrote:
>>> Hi,
>>>
>>> 4.11.0 Linus mainline booted with Warnings on PowerPC.
>>>
>>> We did not see this on next-20170407 but on next-20170410 and later.
>>
>>
> On 8 May 2017, at 14.27, Ming Lei wrote:
>
> On Mon, May 08, 2017 at 01:54:58PM +0200, Javier González wrote:
>> Hi,
>>
>> I find an unusual added latency(~20-30ms) on blk_queue_enter when
>> allocating a request directly from the NVMe driver through
>> nvme_alloc_request. I could use some hel
On Mon, May 08, 2017 at 07:24:57PM +0800, Ming Lei wrote:
> If hw queue is stopped, the following hang can be triggered
> when doing pci reset/remove and running heavy I/O load
> meantime.
>
> This patch fixes the issue by calling nvme_uninit_ctrl()
> just after nvme_dev_disable(dev, true) in nvme
On Mon, May 08, 2017 at 01:54:58PM +0200, Javier González wrote:
> Hi,
>
> I find an unusual added latency(~20-30ms) on blk_queue_enter when
> allocating a request directly from the NVMe driver through
> nvme_alloc_request. I could use some help confirming that this is a bug
> and not an expected
Hi,
I find an unusual added latency(~20-30ms) on blk_queue_enter when
allocating a request directly from the NVMe driver through
nvme_alloc_request. I could use some help confirming that this is a bug
and not an expected side effect due to something else.
I can reproduce this latency consistently
If hw queue is stopped, the following hang can be triggered
when doing pci reset/remove and running heavy I/O load
meantime.
This patch fixes the issue by calling nvme_uninit_ctrl()
just after nvme_dev_disable(dev, true) in nvme_remove().
[ 492.232593] INFO: task nvme-test:5939 blocked for more
From: Colin Ian King
Making __blk_mq_stop_hw_queues static fixes sparse warning:
block/blk-mq.c:6: warning: symbol '__blk_mq_stop_hw_queues' was not
declared. Should it be static?
Fixes: 2719aa217e0d0 ("blk-mq: don't use sync workqueue flushing from drivers")
Signed-off-by: Colin Ian King
On Fri, 2017-05-05 at 08:02 -0600, Jens Axboe wrote:
> On 05/05/2017 12:25 AM, Abdul Haleem wrote:
> > Hi,
> >
> > 4.11.0 Linus mainline booted with Warnings on PowerPC.
> >
> > We did not see this on next-20170407 but on next-20170410 and later.
>
> Have you tried current Linus -git? Both of th
44 matches
Mail list logo
