On Thu, Jan 8, 2015 at 1:29 AM, Christoph Hellwig wrote:
> On Wed, Jan 07, 2015 at 07:55:42PM -0800, Alexei Starovoitov wrote:
>> I'm seeing the same splats... what tree I can pull the fix from ?
>
> None so far. I'll still need a review to apply it to the scsi-queue tree.
applied it manually an
On Wed, Jan 07, 2015 at 07:55:42PM -0800, Alexei Starovoitov wrote:
> I'm seeing the same splats... what tree I can pull the fix from ?
None so far. I'll still need a review to apply it to the scsi-queue tree.
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of
On Mon, Jan 5, 2015 at 11:42 AM, Christoph Hellwig wrote:
> On Mon, Jan 05, 2015 at 12:38:04PM -0700, Jens Axboe wrote:
>> That was true in earlier kernels as well, going back a few versions at
>> least, preempt was disabled on calling __blk_mq_run_hw_queue(). Just
>> checked, and 3.16 and later h
On Mon, Jan 05, 2015 at 12:38:04PM -0700, Jens Axboe wrote:
> That was true in earlier kernels as well, going back a few versions at
> least, preempt was disabled on calling __blk_mq_run_hw_queue(). Just
> checked, and 3.16 and later have that as the behaviour. The only change
> in 3.19 some shuffl
On 01/05/2015 12:32 PM, Christoph Hellwig wrote:
> On Mon, Jan 05, 2015 at 12:00:58PM -0700, Jens Axboe wrote:
>> That's not quite true, the only guarantee is that it WILL execute on the
>> CPU (or CPUs) that are set in the mask. So unless it ends up offloading
>> the run to a specific workqueue, w
On Mon, Jan 05, 2015 at 12:00:58PM -0700, Jens Axboe wrote:
> That's not quite true, the only guarantee is that it WILL execute on the
> CPU (or CPUs) that are set in the mask. So unless it ends up offloading
> the run to a specific workqueue, we'll disable preempt in the current
> path before ->qu
On 01/05/2015 02:15 AM, Christoph Hellwig wrote:
> On Wed, Dec 31, 2014 at 01:14:19PM -0500, Sasha Levin wrote:
>> Hi Christoph,
>>
>> I'm seeing an issue which was bisected down to 3c356bde1 ("scsi: stop passing
>> a gfp_mask argument down the command setup path"):
>
> ->queue_rq in blk-mq contex
On 01/05/2015 04:15 AM, Christoph Hellwig wrote:
> On Wed, Dec 31, 2014 at 01:14:19PM -0500, Sasha Levin wrote:
>> Hi Christoph,
>>
>> I'm seeing an issue which was bisected down to 3c356bde1 ("scsi: stop passing
>> a gfp_mask argument down the command setup path"):
>
> ->queue_rq in blk-mq contex
On Wed, Dec 31, 2014 at 01:14:19PM -0500, Sasha Levin wrote:
> Hi Christoph,
>
> I'm seeing an issue which was bisected down to 3c356bde1 ("scsi: stop passing
> a gfp_mask argument down the command setup path"):
->queue_rq in blk-mq context is designed to be able to sleep and be called
from proce
On 14-12-31 01:14 PM, Sasha Levin wrote:
Hi Christoph,
I'm seeing an issue which was bisected down to 3c356bde1 ("scsi: stop passing
a gfp_mask argument down the command setup path"):
[ 3395.328221] BUG: sleeping function called from invalid context at
mm/mempool.c:206
[ 3395.329540] in_atomic
Hi Christoph,
I'm seeing an issue which was bisected down to 3c356bde1 ("scsi: stop passing
a gfp_mask argument down the command setup path"):
[ 3395.328221] BUG: sleeping function called from invalid context at
mm/mempool.c:206
[ 3395.329540] in_atomic(): 1, irqs_disabled(): 0, pid: 6399, name:
11 matches
Mail list logo
