On Fri, 2017-01-20 at 18:34 +0100, Sebastian Andrzej Siewior wrote:
> On 2017-01-20 18:29:54 [+0100], Mike Galbraith wrote:
> > On Fri, 2017-01-20 at 17:46 +0100, Sebastian Andrzej Siewior wrote:
> > > On 2016-12-26 08:00:54 [+0100], Mike Galbraith wrote:
> > > > Sham
On Fri, 2017-01-20 at 18:34 +0100, Sebastian Andrzej Siewior wrote:
> On 2017-01-20 18:29:54 [+0100], Mike Galbraith wrote:
> > On Fri, 2017-01-20 at 17:46 +0100, Sebastian Andrzej Siewior wrote:
> > > On 2016-12-26 08:00:54 [+0100], Mike Galbraith wrote:
> > > > Sham
On Fri, 2017-01-20 at 17:44 +0100, Sebastian Andrzej Siewior wrote:
> kvm_make_mclock_inprogress_request() will do zalloc_cpumask_var().
> off-stack zalloc is not yet working but I would like to enable it. Also
> it does a SMP function call.
>
> Couldn't we go the other way around and drop the
On Fri, 2017-01-20 at 17:44 +0100, Sebastian Andrzej Siewior wrote:
> kvm_make_mclock_inprogress_request() will do zalloc_cpumask_var().
> off-stack zalloc is not yet working but I would like to enable it. Also
> it does a SMP function call.
>
> Couldn't we go the other way around and drop the
On Fri, 2017-01-20 at 17:46 +0100, Sebastian Andrzej Siewior wrote:
> On 2016-12-26 08:00:54 [+0100], Mike Galbraith wrote:
> > Shamelessly steal softirq.c thread initialization method.
> What is the problem here?
There is no problem in 4.9. I did that for upstream, thought it
On Fri, 2017-01-20 at 17:46 +0100, Sebastian Andrzej Siewior wrote:
> On 2016-12-26 08:00:54 [+0100], Mike Galbraith wrote:
> > Shamelessly steal softirq.c thread initialization method.
> What is the problem here?
There is no problem in 4.9. I did that for upstream, thought it
On Thu, 2017-01-19 at 11:19 +0100, Peter Zijlstra wrote:
> OK, you also forgot to tell what you did to trigger this, but a little
> playing around seems enough to reproduce. All that was required was
> offline + online and *boom*.
Oh, sorry, it was Steven's hotplug stress script. I thought the
On Thu, 2017-01-19 at 11:19 +0100, Peter Zijlstra wrote:
> OK, you also forgot to tell what you did to trigger this, but a little
> playing around seems enough to reproduce. All that was required was
> offline + online and *boom*.
Oh, sorry, it was Steven's hotplug stress script. I thought the
Mindless testing only, too sick to work, not sick enough to be immune
to boredom. Was verifying first warning wasn't somehow rt inspired,
but while doing so, plain nopreempt (and no rt patch set) went boom.
[ 203.088255] smpboot: CPU 1 is now offline
[ 203.168181] smpboot: CPU 2 is now offline
Mindless testing only, too sick to work, not sick enough to be immune
to boredom. Was verifying first warning wasn't somehow rt inspired,
but while doing so, plain nopreempt (and no rt patch set) went boom.
[ 203.088255] smpboot: CPU 1 is now offline
[ 203.168181] smpboot: CPU 2 is now offline
On Sat, 2017-01-14 at 04:50 -0800, tip-bot for Tejun Heo wrote:
> diff --git a/include/linux/mutex.h b/include/linux/mutex.h
> index b97870f..980ba16 100644
> --- a/include/linux/mutex.h
> +++ b/include/linux/mutex.h
> @@ -171,11 +173,13 @@ do {
On Sat, 2017-01-14 at 04:50 -0800, tip-bot for Tejun Heo wrote:
> diff --git a/include/linux/mutex.h b/include/linux/mutex.h
> index b97870f..980ba16 100644
> --- a/include/linux/mutex.h
> +++ b/include/linux/mutex.h
> @@ -171,11 +173,13 @@ do {
On Thu, 2017-01-12 at 10:44 -0800, Liu Bo wrote:
> On Thu, Jan 12, 2017 at 07:12:12PM +0100, Mike Galbraith wrote:
> > Greetings,
> >
> > I wanted to do some -rt testing, but seems non-rt kernels aren't
> > lockdep clean with btrfs /, making -rt testing a bit prematu
On Thu, 2017-01-12 at 10:44 -0800, Liu Bo wrote:
> On Thu, Jan 12, 2017 at 07:12:12PM +0100, Mike Galbraith wrote:
> > Greetings,
> >
> > I wanted to do some -rt testing, but seems non-rt kernels aren't
> > lockdep clean with btrfs /, making -rt testing a bit prematu
Greetings,
I wanted to do some -rt testing, but seems non-rt kernels aren't
lockdep clean with btrfs /, making -rt testing a bit premature.
(hm, 28a235931 Btrfs: fix lockdep warning on deadlock against an inode's log
mutex)
[ 876.622587] =
[
Greetings,
I wanted to do some -rt testing, but seems non-rt kernels aren't
lockdep clean with btrfs /, making -rt testing a bit premature.
(hm, 28a235931 Btrfs: fix lockdep warning on deadlock against an inode's log
mutex)
[ 876.622587] =
[
no reason why we can't use a spinlock instead of the mutex.
Signed-off-by: Mike Galbraith <efa...@gmx.de>
Cc: stable...@vger.kernel.org
---
kernel/cpuset.c | 66
1 file changed, 33 insertions(+), 33 deletions(-)
--- a/kernel/cpuset.c
+++ b/
no reason why we can't use a spinlock instead of the mutex.
Signed-off-by: Mike Galbraith
Cc: stable...@vger.kernel.org
---
kernel/cpuset.c | 66
1 file changed, 33 insertions(+), 33 deletions(-)
--- a/kernel/cpuset.c
+++ b/kernel/cpuset.c
On Sun, 2016-12-18 at 19:45 -0800, Davidlohr Bueso wrote:
> Nit: the title is a bit unclear. How about:
>
> ipc/sem.: fix semop() locking imbalance
>
> Otherwise, Ack.
(notices patchlet _not_ flying upstream... s/failure/imbalance?)
On Sun, 2016-12-18 at 19:45 -0800, Davidlohr Bueso wrote:
> Nit: the title is a bit unclear. How about:
>
> ipc/sem.: fix semop() locking imbalance
>
> Otherwise, Ack.
(notices patchlet _not_ flying upstream... s/failure/imbalance?)
Trace of the bad thing about to happen.
madvise06-4719 [003] ... 1187.428766: handle_mm_fault
<-__do_page_fault
madvise06-4719 [003] ... 1187.428766: __rcu_read_lock
<-handle_mm_fault
madvise06-4719 [003] ... 1187.428766: mem_cgroup_from_task
Trace of the bad thing about to happen.
madvise06-4719 [003] ... 1187.428766: handle_mm_fault
<-__do_page_fault
madvise06-4719 [003] ... 1187.428766: __rcu_read_lock
<-handle_mm_fault
madvise06-4719 [003] ... 1187.428766: mem_cgroup_from_task
On Fri, 2017-01-06 at 13:20 +0100, Mike Galbraith wrote:
> > > madvise06 isn't as deadly to the twiddled PREEMPT kernel as
> it is to PREEMPT_RT_FULL, but a very few runs attracted the oom beast.
The very next run paniced the box... deadly enough for gvt. work :)
On Fri, 2017-01-06 at 13:20 +0100, Mike Galbraith wrote:
> > > madvise06 isn't as deadly to the twiddled PREEMPT kernel as
> it is to PREEMPT_RT_FULL, but a very few runs attracted the oom beast.
The very next run paniced the box... deadly enough for gvt. work :)
On Fri, 2017-01-06 at 11:52 +0100, Mike Galbraith wrote:
> On Fri, 2017-01-06 at 09:55 +0100, Michal Hocko wrote:
> > On Fri 06-01-17 09:13:23, Mike Galbraith wrote:
> > > radix-tree: Partially disable memcg accounting in radix_tree_node_alloc()
> > >
> >
On Fri, 2017-01-06 at 11:52 +0100, Mike Galbraith wrote:
> On Fri, 2017-01-06 at 09:55 +0100, Michal Hocko wrote:
> > On Fri 06-01-17 09:13:23, Mike Galbraith wrote:
> > > radix-tree: Partially disable memcg accounting in radix_tree_node_alloc()
> > >
> >
On Fri, 2017-01-06 at 09:55 +0100, Michal Hocko wrote:
> On Fri 06-01-17 09:13:23, Mike Galbraith wrote:
> > radix-tree: Partially disable memcg accounting in radix_tree_node_alloc()
> >
> > Having no preload, which turns accounting off for non-rt kernels, trying to
>
On Fri, 2017-01-06 at 09:55 +0100, Michal Hocko wrote:
> On Fri 06-01-17 09:13:23, Mike Galbraith wrote:
> > radix-tree: Partially disable memcg accounting in radix_tree_node_alloc()
> >
> > Having no preload, which turns accounting off for non-rt kernels, trying to
>
) consequences.
LTP's madvise06 testcase triggers this quite well, and per gitk, the below
was the beginning of RT memcg woes.
58e698af4c63 radix-tree: account radix_tree_node to memory cgroup
Turn memcg accounting off for RT in the problematic path.
Signed-off-by: Mike Galbraith <efa...@gmx.de&
) consequences.
LTP's madvise06 testcase triggers this quite well, and per gitk, the below
was the beginning of RT memcg woes.
58e698af4c63 radix-tree: account radix_tree_node to memory cgroup
Turn memcg accounting off for RT in the problematic path.
Signed-off-by: Mike Galbraith
Cc: stable
[ 84.088899] NOHZ: local_softirq_pending 02
[ 84.089463] NOHZ: local_softirq_pending 02
[ 115.013470] NOHZ: local_softirq_pending 02
[ 115.013601] NOHZ: local_softirq_pending 02
[ 115.013709] NOHZ: local_softirq_pending 02
Signed-off-by: Mike Galbraith <efa...@gmx.de>
---
kernel/sof
[ 84.088899] NOHZ: local_softirq_pending 02
[ 84.089463] NOHZ: local_softirq_pending 02
[ 115.013470] NOHZ: local_softirq_pending 02
[ 115.013601] NOHZ: local_softirq_pending 02
[ 115.013709] NOHZ: local_softirq_pending 02
Signed-off-by: Mike Galbraith
---
kernel/softirq.c | 10
On Thu, 2016-12-29 at 21:47 -0500, Dave Jones wrote:
> This is a new one for me..
>
> =
> [ BUG: bad unlock balance detected! ]
> 4.10.0-rc1-think+ #8 Not tainted
> -
> trinity-c47/31138 is trying to release lock (
> [CONT
On Thu, 2016-12-29 at 21:47 -0500, Dave Jones wrote:
> This is a new one for me..
>
> =
> [ BUG: bad unlock balance detected! ]
> 4.10.0-rc1-think+ #8 Not tainted
> -
> trinity-c47/31138 is trying to release lock (
> [CONT
Shamelessly steal softirq.c thread initialization method.
Signed-off-by: Mike Galbraith <efa...@gmx.de>
---
include/linux/cpuhotplug.h |1
kernel/time/posix-cpu-timers.c | 158 ++---
2 files changed, 56 insertions(+), 103 deletions(-)
--- a/i
Shamelessly steal softirq.c thread initialization method.
Signed-off-by: Mike Galbraith
---
include/linux/cpuhotplug.h |1
kernel/time/posix-cpu-timers.c | 158 ++---
2 files changed, 56 insertions(+), 103 deletions(-)
--- a/include/linux
614326] [] entry_SYSCALL_64_fastpath+0x1f/0xc2
Signed-off-by: Mike Galbraith <efa...@gmx.de>
---
arch/x86/include/asm/kvm_host.h |2 +-
arch/x86/kvm/x86.c | 20 ++--
2 files changed, 11 insertions(+), 11 deletions(-)
--- a/arch/x86/include/asm/kvm_host.h
++
614326] [] entry_SYSCALL_64_fastpath+0x1f/0xc2
Signed-off-by: Mike Galbraith
---
arch/x86/include/asm/kvm_host.h |2 +-
arch/x86/kvm/x86.c | 20 ++--
2 files changed, 11 insertions(+), 11 deletions(-)
--- a/arch/x86/include/asm/kvm_host.h
+++ b/arch/x86/inclu
On Fri, 2016-12-16 at 16:35 +0100, Michal Hocko wrote:
> On Fri 16-12-16 16:05:58, Mike Galbraith wrote:
> > On Thu, 2016-12-15 at 15:07 +0100, Michal Hocko wrote:
> > > Hi,
> > > I have posted the previous version here [1]. Since then I have added a
> > >
On Fri, 2016-12-16 at 16:35 +0100, Michal Hocko wrote:
> On Fri 16-12-16 16:05:58, Mike Galbraith wrote:
> > On Thu, 2016-12-15 at 15:07 +0100, Michal Hocko wrote:
> > > Hi,
> > > I have posted the previous version here [1]. Since then I have added a
> > >
On Thu, 2016-12-15 at 15:07 +0100, Michal Hocko wrote:
> Hi,
> I have posted the previous version here [1]. Since then I have added a
> support to suppress reclaim lockdep warnings (__GFP_NOLOCKDEP) to allow
> removing GFP_NOFS usage motivated by the lockdep false positives. On top
> of that I've
On Thu, 2016-12-15 at 15:07 +0100, Michal Hocko wrote:
> Hi,
> I have posted the previous version here [1]. Since then I have added a
> support to suppress reclaim lockdep warnings (__GFP_NOLOCKDEP) to allow
> removing GFP_NOFS usage motivated by the lockdep false positives. On top
> of that I've
There's a FIXME there, but seems you may still want to hear about it,
so here ya go.
[4.481803] [drm] Initialized
[4.600103] [drm] Memory usable by graphics device = 4096M
[4.600108] checking generic (c000 1d5000) vs hw (c000 1000)
[4.600109] fb: switching to
There's a FIXME there, but seems you may still want to hear about it,
so here ya go.
[4.481803] [drm] Initialized
[4.600103] [drm] Memory usable by graphics device = 4096M
[4.600108] checking generic (c000 1d5000) vs hw (c000 1000)
[4.600109] fb: switching to
Grumpy master.today, w. tune for maximum bloat PREEMPT config.
[ 101.898909] ===
[ 101.898910] [ INFO: suspicious RCU usage. ]
[ 101.898912] 4.10.0-preempt #1 Tainted: GE
[ 101.898913] ---
[ 101.898914]
Grumpy master.today, w. tune for maximum bloat PREEMPT config.
[ 101.898909] ===
[ 101.898910] [ INFO: suspicious RCU usage. ]
[ 101.898912] 4.10.0-preempt #1 Tainted: GE
[ 101.898913] ---
[ 101.898914]
On Tue, 2016-11-29 at 10:10 +0100, Michael Kerrisk (man-pages) wrote:
> Let's try and go further. How's this:
>
>When scheduling non-real-time processes (i.e., those scheduled
>under the SCHED_OTHER, SCHED_BATCH, and SCHED_IDLE policies), the
>CFS scheduler employs a
On Tue, 2016-11-29 at 10:10 +0100, Michael Kerrisk (man-pages) wrote:
> Let's try and go further. How's this:
>
>When scheduling non-real-time processes (i.e., those scheduled
>under the SCHED_OTHER, SCHED_BATCH, and SCHED_IDLE policies), the
>CFS scheduler employs a
On Sun, 2016-11-27 at 22:13 +0100, Michael Kerrisk (man-pages) wrote:
> Here's my attempt to define the root task group:
>
>* If autogrouping is disabled, then all processes in the root CPU
> cgroup form a scheduling group (sometimes called the "root task
> group").
On Sun, 2016-11-27 at 22:13 +0100, Michael Kerrisk (man-pages) wrote:
> Here's my attempt to define the root task group:
>
>* If autogrouping is disabled, then all processes in the root CPU
> cgroup form a scheduling group (sometimes called the "root task
> group").
On Fri, 2016-11-25 at 16:04 +0100, Michael Kerrisk (man-pages) wrote:
> > >┌─┐
> > >│FIXME│
> > >├─┤
> > >│How do
On Fri, 2016-11-25 at 16:04 +0100, Michael Kerrisk (man-pages) wrote:
> > >┌─┐
> > >│FIXME│
> > >├─┤
> > >│How do
On Thu, 2016-11-24 at 22:41 +0100, Michael Kerrisk (man-pages) wrote:
>Suppose that there are two autogroups competing for the same
>CPU. The first group contains ten CPU-bound processes from a
>kernel build started with make -j10. The other contains a sin‐
>
On Thu, 2016-11-24 at 22:41 +0100, Michael Kerrisk (man-pages) wrote:
>Suppose that there are two autogroups competing for the same
>CPU. The first group contains ten CPU-bound processes from a
>kernel build started with make -j10. The other contains a sin‐
>
Commit-ID: 83929cce95251cc77e5659bf493bd424ae0e7a67
Gitweb: http://git.kernel.org/tip/83929cce95251cc77e5659bf493bd424ae0e7a67
Author: Mike Galbraith <efa...@gmx.de>
AuthorDate: Wed, 23 Nov 2016 11:33:37 +0100
Committer: Ingo Molnar <mi...@kernel.org>
CommitDate: Thu, 24 No
Commit-ID: 83929cce95251cc77e5659bf493bd424ae0e7a67
Gitweb: http://git.kernel.org/tip/83929cce95251cc77e5659bf493bd424ae0e7a67
Author: Mike Galbraith
AuthorDate: Wed, 23 Nov 2016 11:33:37 +0100
Committer: Ingo Molnar
CommitDate: Thu, 24 Nov 2016 05:45:02 +0100
sched/autogroup: Fix 64
On Wed, 2016-11-23 at 17:05 +0100, Michael Kerrisk (man-pages) wrote:
> > I don't think we need group scheduling details, there's plenty of
> > documentation elsewhere for those who want theory.
>
> Actually, which documentation were you referring to here?
Documentation/scheduler/*
On Wed, 2016-11-23 at 17:05 +0100, Michael Kerrisk (man-pages) wrote:
> > I don't think we need group scheduling details, there's plenty of
> > documentation elsewhere for those who want theory.
>
> Actually, which documentation were you referring to here?
Documentation/scheduler/*
On Wed, 2016-11-23 at 17:04 +0100, Michael Kerrisk (man-pages) wrote:
> > > In what circumstances does a process get moved back to the root
> > > task group?
> >
> > Userspace actions, tool or human fingers.
>
> Could you say a little more please. What Kernel-user-space
> APIs/system
On Wed, 2016-11-23 at 17:04 +0100, Michael Kerrisk (man-pages) wrote:
> > > In what circumstances does a process get moved back to the root
> > > task group?
> >
> > Userspace actions, tool or human fingers.
>
> Could you say a little more please. What Kernel-user-space
> APIs/system
On Wed, 2016-11-23 at 15:20 +0100, Michael Kerrisk (man-pages) wrote:
> Thanks for the confirmation. Are you aiming to see the fix
> merged for 4.9, or will this wait for 4.10?
Dunno, that's up to Peter/Ingo. It's unlikely that anyone other than
we two will notice a thing either way :)
On Wed, 2016-11-23 at 15:20 +0100, Michael Kerrisk (man-pages) wrote:
> Thanks for the confirmation. Are you aiming to see the fix
> merged for 4.9, or will this wait for 4.10?
Dunno, that's up to Peter/Ingo. It's unlikely that anyone other than
we two will notice a thing either way :)
On Wed, 2016-11-23 at 14:54 +0100, Michael Kerrisk (man-pages) wrote:
> Hi Mike,
>
> First off, I better say that I'm not at all intimate with the details
> of the scheduler, so bear with me...
>
> On 11/23/2016 12:39 PM, Mike Galbraith wrote:
> > On Tue, 2016-11-22
On Wed, 2016-11-23 at 14:54 +0100, Michael Kerrisk (man-pages) wrote:
> Hi Mike,
>
> First off, I better say that I'm not at all intimate with the details
> of the scheduler, so bear with me...
>
> On 11/23/2016 12:39 PM, Mike Galbraith wrote:
> > On Tue, 2016-11-22
On Wed, 2016-11-23 at 14:47 +0100, Michael Kerrisk (man-pages) wrote:
> Hello Mike,
>
> On 11/23/2016 11:33 AM, Mike Galbraith wrote:
> > On Tue, 2016-11-22 at 16:59 +0100, Michael Kerrisk (man-p
On Wed, 2016-11-23 at 14:47 +0100, Michael Kerrisk (man-pages) wrote:
> Hello Mike,
>
> On 11/23/2016 11:33 AM, Mike Galbraith wrote:
> > On Tue, 2016-11-22 at 16:59 +0100, Michael Kerrisk (man-p
On Tue, 2016-11-22 at 16:59 +0100, Michael Kerrisk (man-pages) wrote:
>┌─┐
>│FIXME│
>├─┤
>│The following is a
On Tue, 2016-11-22 at 16:59 +0100, Michael Kerrisk (man-pages) wrote:
>┌─┐
>│FIXME│
>├─┤
>│The following is a
en ever since load
resolution was increased for 64bit kernels. Use scale_load() to
scale group weight.
Signed-off-by: Mike Galbraith <umgwanakikb...@gmail.com>
Reported-by: Michael Kerrisk <mtk.manpa...@gmail.com>
Cc: sta...@vger.kernel.org
---
kernel/sched/auto_group.c |4 +++-
1 fi
en ever since load
resolution was increased for 64bit kernels. Use scale_load() to
scale group weight.
Signed-off-by: Mike Galbraith
Reported-by: Michael Kerrisk
Cc: sta...@vger.kernel.org
---
kernel/sched/auto_group.c |4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
--- a/kernel/sched/
dynamic enable/disable capability either has become, or
perhaps always was racy. Rip it all out, leaving only commandline disable.
Signed-off-by: Mike Galbraith <umgwanakikb...@gmail.com>
---
fs/proc/base.c | 34 ---
include/linux/sched/sysctl.h |4 --
dynamic enable/disable capability either has become, or
perhaps always was racy. Rip it all out, leaving only commandline disable.
Signed-off-by: Mike Galbraith
---
fs/proc/base.c | 34 ---
include/linux/sched/sysctl.h |4 ---
kernel/sched/
On Wed, 2016-11-09 at 18:50 +0100, Peter Zijlstra wrote:
> On Wed, Nov 09, 2016 at 05:59:33PM +0100, Oleg Nesterov wrote:
>
> > We need to ensure that autogroup/tg returned by autogroup_task_group()
> > can't go away if we race with autogroup_move_group(), and unless the
> > caller holds
On Wed, 2016-11-09 at 18:50 +0100, Peter Zijlstra wrote:
> On Wed, Nov 09, 2016 at 05:59:33PM +0100, Oleg Nesterov wrote:
>
> > We need to ensure that autogroup/tg returned by autogroup_task_group()
> > can't go away if we race with autogroup_move_group(), and unless the
> > caller holds
On Tue, 2016-10-25 at 08:25 -0500, Rob Herring wrote:
> On Tue, Oct 25, 2016 at 7:55 AM, Mike Galbraith
> <umgwanakikb...@gmail.com> wrote:
> > On Tue, 2016-10-25 at 12:40 +0200, Geert Uytterhoeven wrote:
> >
> > > Mike: I see you are using a PC, whil
On Tue, 2016-10-25 at 08:25 -0500, Rob Herring wrote:
> On Tue, Oct 25, 2016 at 7:55 AM, Mike Galbraith
> wrote:
> > On Tue, 2016-10-25 at 12:40 +0200, Geert Uytterhoeven wrote:
> >
> > > Mike: I see you are using a PC, while I'm using an ARM board (with DT).
> >
On Tue, 2016-10-25 at 12:40 +0200, Geert Uytterhoeven wrote:
> Mike: I see you are using a PC, while I'm using an ARM board (with DT).
> Are you using a serial console? If yes, what's the value of port->console
> before and after the call to uart_console() that Rob's patch below removes?
Well,
On Tue, 2016-10-25 at 12:40 +0200, Geert Uytterhoeven wrote:
> Mike: I see you are using a PC, while I'm using an ARM board (with DT).
> Are you using a serial console? If yes, what's the value of port->console
> before and after the call to uart_console() that Rob's patch below removes?
Well,
On Mon, 2016-10-24 at 17:28 +0200, Jiri Slaby wrote:
On 10/24/2016, 04:48 PM, Borislav Petkov wrote:
> Hi people,
>
> typing "reboot" splats the following on the serial console. Ideas?
>
> INIT: Sending p[ 427.863916] BUG: unable to handle kernel NULL pointer
> dereference at 01e0
On Mon, 2016-10-24 at 17:28 +0200, Jiri Slaby wrote:
On 10/24/2016, 04:48 PM, Borislav Petkov wrote:
> Hi people,
>
> typing "reboot" splats the following on the serial console. Ideas?
>
> INIT: Sending p[ 427.863916] BUG: unable to handle kernel NULL pointer
> dereference at 01e0
On Mon, 2016-10-24 at 16:48 +0200, Borislav Petkov wrote:
> Hi people,
>
> typing "reboot" splats the following on the serial console. Ideas?
Very familiar, I bisected that to 761ed4a94582. Workaround for the
nonce is to comment out..
port->console = uart_console(uport);
..in
On Mon, 2016-10-24 at 16:48 +0200, Borislav Petkov wrote:
> Hi people,
>
> typing "reboot" splats the following on the serial console. Ideas?
Very familiar, I bisected that to 761ed4a94582. Workaround for the
nonce is to comment out..
port->console = uart_console(uport);
..in
On Fri, 2016-10-21 at 10:00 -0500, Rob Herring wrote:
> On Fri, Oct 21, 2016 at 9:40 AM, Mike Galbraith
> <umgwanakikb...@gmail.com> wrote:
> > On Fri, 2016-10-21 at 08:51 -0500, Rob Herring wrote:
> > > On Fri, Oct 21, 2016 at 7:45 AM, Mike Galbraith
> > &
On Fri, 2016-10-21 at 10:00 -0500, Rob Herring wrote:
> On Fri, Oct 21, 2016 at 9:40 AM, Mike Galbraith
> wrote:
> > On Fri, 2016-10-21 at 08:51 -0500, Rob Herring wrote:
> > > On Fri, Oct 21, 2016 at 7:45 AM, Mike Galbraith
> > > wrote:
> > > > G
On Fri, 2016-10-21 at 10:00 -0500, Rob Herring wrote:
> On Fri, Oct 21, 2016 at 9:40 AM, Mike Galbraith
> <umgwanakikb...@gmail.com> wrote:
> > On Fri, 2016-10-21 at 08:51 -0500, Rob Herring wrote:
> > > On Fri, Oct 21, 2016 at 7:45 AM, Mike Galbraith
> > &
On Fri, 2016-10-21 at 10:00 -0500, Rob Herring wrote:
> On Fri, Oct 21, 2016 at 9:40 AM, Mike Galbraith
> wrote:
> > On Fri, 2016-10-21 at 08:51 -0500, Rob Herring wrote:
> > > On Fri, Oct 21, 2016 at 7:45 AM, Mike Galbraith
> > > wrote:
> > > > G
On Fri, 2016-10-21 at 08:51 -0500, Rob Herring wrote:
> On Fri, Oct 21, 2016 at 7:45 AM, Mike Galbraith
> <umgwanakikb...@gmail.com> wrote:
> > Greetings,
> >
> > My old DL980 G7 is exploding on reboot with master, with only the first
> > couple lines actu
On Fri, 2016-10-21 at 08:51 -0500, Rob Herring wrote:
> On Fri, Oct 21, 2016 at 7:45 AM, Mike Galbraith
> wrote:
> > Greetings,
> >
> > My old DL980 G7 is exploding on reboot with master, with only the first
> > couple lines actually making it to the console. O
Greetings,
My old DL980 G7 is exploding on reboot with master, with only the first
couple lines actually making it to the console. Once (and only once)
during bisection it did manage to get the below emitted.
[ 358.315713] BUG: unable to handle kernel NULL pointer dereference at
Greetings,
My old DL980 G7 is exploding on reboot with master, with only the first
couple lines actually making it to the console. Once (and only once)
during bisection it did manage to get the below emitted.
[ 358.315713] BUG: unable to handle kernel NULL pointer dereference at
896941] [] ?
smpboot_update_cpumask_percpu_thread+0x130/0x130
[ 634.896942] [] kthread+0xef/0x110
[ 634.896944] [] ret_from_fork+0x1f/0x40
[ 634.896945] [] ? kthread_park+0x60/0x60
[ 634.896970] smpboot: CPU 6 is now offline
Signed-off-by: Mike Galbraith <umgwanakikb...@gmail.com>
---
kernel/sched/core.c |
896941] [] ?
smpboot_update_cpumask_percpu_thread+0x130/0x130
[ 634.896942] [] kthread+0xef/0x110
[ 634.896944] [] ret_from_fork+0x1f/0x40
[ 634.896945] [] ? kthread_park+0x60/0x60
[ 634.896970] smpboot: CPU 6 is now offline
Signed-off-by: Mike Galbraith
---
kernel/sched/core.c |3 +++
1 file changed, 3 inse
On Wed, 2016-10-19 at 18:54 +0200, Sebastian Andrzej Siewior wrote:
> On 2016-10-19 17:56:30 [+0200], Mike Galbraith wrote:
> > In v4.7, the driver switched to percpu compression streams, disabling
> > preemption vai get/put_cpu_ptr(). Use a local lock instead for RT.
> >
On Wed, 2016-10-19 at 18:54 +0200, Sebastian Andrzej Siewior wrote:
> On 2016-10-19 17:56:30 [+0200], Mike Galbraith wrote:
> > In v4.7, the driver switched to percpu compression streams, disabling
> > preemption vai get/put_cpu_ptr(). Use a local lock instead for RT.
> >
On Mon, 2016-10-17 at 16:24 +0200, Sebastian Andrzej Siewior wrote:
> On 2016-10-16 05:14:22 [+0200], Mike Galbraith wrote:
> >
> > In v4.7, the driver switched to percpu compression streams, disabling
> > preemption (get/put_cpu_ptr()). Use get/put_cpu_light() instead.
&g
On Mon, 2016-10-17 at 16:24 +0200, Sebastian Andrzej Siewior wrote:
> On 2016-10-16 05:14:22 [+0200], Mike Galbraith wrote:
> >
> > In v4.7, the driver switched to percpu compression streams, disabling
> > preemption (get/put_cpu_ptr()). Use get/put_cpu_light() instead.
&g
take it...
Signed-off-by: Mike Galbraith <umgwanakikb...@gmail.com>
---
mm/zsmalloc.c | 31 +--
1 file changed, 17 insertions(+), 14 deletions(-)
--- a/mm/zsmalloc.c
+++ b/mm/zsmalloc.c
@@ -71,18 +71,20 @@
#define ZS_MAX_ZSPAGE_ORDER 2
#
take it...
Signed-off-by: Mike Galbraith
---
mm/zsmalloc.c | 31 +--
1 file changed, 17 insertions(+), 14 deletions(-)
--- a/mm/zsmalloc.c
+++ b/mm/zsmalloc.c
@@ -71,18 +71,20 @@
#define ZS_MAX_ZSPAGE_ORDER 2
#define ZS_MAX_PAGES_PER_ZSPAGE (_AC(1, UL
On Tue, 2016-10-18 at 15:40 +0200, Igor Mammedov wrote:
> kernel crashes at runtime due null pointer dereference at
> select_idle_sibling()
> -> select_idle_cpu()
> ...
> u64 avg_cost = this_sd->avg_scan_cost;
>
> regression bisects to:
> commit
On Tue, 2016-10-18 at 15:40 +0200, Igor Mammedov wrote:
> kernel crashes at runtime due null pointer dereference at
> select_idle_sibling()
> -> select_idle_cpu()
> ...
> u64 avg_cost = this_sd->avg_scan_cost;
>
> regression bisects to:
> commit
1301 - 1400 of 5828 matches
Mail list logo
