Mike Galbraith writes:
> On Thu, 2017-05-18 at 17:40 -0300, Gabriel Krisman Bertazi wrote:
>> > Mike Galbraith writes:
>>
>> >
>> > On Mon, 2017-05-08 at 16:48 -0300, Gabriel Krisman Bertazi wrote:
>> >
>> > >
>> > > Thanks for reporting this. Can you confirm
Mike Galbraith writes:
> On Thu, 2017-05-18 at 17:40 -0300, Gabriel Krisman Bertazi wrote:
>> > Mike Galbraith writes:
>>
>> >
>> > On Mon, 2017-05-08 at 16:48 -0300, Gabriel Krisman Bertazi wrote:
>> >
>> > >
>> > > Thanks for reporting this. Can you confirm the following patch prevents
On Thu, 2017-05-18 at 17:40 -0300, Gabriel Krisman Bertazi wrote:
> > Mike Galbraith writes:
>
> >
> > On Mon, 2017-05-08 at 16:48 -0300, Gabriel Krisman Bertazi wrote:
> >
> > >
> > > Thanks for reporting this. Can you confirm the following patch prevents
> > > the issue?
> >
On Thu, 2017-05-18 at 17:40 -0300, Gabriel Krisman Bertazi wrote:
> > Mike Galbraith writes:
>
> >
> > On Mon, 2017-05-08 at 16:48 -0300, Gabriel Krisman Bertazi wrote:
> >
> > >
> > > Thanks for reporting this. Can you confirm the following patch prevents
> > > the issue?
> >
> > Nope, it
Mike Galbraith writes:
> On Mon, 2017-05-08 at 16:48 -0300, Gabriel Krisman Bertazi wrote:
>
>> Thanks for reporting this. Can you confirm the following patch prevents
>> the issue?
>
> Nope, it still gripes.
Oops... Thanks for checking. The following patch fixes the issue for
Mike Galbraith writes:
> On Mon, 2017-05-08 at 16:48 -0300, Gabriel Krisman Bertazi wrote:
>
>> Thanks for reporting this. Can you confirm the following patch prevents
>> the issue?
>
> Nope, it still gripes.
Oops... Thanks for checking. The following patch fixes the issue for
me. Can you
Mike Galbraith writes:
> On Tue, 2017-05-09 at 04:37 +0200, Mike Galbraith wrote:
>> On Mon, 2017-05-08 at 16:48 -0300, Gabriel Krisman Bertazi wrote:
>>
>> > Thanks for reporting this. Can you confirm the following patch prevents
>> > the issue?
>>
>> Nope, it still gripes.
>
Mike Galbraith writes:
> On Tue, 2017-05-09 at 04:37 +0200, Mike Galbraith wrote:
>> On Mon, 2017-05-08 at 16:48 -0300, Gabriel Krisman Bertazi wrote:
>>
>> > Thanks for reporting this. Can you confirm the following patch prevents
>> > the issue?
>>
>> Nope, it still gripes.
>
> The reason
On Tue, 2017-05-09 at 04:37 +0200, Mike Galbraith wrote:
> On Mon, 2017-05-08 at 16:48 -0300, Gabriel Krisman Bertazi wrote:
>
> > Thanks for reporting this. Can you confirm the following patch prevents
> > the issue?
>
> Nope, it still gripes.
The reason for this gripe is that we find that we
On Tue, 2017-05-09 at 04:37 +0200, Mike Galbraith wrote:
> On Mon, 2017-05-08 at 16:48 -0300, Gabriel Krisman Bertazi wrote:
>
> > Thanks for reporting this. Can you confirm the following patch prevents
> > the issue?
>
> Nope, it still gripes.
The reason for this gripe is that we find that we
On Mon, 2017-05-08 at 16:48 -0300, Gabriel Krisman Bertazi wrote:
> Thanks for reporting this. Can you confirm the following patch prevents
> the issue?
Nope, it still gripes.
[ 43.910362] BUG: sleeping function called from invalid context at
mm/slab.h:432
[ 43.910955] in_atomic(): 1,
On Mon, 2017-05-08 at 16:48 -0300, Gabriel Krisman Bertazi wrote:
> Thanks for reporting this. Can you confirm the following patch prevents
> the issue?
Nope, it still gripes.
[ 43.910362] BUG: sleeping function called from invalid context at
mm/slab.h:432
[ 43.910955] in_atomic(): 1,
Mike Galbraith writes:
> Greetings,
>
> I'm meeting this splat in master, call io_mapping_map_atomic_wc(),
> then do something sleepy. In master-rt, I meet a variant of this
> doing read_lock() in find_next_iomem_res(), due to rwlocks being
> sleepy in RT.
>
Hi Mike,
Thanks for
Mike Galbraith writes:
> Greetings,
>
> I'm meeting this splat in master, call io_mapping_map_atomic_wc(),
> then do something sleepy. In master-rt, I meet a variant of this
> doing read_lock() in find_next_iomem_res(), due to rwlocks being
> sleepy in RT.
>
Hi Mike,
Thanks for reporting
Greetings,
I'm meeting this splat in master, call io_mapping_map_atomic_wc(),
then do something sleepy. In master-rt, I meet a variant of this
doing read_lock() in find_next_iomem_res(), due to rwlocks being
sleepy in RT.
[ 53.286236] BUG: sleeping function called from invalid context at
Greetings,
I'm meeting this splat in master, call io_mapping_map_atomic_wc(),
then do something sleepy. In master-rt, I meet a variant of this
doing read_lock() in find_next_iomem_res(), due to rwlocks being
sleepy in RT.
[ 53.286236] BUG: sleeping function called from invalid context at
16 matches
Mail list logo