On 08/03/2017 18:46, Steven Rostedt wrote:
> On Wed, 8 Mar 2017 12:40:12 -0500
> Steven Rostedt wrote:
>
>> I wonder if we should just have a special flag sent by that sysrq
>> trigger. Since it is causing all tasks to go "nice" there's no need to
>> do the pi chain walk in
On 08/03/2017 18:46, Steven Rostedt wrote:
> On Wed, 8 Mar 2017 12:40:12 -0500
> Steven Rostedt wrote:
>
>> I wonder if we should just have a special flag sent by that sysrq
>> trigger. Since it is causing all tasks to go "nice" there's no need to
>> do the pi chain walk in
On 08/03/2017 17:57, Steven Rostedt wrote:
> On Wed, 8 Mar 2017 11:51:14 -0500
> Steven Rostedt wrote:
>
>
>> Hmm, that commit was added in 2.6.18, and you're right, a lot has
>> changed since then. Have you tried removing it and running it under
>> lockdep, and see if it
On 08/03/2017 17:57, Steven Rostedt wrote:
> On Wed, 8 Mar 2017 11:51:14 -0500
> Steven Rostedt wrote:
>
>
>> Hmm, that commit was added in 2.6.18, and you're right, a lot has
>> changed since then. Have you tried removing it and running it under
>> lockdep, and see if it triggers any warnings?
On Wed, 8 Mar 2017 12:40:12 -0500
Steven Rostedt wrote:
> I wonder if we should just have a special flag sent by that sysrq
> trigger. Since it is causing all tasks to go "nice" there's no need to
> do the pi chain walk in __sched_setscheduler().
Hah, there already is a
On Wed, 8 Mar 2017 12:40:12 -0500
Steven Rostedt wrote:
> I wonder if we should just have a special flag sent by that sysrq
> trigger. Since it is causing all tasks to go "nice" there's no need to
> do the pi chain walk in __sched_setscheduler().
Hah, there already is a flag!
Laurent, can you
[
Added Peter
Update: Laurent noticed that sysrq 'n' (nice-all-RT-tasks) calls
__sched_setscheduler() form interrupt context. At the start of that
function, there's a BUG_ON(in_interrupt()). The reason for that was
due to the rt mutex pi code calling wait_lock. Which was not irq
[
Added Peter
Update: Laurent noticed that sysrq 'n' (nice-all-RT-tasks) calls
__sched_setscheduler() form interrupt context. At the start of that
function, there's a BUG_ON(in_interrupt()). The reason for that was
due to the rt mutex pi code calling wait_lock. Which was not irq
On Wed, 8 Mar 2017 11:51:14 -0500
Steven Rostedt wrote:
> Hmm, that commit was added in 2.6.18, and you're right, a lot has
> changed since then. Have you tried removing it and running it under
> lockdep, and see if it triggers any warnings?
I did a little digging, and it
On Wed, 8 Mar 2017 11:51:14 -0500
Steven Rostedt wrote:
> Hmm, that commit was added in 2.6.18, and you're right, a lot has
> changed since then. Have you tried removing it and running it under
> lockdep, and see if it triggers any warnings?
I did a little digging, and it appears that its the
On Wed, 8 Mar 2017 16:23:35 +0100
Laurent Dufour wrote:
> I got it on Power and on X86_64, but I guess it should happen in all
> architectures.
> Here are the steps to recreate it :
> 1. Create a RT task : sudo chrt -f 50 /bin/sleep 99
> 2. On the console trigger
On Wed, 8 Mar 2017 16:23:35 +0100
Laurent Dufour wrote:
> I got it on Power and on X86_64, but I guess it should happen in all
> architectures.
> Here are the steps to recreate it :
> 1. Create a RT task : sudo chrt -f 50 /bin/sleep 99
> 2. On the console trigger the 'nice-all-RT-tasks'
Hi,
It appears that triggering the SysRq nice-all-RT-tasks from the console
while a real task is active is leading to panic the system like this :
sysrq: SysRq : Nice All RT Tasks
[ cut here ]
kernel BUG at /build/linux-twbIHf/linux-4.10.0/kernel/sched/core.c:4089!
Hi,
It appears that triggering the SysRq nice-all-RT-tasks from the console
while a real task is active is leading to panic the system like this :
sysrq: SysRq : Nice All RT Tasks
[ cut here ]
kernel BUG at /build/linux-twbIHf/linux-4.10.0/kernel/sched/core.c:4089!
14 matches
Mail list logo