On 07/28/2017 10:17 AM, Brian J King wrote:
> Jens Axboe wrote on 07/28/2017 09:25:48 AM:
>
>> Can you try the below fix? Should be more palatable than the previous
>> one. Brian, maybe you can take a look at the IRQ issue mentioned above?
Michael,
Does this address the issue you are seeing?
T
BFQ implements hierarchical scheduling by representing each group of
queues with a generic parent entity. For each parent entity, BFQ
maintains an in_service_entity pointer: if one of the child entities
happens to be in service, in_service_entity points to it. The
resetting of these pointers happe
On Fri, Jul 28 2017 at 12:17pm -0400,
Bart Van Assche wrote:
> On Mon, 2017-04-17 at 12:09 -0700, Dan Williams wrote:
> > diff --git a/drivers/md/Kconfig b/drivers/md/Kconfig
> > index b7767da50c26..1de8372d9459 100644
> > --- a/drivers/md/Kconfig
> > +++ b/drivers/md/Kconfig
> > @@ -200,6 +200,7
On Mon, 2017-04-17 at 12:09 -0700, Dan Williams wrote:
> diff --git a/drivers/md/Kconfig b/drivers/md/Kconfig
> index b7767da50c26..1de8372d9459 100644
> --- a/drivers/md/Kconfig
> +++ b/drivers/md/Kconfig
> @@ -200,6 +200,7 @@ config BLK_DEV_DM_BUILTIN
> config BLK_DEV_DM
> tristate "Device
Hi Linus,
A small collection of fixes that should go into this series. This pull
request contains:
- NVMe pull request from Christoph, with various fixes for nvme proper
and nvme-fc.
- Disabling runtime PM for blk-mq for now. With scsi now defaulting to
using blk-mq, this reared it's head as
On 07/28/2017 09:13 AM, Bart Van Assche wrote:
> On Fri, 2017-07-28 at 08:25 -0600, Jens Axboe wrote:
>> On 07/28/2017 12:19 AM, Michael Ellerman wrote:
>>> OK, so the resolution is "fix it in IPR" ?
>>
>> I'll leave that to the SCSI crew. But at least one bug is in IPR, if you
>> look at the call
On Fri, 2017-07-28 at 08:25 -0600, Jens Axboe wrote:
> On 07/28/2017 12:19 AM, Michael Ellerman wrote:
> > OK, so the resolution is "fix it in IPR" ?
>
> I'll leave that to the SCSI crew. But at least one bug is in IPR, if you
> look at the call trace:
>
> - timer function triggers, runs ipr_rese
On 07/26/17 00:25, Keith Busch wrote:
> On Fri, Jul 21, 2017 at 07:07:06PM +0200, Benoit Depail wrote:
>> On 07/21/17 18:07, Roger Pau Monné wrote:
>>>
>>> Hm, I'm not sure I follow either. AFAIK this problem came from
>>> changing the Linux version in the Dom0 (where the backend, blkback is
>>> ru
On 07/28/2017 12:19 AM, Michael Ellerman wrote:
> Jens Axboe writes:
>> On 07/27/2017 08:47 AM, Bart Van Assche wrote:
>>> On Thu, 2017-07-27 at 08:02 -0600, Jens Axboe wrote:
The bug looks like SCSI running the queue inline from IRQ
context, that's not a good idea.
> ...
>>>
>>> scsi_ru
> On 28 Jul 2017, at 16.06, Jens Axboe wrote:
>
> On 07/28/2017 07:13 AM, Javier González wrote:
>> Hi Jens,
>>
>> Can you pick up this fix for 4.13? It is a fix to a read corruption in
>> pblk that has been there form the beginning. It is due to a bad bio
>> manipulation in the case that an I/O
On 07/28/2017 07:13 AM, Javier González wrote:
> Hi Jens,
>
> Can you pick up this fix for 4.13? It is a fix to a read corruption in
> pblk that has been there form the beginning. It is due to a bad bio
> manipulation in the case that an I/O containing lbas that are invalid,
> point to data in the
Hi Jens,
Can you pick up this fix for 4.13? It is a fix to a read corruption in
pblk that has been there form the beginning. It is due to a bad bio
manipulation in the case that an I/O containing lbas that are invalid,
point to data in the host cache and point to data on the device, all
three in a
When a lba either hits the cache or corresponds to an empty entry in the
L2P table, we need to advance the bio according to the position in which
the lba is located. Otherwise, we will copy data in the wrong page, thus
causing data corruption for the application.
In case of a cache hit, we assumed
13 matches
Mail list logo