Re: 9908859acaa9 cpuidle/menu: add per CPU PM QoS resume latency consideration

On Wed, 2017-02-22 at 14:12 +0100, Peter Zijlstra wrote: > On Wed, Feb 22, 2017 at 01:56:37PM +0100, Mike Galbraith wrote: > > Hi, > > > > Do we really need a spinlock for that in the idle loop? > > Urgh, that's broken on RT, you cannot schedule the idle loop.

Re: 9908859acaa9 cpuidle/menu: add per CPU PM QoS resume latency consideration

On Wed, 2017-02-22 at 14:12 +0100, Peter Zijlstra wrote: > On Wed, Feb 22, 2017 at 01:56:37PM +0100, Mike Galbraith wrote: > > Hi, > > > > Do we really need a spinlock for that in the idle loop? > > Urgh, that's broken on RT, you cannot schedule the idle loop.

9908859acaa9 cpuidle/menu: add per CPU PM QoS resume latency consideration

Hi, Do we really need a spinlock for that in the idle loop? -Mike

9908859acaa9 cpuidle/menu: add per CPU PM QoS resume latency consideration

Hi, Do we really need a spinlock for that in the idle loop? -Mike

Re: [bisection] b0119e87083 iommu: Introduce new 'struct iommu_device' ==> boom

On Tue, 2017-02-21 at 16:19 +0100, Joerg Roedel wrote: > Hi Mike, > > thanks for the report, this didn't trigger in my local testing here. > Loosk like I need to test without intel_iommu=on too :/ > > Anyway, can you check whether the attached patch helps? Yup, boots. > diff --git

Re: [bisection] b0119e87083 iommu: Introduce new 'struct iommu_device' ==> boom

On Tue, 2017-02-21 at 16:19 +0100, Joerg Roedel wrote: > Hi Mike, > > thanks for the report, this didn't trigger in my local testing here. > Loosk like I need to test without intel_iommu=on too :/ > > Anyway, can you check whether the attached patch helps? Yup, boots. > diff --git

[bisection] b0119e87083 iommu: Introduce new 'struct iommu_device' ==> boom

4x18 box (berio) explodes as below after morning master pull. BIOS has a couple issues, maybe one of them.. helps. [ 30.796530] ima: No TPM chip found, activating TPM-bypass! (rc=-19) [ 30.810709] evm: HMAC attrs: 0x1 [ 30.821200] BUG: unable to handle kernel NULL pointer dereference at

[bisection] b0119e87083 iommu: Introduce new 'struct iommu_device' ==> boom

4x18 box (berio) explodes as below after morning master pull. BIOS has a couple issues, maybe one of them.. helps. [ 30.796530] ima: No TPM chip found, activating TPM-bypass! (rc=-19) [ 30.810709] evm: HMAC attrs: 0x1 [ 30.821200] BUG: unable to handle kernel NULL pointer dereference at

[cgroups] suspicious rcu_dereference_check() usage!

Running LTP on master.today (v4.10) with a seriously bloated PREEMPT config inspired box to emit the below. [ 7160.458996] === [ 7160.463195] [ INFO: suspicious RCU usage. ] [ 7160.467387] 4.10.0-default #100 Tainted: GE [ 7160.472808]

[cgroups] suspicious rcu_dereference_check() usage!

Running LTP on master.today (v4.10) with a seriously bloated PREEMPT config inspired box to emit the below. [ 7160.458996] === [ 7160.463195] [ INFO: suspicious RCU usage. ] [ 7160.467387] 4.10.0-default #100 Tainted: GE [ 7160.472808]

[btrfs] lockdep splat

Greetings, Running ltp on master.today, I received the splat (from hell) below. [ 5015.128458] = [ 5015.128458] [ INFO: possible irq lock inversion dependency detected ] [ 5015.128458] 4.10.0-default #119 Tainted: GE [

[btrfs] lockdep splat

Greetings, Running ltp on master.today, I received the splat (from hell) below. [ 5015.128458] = [ 5015.128458] [ INFO: possible irq lock inversion dependency detected ] [ 5015.128458] 4.10.0-default #119 Tainted: GE [

Re: [RT] lockdep munching nr_list_entries like popcorn

On Thu, 2017-02-16 at 19:06 +0100, Mike Galbraith wrote: > On Thu, 2017-02-16 at 15:53 +0100, Sebastian Andrzej Siewior wrote: > > On 2017-02-16 15:42:59 [+0100], Mike Galbraith wrote: > > > > > > Weeell, I'm trying to cobble something kinda like that together using

Re: [RT] lockdep munching nr_list_entries like popcorn

On Thu, 2017-02-16 at 19:06 +0100, Mike Galbraith wrote: > On Thu, 2017-02-16 at 15:53 +0100, Sebastian Andrzej Siewior wrote: > > On 2017-02-16 15:42:59 [+0100], Mike Galbraith wrote: > > > > > > Weeell, I'm trying to cobble something kinda like that together using

Re: [RT] lockdep munching nr_list_entries like popcorn

BTW, this ain't gone. I'll take a peek. It doesn't happen in my tree, seems likely to be because whether running sirqs fully threaded or not, I don't let one any thread handle what another exists to handle. [ 638.107293] NOHZ: local_softirq_pending 80 [ 939.729684] NOHZ:

Re: [RT] lockdep munching nr_list_entries like popcorn

BTW, this ain't gone. I'll take a peek. It doesn't happen in my tree, seems likely to be because whether running sirqs fully threaded or not, I don't let one any thread handle what another exists to handle. [ 638.107293] NOHZ: local_softirq_pending 80 [ 939.729684] NOHZ:

Re: [RT] lockdep munching nr_list_entries like popcorn

On Thu, 2017-02-16 at 15:53 +0100, Sebastian Andrzej Siewior wrote: > On 2017-02-16 15:42:59 [+0100], Mike Galbraith wrote: > > > > Weeell, I'm trying to cobble something kinda like that together using > > __RT_SPIN_INITIALIZER() instead, but seems mean

Re: [RT] lockdep munching nr_list_entries like popcorn

On Thu, 2017-02-16 at 15:53 +0100, Sebastian Andrzej Siewior wrote: > On 2017-02-16 15:42:59 [+0100], Mike Galbraith wrote: > > > > Weeell, I'm trying to cobble something kinda like that together using > > __RT_SPIN_INITIALIZER() instead, but seems mean

Re: [RT] lockdep munching nr_list_entries like popcorn

On Thu, 2017-02-16 at 12:06 +0100, Peter Zijlstra wrote: > On Thu, Feb 16, 2017 at 10:01:18AM +0100, Thomas Gleixner wrote: > > On Thu, 16 Feb 2017, Mike Galbraith wrote: > > > > > On Thu, 2017-02-16 at 09:37 +0100, Thomas Gleixner wrote: > > > > On Th

Re: [RT] lockdep munching nr_list_entries like popcorn

On Thu, 2017-02-16 at 12:06 +0100, Peter Zijlstra wrote: > On Thu, Feb 16, 2017 at 10:01:18AM +0100, Thomas Gleixner wrote: > > On Thu, 16 Feb 2017, Mike Galbraith wrote: > > > > > On Thu, 2017-02-16 at 09:37 +0100, Thomas Gleixner wrote: > > > > On Th

Re: [RT] lockdep munching nr_list_entries like popcorn

On Thu, 2017-02-16 at 10:01 +0100, Thomas Gleixner wrote: > On Thu, 16 Feb 2017, Mike Galbraith wrote: > > > On Thu, 2017-02-16 at 09:37 +0100, Thomas Gleixner wrote: > > > On Thu, 16 Feb 2017, Mike Galbraith wrote: > > > > > ... > > > > swapve

Re: [RT] lockdep munching nr_list_entries like popcorn

On Thu, 2017-02-16 at 10:01 +0100, Thomas Gleixner wrote: > On Thu, 16 Feb 2017, Mike Galbraith wrote: > > > On Thu, 2017-02-16 at 09:37 +0100, Thomas Gleixner wrote: > > > On Thu, 16 Feb 2017, Mike Galbraith wrote: > > > > > ... > > > > swapve

Re: [RT] lockdep munching nr_list_entries like popcorn

On Thu, 2017-02-16 at 09:37 +0100, Thomas Gleixner wrote: > On Thu, 16 Feb 2017, Mike Galbraith wrote: > ... > > swapvec_lock? Oodles of 'em? Nope. > > Well, it's a per cpu lock and the lru_cache_add() variants might be called > from a gazillion of different call cha

Re: [RT] lockdep munching nr_list_entries like popcorn

On Thu, 2017-02-16 at 09:37 +0100, Thomas Gleixner wrote: > On Thu, 16 Feb 2017, Mike Galbraith wrote: > ... > > swapvec_lock? Oodles of 'em? Nope. > > Well, it's a per cpu lock and the lru_cache_add() variants might be called > from a gazillion of different call cha

[RT] lockdep munching nr_list_entries like popcorn

4.9.10-rt6-virgin on 72 core +SMT box. Below is 1 line per minute, box idling along daintily nibbling, I fire up a parallel kbuild loop at 40465, and box gobbles greedily. I have entries bumped to 128k, and chain bits to 18 so box will get booted and run for a while before lockdep says "I quit".

[RT] lockdep munching nr_list_entries like popcorn

4.9.10-rt6-virgin on 72 core +SMT box. Below is 1 line per minute, box idling along daintily nibbling, I fire up a parallel kbuild loop at 40465, and box gobbles greedily. I have entries bumped to 128k, and chain bits to 18 so box will get booted and run for a while before lockdep says "I quit".

[tip:timers/urgent] tick/broadcast: Prevent deadlock on tick_broadcast_lock

Commit-ID: 202461e2f3c15dbfb05825d29ace0d20cdf55fa4 Gitweb: http://git.kernel.org/tip/202461e2f3c15dbfb05825d29ace0d20cdf55fa4 Author: Mike Galbraith <efa...@gmx.de> AuthorDate: Mon, 13 Feb 2017 03:31:55 +0100 Committer: Thomas Gleixner <t...@linutronix.de> CommitDate: Mon,

[tip:timers/urgent] tick/broadcast: Prevent deadlock on tick_broadcast_lock

Commit-ID: 202461e2f3c15dbfb05825d29ace0d20cdf55fa4 Gitweb: http://git.kernel.org/tip/202461e2f3c15dbfb05825d29ace0d20cdf55fa4 Author: Mike Galbraith AuthorDate: Mon, 13 Feb 2017 03:31:55 +0100 Committer: Thomas Gleixner CommitDate: Mon, 13 Feb 2017 09:49:31 +0100 tick/broadcast

Re: [PATCHSET for-4.11] cgroup: implement cgroup v2 thread mode

On Sun, 2017-02-12 at 07:59 +0100, Mike Galbraith wrote: > On Sun, 2017-02-12 at 14:05 +0900, Tejun Heo wrote: > > > > I think cgroup tree depth is a more significant issue; because of > > > hierarchy we often do tree walks (uo-to-root or down-to-task). > > >

Re: [PATCHSET for-4.11] cgroup: implement cgroup v2 thread mode

On Sun, 2017-02-12 at 07:59 +0100, Mike Galbraith wrote: > On Sun, 2017-02-12 at 14:05 +0900, Tejun Heo wrote: > > > > I think cgroup tree depth is a more significant issue; because of > > > hierarchy we often do tree walks (uo-to-root or down-to-task). > > >

Re: [PATCHSET for-4.11] cgroup: implement cgroup v2 thread mode

On Sun, 2017-02-12 at 13:16 -0800, Paul Turner wrote: > > > On Thursday, February 9, 2017, Peter Zijlstra wrote: > > On Thu, Feb 09, 2017 at 05:07:16AM -0800, Paul Turner wrote: > > > The only case that this does not support vs ".threads" would be some > > > hybrid where

Re: [PATCHSET for-4.11] cgroup: implement cgroup v2 thread mode

On Sun, 2017-02-12 at 13:16 -0800, Paul Turner wrote: > > > On Thursday, February 9, 2017, Peter Zijlstra wrote: > > On Thu, Feb 09, 2017 at 05:07:16AM -0800, Paul Turner wrote: > > > The only case that this does not support vs ".threads" would be some > > > hybrid where we co-mingle threads

Re: Linux 4.9.6 ( Restore IO-APIC irq_chip retrigger callback , breaks my box )

[ 12.703757] kthread+0x10c/0x140 [ 12.703759] ? smpboot_update_cpumask_percpu_thread+0x130/0x130 [ 12.703760] ? kthread_park+0x90/0x90 [ 12.703762] ret_from_fork+0x2a/0x40 [ 12.709790] intel_idle: lapic_timer_reliable_states 0x2 Signed-off-by: Mike Galbraith <efa...@gmx.de> --- kernel/

Re: Linux 4.9.6 ( Restore IO-APIC irq_chip retrigger callback , breaks my box )

[ 12.703757] kthread+0x10c/0x140 [ 12.703759] ? smpboot_update_cpumask_percpu_thread+0x130/0x130 [ 12.703760] ? kthread_park+0x90/0x90 [ 12.703762] ret_from_fork+0x2a/0x40 [ 12.709790] intel_idle: lapic_timer_reliable_states 0x2 Signed-off-by: Mike Galbraith --- kernel/time/tick-broadca

Re: [PATCHSET for-4.11] cgroup: implement cgroup v2 thread mode

On Sun, 2017-02-12 at 14:05 +0900, Tejun Heo wrote: > > I think cgroup tree depth is a more significant issue; because of > > hierarchy we often do tree walks (uo-to-root or down-to-task). > > > > So creating elaborate trees is something I try not to do. > > So, as long as the depth stays

Re: [PATCHSET for-4.11] cgroup: implement cgroup v2 thread mode

On Sun, 2017-02-12 at 14:05 +0900, Tejun Heo wrote: > > I think cgroup tree depth is a more significant issue; because of > > hierarchy we often do tree walks (uo-to-root or down-to-task). > > > > So creating elaborate trees is something I try not to do. > > So, as long as the depth stays

Re: [PATCH 2/2] sched/deadline: Throttle a constrained deadline task activated after the deadline

On Sat, 2017-02-11 at 08:15 +0100, luca abeni wrote: > Hi Daniel, > > On Fri, 10 Feb 2017 20:48:11 +0100 > Daniel Bristot de Oliveira wrote: > > > During the activation, CBS checks if it can reuse the current > > task's > > runtime and period. If the deadline of the task is

Re: [PATCH 2/2] sched/deadline: Throttle a constrained deadline task activated after the deadline

On Sat, 2017-02-11 at 08:15 +0100, luca abeni wrote: > Hi Daniel, > > On Fri, 10 Feb 2017 20:48:11 +0100 > Daniel Bristot de Oliveira wrote: > > > During the activation, CBS checks if it can reuse the current > > task's > > runtime and period. If the deadline of the task is in the past, CBS > >

Re: [GIT pull] x86/timers for 4.10

On Thu, 2017-02-09 at 16:21 +0100, Thomas Gleixner wrote: > On Thu, 9 Feb 2017, Mike Galbraith wrote: > > > On Thu, 2017-02-09 at 16:07 +0100, Thomas Gleixner wrote: > > > On Wed, 8 Feb 2017, Mike Galbraith wrote: > > > > On Wed, 2017-02-08 at 12:44 +0100, Thomas

Re: [GIT pull] x86/timers for 4.10

On Thu, 2017-02-09 at 16:21 +0100, Thomas Gleixner wrote: > On Thu, 9 Feb 2017, Mike Galbraith wrote: > > > On Thu, 2017-02-09 at 16:07 +0100, Thomas Gleixner wrote: > > > On Wed, 8 Feb 2017, Mike Galbraith wrote: > > > > On Wed, 2017-02-08 at 12:44 +0100, Thomas

Re: [GIT pull] x86/timers for 4.10

On Thu, 2017-02-09 at 16:07 +0100, Thomas Gleixner wrote: > On Wed, 8 Feb 2017, Mike Galbraith wrote: > > On Wed, 2017-02-08 at 12:44 +0100, Thomas Gleixner wrote: > > > On Mon, 6 Feb 2017, Olof Johansson wrote: > > > > [0.177102] [Firmware Bug]: TSC

Re: [GIT pull] x86/timers for 4.10

On Thu, 2017-02-09 at 16:07 +0100, Thomas Gleixner wrote: > On Wed, 8 Feb 2017, Mike Galbraith wrote: > > On Wed, 2017-02-08 at 12:44 +0100, Thomas Gleixner wrote: > > > On Mon, 6 Feb 2017, Olof Johansson wrote: > > > > [0.177102] [Firmware Bug]: TSC

Re: [PATCHSET for-4.11] cgroup: implement cgroup v2 thread mode

On Thu, 2017-02-09 at 15:47 +0100, Peter Zijlstra wrote: > On Thu, Feb 09, 2017 at 05:07:16AM -0800, Paul Turner wrote: > > The only case that this does not support vs ".threads" would be some > > hybrid where we co-mingle threads from different processes (with the > > processes belonging to the

Re: [PATCHSET for-4.11] cgroup: implement cgroup v2 thread mode

On Thu, 2017-02-09 at 15:47 +0100, Peter Zijlstra wrote: > On Thu, Feb 09, 2017 at 05:07:16AM -0800, Paul Turner wrote: > > The only case that this does not support vs ".threads" would be some > > hybrid where we co-mingle threads from different processes (with the > > processes belonging to the

Re: [GIT pull] x86/timers for 4.10

On Wed, 2017-02-08 at 12:44 +0100, Thomas Gleixner wrote: > On Mon, 6 Feb 2017, Olof Johansson wrote: > > [0.177102] [Firmware Bug]: TSC ADJUST differs: Reference CPU0: > > -6495898515190607 CPU1: -6495898517158354 > > Yay, another "clever" BIOS Oh yeah, that reminds me... I met one

Re: [GIT pull] x86/timers for 4.10

On Wed, 2017-02-08 at 12:44 +0100, Thomas Gleixner wrote: > On Mon, 6 Feb 2017, Olof Johansson wrote: > > [0.177102] [Firmware Bug]: TSC ADJUST differs: Reference CPU0: > > -6495898515190607 CPU1: -6495898517158354 > > Yay, another "clever" BIOS Oh yeah, that reminds me... I met one

Re: [RFC,v2 3/3] sched: ignore task_h_load for CPU_NEWLY_IDLE

On Wed, 2017-02-08 at 09:43 +0100, Uladzislau Rezki wrote: > From: Uladzislau 2 Rezki > > A load balancer calculates imbalance factor for particular shed ^sched > domain and tries to steal up the

Re: [RFC,v2 3/3] sched: ignore task_h_load for CPU_NEWLY_IDLE

On Wed, 2017-02-08 at 09:43 +0100, Uladzislau Rezki wrote: > From: Uladzislau 2 Rezki > > A load balancer calculates imbalance factor for particular shed ^sched > domain and tries to steal up the prescribed amount of weighted load. >

Re: v4.9, 4.4-final: 28 bioset threads on small notebook, 36 threads on cellphone

On Tue, 2017-02-07 at 19:58 -0900, Kent Overstreet wrote: > On Tue, Feb 07, 2017 at 09:39:11PM +0100, Pavel Machek wrote: > > On Mon 2017-02-06 17:49:06, Kent Overstreet wrote: > > > On Mon, Feb 06, 2017 at 04:47:24PM -0900, Kent Overstreet wrote: > > > > On Mon, Feb 06, 2017 at 01:53:09PM +0100,

Re: v4.9, 4.4-final: 28 bioset threads on small notebook, 36 threads on cellphone

On Tue, 2017-02-07 at 19:58 -0900, Kent Overstreet wrote: > On Tue, Feb 07, 2017 at 09:39:11PM +0100, Pavel Machek wrote: > > On Mon 2017-02-06 17:49:06, Kent Overstreet wrote: > > > On Mon, Feb 06, 2017 at 04:47:24PM -0900, Kent Overstreet wrote: > > > > On Mon, Feb 06, 2017 at 01:53:09PM +0100,

Re: v4.9, 4.4-final: 28 bioset threads on small notebook, 36 threads on cellphone

On Tue, 2017-02-07 at 21:39 +0100, Pavel Machek wrote: > On Mon 2017-02-06 17:49:06, Kent Overstreet wrote: > > On Mon, Feb 06, 2017 at 04:47:24PM -0900, Kent Overstreet wrote: > > > On Mon, Feb 06, 2017 at 01:53:09PM +0100, Pavel Machek wrote: > > > > Still there on v4.9, 36 threads on nokia n900

Re: v4.9, 4.4-final: 28 bioset threads on small notebook, 36 threads on cellphone

On Tue, 2017-02-07 at 21:39 +0100, Pavel Machek wrote: > On Mon 2017-02-06 17:49:06, Kent Overstreet wrote: > > On Mon, Feb 06, 2017 at 04:47:24PM -0900, Kent Overstreet wrote: > > > On Mon, Feb 06, 2017 at 01:53:09PM +0100, Pavel Machek wrote: > > > > Still there on v4.9, 36 threads on nokia n900

Re: tip: demise of tsk_cpus_allowed() and tsk_nr_cpus_allowed()

On Mon, 2017-02-06 at 13:29 +0100, Ingo Molnar wrote: > * Mike Galbraith <efa...@gmx.de> wrote: > > > On Mon, 2017-02-06 at 11:31 +0100, Ingo Molnar wrote: > > > * Mike Galbraith <efa...@gmx.de> wrote: > > > > > > > Hi Ingo, > > &g

Re: tip: demise of tsk_cpus_allowed() and tsk_nr_cpus_allowed()

On Mon, 2017-02-06 at 13:29 +0100, Ingo Molnar wrote: > * Mike Galbraith wrote: > > > On Mon, 2017-02-06 at 11:31 +0100, Ingo Molnar wrote: > > > * Mike Galbraith wrote: > > > > > > > Hi Ingo, > > > > > > > > D

Re: tip: demise of tsk_cpus_allowed() and tsk_nr_cpus_allowed()

On Mon, 2017-02-06 at 11:31 +0100, Ingo Molnar wrote: > * Mike Galbraith <efa...@gmx.de> wrote: > > > Hi Ingo, > > > > Doing my ~daily tip merge of -rt, I couldn't help noticing $subject, as > > they grow more functionality in -rt, which is allegedly slowly bu

Re: tip: demise of tsk_cpus_allowed() and tsk_nr_cpus_allowed()

On Mon, 2017-02-06 at 11:31 +0100, Ingo Molnar wrote: > * Mike Galbraith wrote: > > > Hi Ingo, > > > > Doing my ~daily tip merge of -rt, I couldn't help noticing $subject, as > > they grow more functionality in -rt, which is allegedly slowly but > > surely h

tip: demise of tsk_cpus_allowed() and tsk_nr_cpus_allowed()

Hi Ingo, Doing my ~daily tip merge of -rt, I couldn't help noticing $subject, as they grow more functionality in -rt, which is allegedly slowly but surely headed toward merge. I don't suppose they could be left intact? I can easily restore them in my local tree, but it seems a bit of a shame to

tip: demise of tsk_cpus_allowed() and tsk_nr_cpus_allowed()

Hi Ingo, Doing my ~daily tip merge of -rt, I couldn't help noticing $subject, as they grow more functionality in -rt, which is allegedly slowly but surely headed toward merge. I don't suppose they could be left intact? I can easily restore them in my local tree, but it seems a bit of a shame to

Re: [tip:sched/core] sched/core: Add debugging code to catch missing update_rq_clock() calls

On Fri, 2017-02-03 at 14:37 +0100, Peter Zijlstra wrote: > On Fri, Feb 03, 2017 at 01:59:34PM +0100, Mike Galbraith wrote: > > FWIW, I'm not seeing stalls/hangs while beating hotplug up in tip. (so > > next grew a wart?) > > I've seen it on tip. It looks like hot unplug

Re: [tip:sched/core] sched/core: Add debugging code to catch missing update_rq_clock() calls

On Fri, 2017-02-03 at 14:37 +0100, Peter Zijlstra wrote: > On Fri, Feb 03, 2017 at 01:59:34PM +0100, Mike Galbraith wrote: > > FWIW, I'm not seeing stalls/hangs while beating hotplug up in tip. (so > > next grew a wart?) > > I've seen it on tip. It looks like hot unplug

x86-tip/master: Kernel panic - not syncing: snd_hda_codec_hdmi hdaudioC1D0: unrecoverable failure

On a lark, I tried a suspend/resume cycle after a bit of uneventful beating on cpu hotplug. Suspend worked fine, resume not so well. [ 1571.838698] Call Trace: [ 1571.838703] __schedule+0x32c/0xd10 [ 1571.838706] ? _raw_spin_unlock_irqrestore+0x36/0x60 [ 1571.838710] schedule+0x3d/0x90 [

x86-tip/master: Kernel panic - not syncing: snd_hda_codec_hdmi hdaudioC1D0: unrecoverable failure

On a lark, I tried a suspend/resume cycle after a bit of uneventful beating on cpu hotplug. Suspend worked fine, resume not so well. [ 1571.838698] Call Trace: [ 1571.838703] __schedule+0x32c/0xd10 [ 1571.838706] ? _raw_spin_unlock_irqrestore+0x36/0x60 [ 1571.838710] schedule+0x3d/0x90 [

Re: [tip:sched/core] sched/core: Add debugging code to catch missing update_rq_clock() calls

On Fri, 2017-02-03 at 09:53 +0100, Peter Zijlstra wrote: > On Fri, Feb 03, 2017 at 10:03:14AM +0530, Sachin Sant wrote: > > I ran few cycles of cpu hot(un)plug tests. In most cases it works except one > > where I ran into rcu stall: > > > > [ 173.493453] INFO: rcu_sched detected stalls on

Re: [tip:sched/core] sched/core: Add debugging code to catch missing update_rq_clock() calls

On Fri, 2017-02-03 at 09:53 +0100, Peter Zijlstra wrote: > On Fri, Feb 03, 2017 at 10:03:14AM +0530, Sachin Sant wrote: > > I ran few cycles of cpu hot(un)plug tests. In most cases it works except one > > where I ran into rcu stall: > > > > [ 173.493453] INFO: rcu_sched detected stalls on

[patch-tip] drivers/mtd: Apply sched include reorg to tests/mtd_test.h

signal_pending() moved to linux/sched/signal.h, go get it. Signed-off-by: Mike Galbraith <efa...@gmx.de> --- drivers/mtd/tests/mtd_test.h |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/drivers/mtd/tests/mtd_test.h +++ b/drivers/mtd/tests/mtd_test.h @@ -1,5 +1,5 @@ #i

[patch-tip] drivers/mtd: Apply sched include reorg to tests/mtd_test.h

signal_pending() moved to linux/sched/signal.h, go get it. Signed-off-by: Mike Galbraith --- drivers/mtd/tests/mtd_test.h |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/drivers/mtd/tests/mtd_test.h +++ b/drivers/mtd/tests/mtd_test.h @@ -1,5 +1,5 @@ #include -#include

Re: [tip:sched/core] sched/core: Add debugging code to catch missing update_rq_clock() calls

On Thu, 2017-02-02 at 16:55 +0100, Peter Zijlstra wrote: > On Tue, Jan 31, 2017 at 10:22:47AM -0700, Ross Zwisler wrote: > > On Tue, Jan 31, 2017 at 4:48 AM, Mike Galbraith <efa...@gmx.de> > > wrote: > > > On Tue, 2017-01-31 at 16:30 +0530, Sachin Sant wrote:

Re: [tip:sched/core] sched/core: Add debugging code to catch missing update_rq_clock() calls

On Thu, 2017-02-02 at 16:55 +0100, Peter Zijlstra wrote: > On Tue, Jan 31, 2017 at 10:22:47AM -0700, Ross Zwisler wrote: > > On Tue, Jan 31, 2017 at 4:48 AM, Mike Galbraith > > wrote: > > > On Tue, 2017-01-31 at 16:30 +0530, Sachin Sant wrote: > > > Could some o

Re: [PATCH] x86/microcode: Do not access the initrd after it has been freed

On Tue, 2017-01-31 at 18:49 +0100, Borislav Petkov wrote: > On Tue, Jan 31, 2017 at 01:31:00PM +0100, Borislav Petkov wrote: > > On Tue, Jan 31, 2017 at 12:31:17PM +0100, Mike Galbraith wrote: > > > (bisect fingered irqdomain: Avoid activating interrupts more than once) >

Re: [PATCH] x86/microcode: Do not access the initrd after it has been freed

On Tue, 2017-01-31 at 18:49 +0100, Borislav Petkov wrote: > On Tue, Jan 31, 2017 at 01:31:00PM +0100, Borislav Petkov wrote: > > On Tue, Jan 31, 2017 at 12:31:17PM +0100, Mike Galbraith wrote: > > > (bisect fingered irqdomain: Avoid activating interrupts more than once) >

Re: [tip:sched/core] sched/core: Add debugging code to catch missing update_rq_clock() calls

On Tue, 2017-01-31 at 16:30 +0530, Sachin Sant wrote: > Trimming the cc list. > > > > I assume I should be worried? > > > > Thanks for the report. No need to worry, the bug has existed for a > > while, this patch just turns on the warning ;-) > > > > The following commit queued up in

Re: [tip:sched/core] sched/core: Add debugging code to catch missing update_rq_clock() calls

On Tue, 2017-01-31 at 16:30 +0530, Sachin Sant wrote: > Trimming the cc list. > > > > I assume I should be worried? > > > > Thanks for the report. No need to worry, the bug has existed for a > > while, this patch just turns on the warning ;-) > > > > The following commit queued up in

Re: [PATCH] x86/microcode: Do not access the initrd after it has been freed

On Tue, 2017-01-31 at 11:01 +0100, Borislav Petkov wrote: > On Tue, Jan 31, 2017 at 08:43:55AM +0100, Ingo Molnar wrote: > > (Cc:-ed Mike as this could explain his early boot crash/hang? > > Mike: please try -tip f18a8a0143b1 that I just pushed out. ) > > One other thing to try, Mike, is

Re: [PATCH] x86/microcode: Do not access the initrd after it has been freed

On Tue, 2017-01-31 at 11:01 +0100, Borislav Petkov wrote: > On Tue, Jan 31, 2017 at 08:43:55AM +0100, Ingo Molnar wrote: > > (Cc:-ed Mike as this could explain his early boot crash/hang? > > Mike: please try -tip f18a8a0143b1 that I just pushed out. ) > > One other thing to try, Mike, is

Re: WARNING: CPU: 1 PID: 15 at kernel/sched/sched.h:804 assert_clock_updated.isra.62.part.63+0x25/0x27

On Tue, 2017-01-31 at 09:54 +0100, Ingo Molnar wrote: > > Fast ain't gonna happen, 5bf728f02218 bricked. > > :-/ > > Next point would be f9a42e0d58cf I suspect, to establish that Linus's latest > kernel is fine. That means it's in one of the ~200 -tip commits - should be > bisectable in 8-10

Re: WARNING: CPU: 1 PID: 15 at kernel/sched/sched.h:804 assert_clock_updated.isra.62.part.63+0x25/0x27

On Tue, 2017-01-31 at 09:54 +0100, Ingo Molnar wrote: > > Fast ain't gonna happen, 5bf728f02218 bricked. > > :-/ > > Next point would be f9a42e0d58cf I suspect, to establish that Linus's latest > kernel is fine. That means it's in one of the ~200 -tip commits - should be > bisectable in 8-10

Re: WARNING: CPU: 1 PID: 15 at kernel/sched/sched.h:804 assert_clock_updated.isra.62.part.63+0x25/0x27

On Tue, 2017-01-31 at 08:28 +0100, Ingo Molnar wrote: > * Mike Galbraith <efa...@gmx.de> wrote: > > > On Mon, 2017-01-30 at 11:59 +, Matt Fleming wrote: > > > On Sat, 28 Jan, at 08:21:05AM, Mike Galbraith wrote: > > > > Running Steven's hotp

Re: WARNING: CPU: 1 PID: 15 at kernel/sched/sched.h:804 assert_clock_updated.isra.62.part.63+0x25/0x27

On Tue, 2017-01-31 at 08:28 +0100, Ingo Molnar wrote: > * Mike Galbraith wrote: > > > On Mon, 2017-01-30 at 11:59 +, Matt Fleming wrote: > > > On Sat, 28 Jan, at 08:21:05AM, Mike Galbraith wrote: > > > > Running Steven's hotplug stress script in tip.today.

Re: WARNING: CPU: 1 PID: 15 at kernel/sched/sched.h:804 assert_clock_updated.isra.62.part.63+0x25/0x27

On Tue, 2017-01-31 at 08:45 +0100, Ingo Molnar wrote: > * Mike Galbraith <efa...@gmx.de> wrote: > > > On Tue, 2017-01-31 at 08:28 +0100, Ingo Molnar wrote: > > > * Mike Galbraith <efa...@gmx.de> wrote: > > > > > > Weeell, I'll have

Re: WARNING: CPU: 1 PID: 15 at kernel/sched/sched.h:804 assert_clock_updated.isra.62.part.63+0x25/0x27

On Tue, 2017-01-31 at 08:45 +0100, Ingo Molnar wrote: > * Mike Galbraith wrote: > > > On Tue, 2017-01-31 at 08:28 +0100, Ingo Molnar wrote: > > > * Mike Galbraith wrote: > > > > > > Weeell, I'll have to take your word for it, as tip g35669bb7fd46 g

Re: WARNING: CPU: 1 PID: 15 at kernel/sched/sched.h:804 assert_clock_updated.isra.62.part.63+0x25/0x27

On Tue, 2017-01-31 at 08:28 +0100, Ingo Molnar wrote: > * Mike Galbraith <efa...@gmx.de> wrote: > > Weeell, I'll have to take your word for it, as tip g35669bb7fd46 grew > > an early boot brick problem. > > That's bad - could you perhaps try to bisect it? All re

Re: WARNING: CPU: 1 PID: 15 at kernel/sched/sched.h:804 assert_clock_updated.isra.62.part.63+0x25/0x27

On Tue, 2017-01-31 at 08:28 +0100, Ingo Molnar wrote: > * Mike Galbraith wrote: > > Weeell, I'll have to take your word for it, as tip g35669bb7fd46 grew > > an early boot brick problem. > > That's bad - could you perhaps try to bisect it? All recently queued up > pat

Re: WARNING: CPU: 1 PID: 15 at kernel/sched/sched.h:804 assert_clock_updated.isra.62.part.63+0x25/0x27

On Mon, 2017-01-30 at 11:59 +, Matt Fleming wrote: > On Sat, 28 Jan, at 08:21:05AM, Mike Galbraith wrote: > > Running Steven's hotplug stress script in tip.today. Config is > > NOPREEMPT, tune for maximum build time (enterprise default-ish). > > > > [

Re: WARNING: CPU: 1 PID: 15 at kernel/sched/sched.h:804 assert_clock_updated.isra.62.part.63+0x25/0x27

On Mon, 2017-01-30 at 11:59 +, Matt Fleming wrote: > On Sat, 28 Jan, at 08:21:05AM, Mike Galbraith wrote: > > Running Steven's hotplug stress script in tip.today. Config is > > NOPREEMPT, tune for maximum build time (enterprise default-ish). > > > > [

WARNING: CPU: 1 PID: 15 at kernel/sched/sched.h:804 assert_clock_updated.isra.62.part.63+0x25/0x27

Running Steven's hotplug stress script in tip.today. Config is NOPREEMPT, tune for maximum build time (enterprise default-ish). [ 75.268049] x86: Booting SMP configuration: [ 75.268052] smpboot: Booting Node 0 Processor 1 APIC 0x2 [ 75.279994] smpboot: Booting Node 0 Processor 2 APIC 0x4 [

WARNING: CPU: 1 PID: 15 at kernel/sched/sched.h:804 assert_clock_updated.isra.62.part.63+0x25/0x27

Running Steven's hotplug stress script in tip.today. Config is NOPREEMPT, tune for maximum build time (enterprise default-ish). [ 75.268049] x86: Booting SMP configuration: [ 75.268052] smpboot: Booting Node 0 Processor 1 APIC 0x2 [ 75.279994] smpboot: Booting Node 0 Processor 2 APIC 0x4 [

Re: [btrfs/rt] lockdep false positive

On Thu, 2017-01-26 at 18:09 +0100, Sebastian Andrzej Siewior wrote: > On 2017-01-25 19:29:49 [+0100], Mike Galbraith wrote: > > On Wed, 2017-01-25 at 18:02 +0100, Sebastian Andrzej Siewior wrote: > > > > > > [ 341.960794]CPU0 > > > > [ 341.96

Re: [btrfs/rt] lockdep false positive

On Thu, 2017-01-26 at 18:09 +0100, Sebastian Andrzej Siewior wrote: > On 2017-01-25 19:29:49 [+0100], Mike Galbraith wrote: > > On Wed, 2017-01-25 at 18:02 +0100, Sebastian Andrzej Siewior wrote: > > > > > > [ 341.960794]CPU0 > > > > [ 341.96

Re: [rfc patch-rt] radix-tree: Partially disable memcg accounting in radix_tree_node_alloc()

On Wed, 2017-01-25 at 16:06 +0100, Sebastian Andrzej Siewior wrote: > According to the to description of radix_tree_preload() the return code > of 0 means that the following addition of a single element does not > fail. But in RT's case this requirement is not fulfilled. There is more > than just

Re: [rfc patch-rt] radix-tree: Partially disable memcg accounting in radix_tree_node_alloc()

On Wed, 2017-01-25 at 16:06 +0100, Sebastian Andrzej Siewior wrote: > According to the to description of radix_tree_preload() the return code > of 0 means that the following addition of a single element does not > fail. But in RT's case this requirement is not fulfilled. There is more > than just

Re: [btrfs/rt] lockdep false positive

On Wed, 2017-01-25 at 18:02 +0100, Sebastian Andrzej Siewior wrote: > > [ 341.960794]CPU0 > > [ 341.960795] > > [ 341.960795] lock(btrfs-tree-00); > > [ 341.960795] lock(btrfs-tree-00); > > [ 341.960796] > > [ 341.960796] *** DEADLOCK *** > > [ 341.960796] > > [

Re: [btrfs/rt] lockdep false positive

On Wed, 2017-01-25 at 18:02 +0100, Sebastian Andrzej Siewior wrote: > > [ 341.960794]CPU0 > > [ 341.960795] > > [ 341.960795] lock(btrfs-tree-00); > > [ 341.960795] lock(btrfs-tree-00); > > [ 341.960796] > > [ 341.960796] *** DEADLOCK *** > > [ 341.960796] > > [

Re: [btrfs/rt] lockdep false positive

On Sun, 2017-01-22 at 18:45 +0100, Mike Galbraith wrote: > On Sun, 2017-01-22 at 09:46 +0100, Mike Galbraith wrote: > > Greetings btrfs/lockdep wizards, > > > > RT trees have trouble with the BTRFS lockdep positive avoidance lock > > class dance (see disk-io.c). See

Re: [btrfs/rt] lockdep false positive

On Sun, 2017-01-22 at 18:45 +0100, Mike Galbraith wrote: > On Sun, 2017-01-22 at 09:46 +0100, Mike Galbraith wrote: > > Greetings btrfs/lockdep wizards, > > > > RT trees have trouble with the BTRFS lockdep positive avoidance lock > > class dance (see disk-io.c). See

Re: [btrfs/rt] lockdep false positive

> +>> > /* > +>> > * Allow read-after-read or read-after-write recursion of the > +>> > * same lock class for RT rwlocks. > +>> > */ > +>> > if (read == 3 && (prev->read == 3 || prev->read == 0)) Pff, shoulda left it reader vs reader.. but

Re: [btrfs/rt] lockdep false positive

> +>> > /* > +>> > * Allow read-after-read or read-after-write recursion of the > +>> > * same lock class for RT rwlocks. > +>> > */ > +>> > if (read == 3 && (prev->read == 3 || prev->read == 0)) Pff, shoulda left it reader vs reader.. but

Re: [btrfs/rt] lockdep false positive

On Sun, 2017-01-22 at 09:46 +0100, Mike Galbraith wrote: > Greetings btrfs/lockdep wizards, > > RT trees have trouble with the BTRFS lockdep positive avoidance lock > class dance (see disk-io.c). Seems the trouble is due to RT not having > a means of telling lockdep t

Re: [btrfs/rt] lockdep false positive

On Sun, 2017-01-22 at 09:46 +0100, Mike Galbraith wrote: > Greetings btrfs/lockdep wizards, > > RT trees have trouble with the BTRFS lockdep positive avoidance lock > class dance (see disk-io.c). Seems the trouble is due to RT not having > a means of telling lockdep t

[btrfs/rt] lockdep false positive

Greetings btrfs/lockdep wizards, RT trees have trouble with the BTRFS lockdep positive avoidance lock class dance (see disk-io.c). Seems the trouble is due to RT not having a means of telling lockdep that its rwlocks are recursive for read by the lock owner only, combined with the BTRFS lock

[btrfs/rt] lockdep false positive

Greetings btrfs/lockdep wizards, RT trees have trouble with the BTRFS lockdep positive avoidance lock class dance (see disk-io.c). Seems the trouble is due to RT not having a means of telling lockdep that its rwlocks are recursive for read by the lock owner only, combined with the BTRFS lock

<    8   9   10   11   12   13   14   15   16   17   >