[ANNOUNCE] 4.19.188-rt77

attributes drm/imx: imx-ldb: fix out of bounds array access warning Aya Levin (1): net/mlx5: Fix PBMC register mapping Bastian Germann (1): ASoC: sunxi: sun4i-codec: fill ASoC card owner Bob Peterson (1): gfs2: report "already frozen/thawed" errors Clark W

[ANNOUNCE] 4.19.185-rt76

streams issue on 0.96 xHCI Clark Williams (2): Merge tag 'v4.19.185' into v4.19-rt Linux 4.19.185-rt76 David Brazdil (1): selinux: vsock: Set SID for socket returned by accept() Dinghao Liu (1): extcon: Fix error handling in extcon_dev_register Doug Brown (1): appletalk

[ANNOUNCE] 4.19.184-rt75

-flag Christian König (1): drm/radeon: fix AGP dependency Christophe Leroy (1): powerpc: Force inlining of cpu_has_feature() to avoid build failure Clark Williams (3): Merge tag 'v4.19.183' into linux-4.19.y-rt Merge tag 'v4.19.184' into linux-4.19.y-rt Linux

[ANNOUNCE] 4.14.226-rt109

a resource leak in an error handling path in 'mxs_mmc_probe()' Clark Williams (2): Merge tag 'v4.14.226' into v4.14-rt Linux 4.14.226-rt109 Daiyue Zhang (1): configfs: fix a use-after-free in __configfs_open_file Dan Carpenter (6): USB: gadget: u_ether: Fix a configfs return

[ANNOUNCE] 4.14.225-rt108

: Add function 1 DMA alias quirk for Marvell 9215 SATA controller Clark Williams (2): Merge tag 'v4.14.225' into v4.14-rt Linux 4.14.225-rt108 Colin Ian King (1): ALSA: ctxfi: cthw20k2: fix mask on conf to allow 4 bits Dan Carpenter (1): rsxx: Return -EFAULT if copy_to_user

[ANNOUNCE] 4.14.224-rt107

Hello RT-list! I'm pleased to announce the 4.14.224-rt107 stable release. Note that there was a futex/mutex code collision when I merge v4.14.218. I believe that it's fixed correctly but anyone with suspicions about futex/mutex behavior in this release, that's where I'd start looking. You can

[ANNOUNCE] 4.14.215-rt105

Hello RT-list! I'm pleased to announce the 4.14.215-rt105 stable release. You can get this release via the git tree at: git://git.kernel.org/pub/scm/linux/kernel/git/rt/linux-stable-rt.git branch: v4.14-rt Head SHA1: 86898452a42078b98cfe9d8a25404fee11563083 Or to build 4.14.215-rt105

[ANNOUNCE] 4.14.214-rt104

Hello RT-list! I'm pleased to announce the 4.14.214-rt104 stable release. You can get this release via the git tree at: git://git.kernel.org/pub/scm/linux/kernel/git/rt/linux-stable-rt.git branch: v4.14-rt Head SHA1: 97732d346a9177c209261cea6f7822f7d3e0ce9a Or to build 4.14.214-rt104

[ANNOUNCE] 4.14.213-rt103

Hello RT-list! I'm pleased to announce the 4.14.213-rt103 stable release. You can get this release via the git tree at: git://git.kernel.org/pub/scm/linux/kernel/git/rt/linux-stable-rt.git branch: v4.14-rt Head SHA1: af29de213eb180fe8a0db0d4aadde83f1a74be13 Or to build 4.14.213-rt103

[ANNOUNCE] 4.14.212-rt102

Hello RT-list! I'm pleased to announce the 4.14.212-rt102 stable release. You can get this release via the git tree at: git://git.kernel.org/pub/scm/linux/kernel/git/rt/linux-stable-rt.git branch: v4.14-rt Head SHA1: cc763276d939207b3424090ab618c3e52f7d49de Or to build 4.14.212-rt102

[ANNOUNCE] 4.14.209-rt101

Hello RT-list! I'm pleased to announce the 4.14.209-rt101 stable release. You can get this release via the git tree at: git://git.kernel.org/pub/scm/linux/kernel/git/rt/linux-stable-rt.git branch: v4.14-rt Head SHA1: a19d538aef10c100fd2d85b5a96708792154d44f Or to build 4.14.209-rt101

[ANNOUNCE] 4.14.207-rt100

Hello RT-list! I'm pleased to announce the 4.14.207-rt100 stable release. You can get this release via the git tree at: git://git.kernel.org/pub/scm/linux/kernel/git/rt/linux-stable-rt.git branch: v4.14-rt Head SHA1: 22416f5a24532864c6e6aea7496bb56084d7abb6 Or to build 4.14.207-rt100

[ANNOUNCE] 4.14.206-rt99

Hello RT-list! I'm pleased to announce the 4.14.206-rt99 stable release. This release also has the following RT commit backported: 0fdc91971b34 ptrace: fix ptrace_unfreeze_traced() race with rt-lock You can get this release via the git tree at:

[ANNOUNCE] 4.9.241-rt156

Hello RT-list! I'm pleased to announce the 4.9.241-rt156 stable release. You can get this release via the git tree at: git://git.kernel.org/pub/scm/linux/kernel/git/rt/linux-stable-rt.git branch: v4.9-rt Head SHA1: a6dd7b8abd36091f06bc6a65e40f41d7dc6a5997 Or to build 4.9.241-rt156

[ANNOUNCE] 4.14.204-rt98

Hello RT-list! I'm pleased to announce the 4.14.204-rt98 stable release. You can get this release via the git tree at: git://git.kernel.org/pub/scm/linux/kernel/git/rt/linux-stable-rt.git branch: v4.14-rt Head SHA1: a732a33d9a454d33d99df2eb900c33039b23d5e2 Or to build 4.14.204-rt98

[ANNOUNCE] 4.9.240-rt155

Hello RT-list! I'm pleased to announce the 4.9.240-rt155 stable release. Note that this is a merge of the upstream stable releases only and no change has been made to RT code, as the v4.9 branch is in maintenance mode. You can get this release via the git tree at:

[ANNOUNCE] 4.14.202-rt97

Hello RT-list! I'm pleased to announce the 4.14.202-rt97 stable release. You can get this release via the git tree at: git://git.kernel.org/pub/scm/linux/kernel/git/rt/linux-stable-rt.git branch: v4.14-rt Head SHA1: 55b07213576aa053c62507c97f194df13c25c155 Or to build 4.14.202-rt97

[PATCH] tracing: fix compile failure on RT with PREEMPT_RT off

This patch is against v5.9-rc8-rt14 Fix a compile issue when CONFIG_PREEMPT_RT is not defined. If we're not on an RT kernel, just set the migration disabled status to zero. Signed-off-by: Clark Williams --- kernel/trace/trace.c | 12 +++- 1 file changed, 11 insertions(+), 1 deletion

[ANNOUNCE] 4.9.236-rt154

Hello RT-list! I'm pleased to announce the 4.9.236-rt154 stable release. You can get this release via the git tree at: git://git.kernel.org/pub/scm/linux/kernel/git/rt/linux-stable-rt.git branch: v4.9-rt Head SHA1: d81b19f462cdf108afa79e7f7717190a280a299e Or to build 4.9.236-rt154

[ANNOUNCE] 4.14.198-rt96

Hello RT-list! I'm pleased to announce the 4.14.198-rt96 stable release. You can get this release via the git tree at: git://git.kernel.org/pub/scm/linux/kernel/git/rt/linux-stable-rt.git branch: v4.14-rt Head SHA1: 8c4828cbd4220fc1c97c0db534fce850b86aa8d4 Or to build 4.14.198-rt96

[ANNOUNCE] 4.9.235-rt153

Hello RT-list! I'm pleased to announce the 4.9.235-rt153 stable release. You can get this release via the git tree at: git://git.kernel.org/pub/scm/linux/kernel/git/rt/linux-stable-rt.git branch: v4.9-rt Head SHA1: 0e7258df4e13bd29c182837d9b642b2ad7868847 Or to build 4.9.235-rt153

[ANNOUNCE] 4.14.197-rt95

Hello RT-list! I'm pleased to announce the 4.14.197-rt95 stable release. In addition to the merge of the .196 and .197 stable release tags, this release contains three RT specific fixes: eba893980303 net: xfrm: fix compress vs decompress serialization 23d7ce6a6ca9 Bluetooth: Acquire

[ANNOUNCE] 4.9.234-rt152

Hello RT-list! I'm pleased to announce the 4.9.234-rt152 stable release. You can get this release via the git tree at: git://git.kernel.org/pub/scm/linux/kernel/git/rt/linux-stable-rt.git branch: v4.9-rt Head SHA1: f54ae0918dc6b62e5c6e38add0f7ddb13f1fcc6f Or to build 4.9.234-rt152

[ANNOUNCE] 4.14.195-rt94

Hello RT-list! I'm pleased to announce the 4.14.195-rt94 stable release. You can get this release via the git tree at: git://git.kernel.org/pub/scm/linux/kernel/git/rt/linux-stable-rt.git branch: v4.14-rt Head SHA1: 621094972be038753162aea35d63b4e904c85f46 Or to build 4.14.195-rt94

[ANNOUNCE] 4.9.233-rt151

Hello RT-list! I'm pleased to announce the 4.9.233-rt151 stable release. You can get this release via the git tree at: git://git.kernel.org/pub/scm/linux/kernel/git/rt/linux-stable-rt.git branch: v4.9-rt Head SHA1: ac50e0392167afde7bc752ac240d2adbee56c483 Or to build 4.9.233-rt151

[ANNOUNCE] 4.14.194-rt93

Hello RT-list! I'm pleased to announce the 4.14.194-rt93 stable release. You can get this release via the git tree at: git://git.kernel.org/pub/scm/linux/kernel/git/rt/linux-stable-rt.git branch: v4.14-rt Head SHA1: 12bc7963be92af2155fb661bea9f3a420338b54d Or to build 4.14.194-rt93

[ANNOUNCE] 4.14.193-rt92

Hello RT-list! I'm pleased to announce the 4.14.193-rt92 stable release. You can get this release via the git tree at: git://git.kernel.org/pub/scm/linux/kernel/git/rt/linux-stable-rt.git branch: v4.14-rt Head SHA1: 832a83d1bb8ce9a523aef196b40c17318f0a6e52 Or to build 4.14.193-rt92

[ANNOUNCE] 4.14.192-rt91

Hello RT-list! I'm pleased to announce the 4.14.192-rt91 stable release. This is a merge of the 4.14.192 stable release with no conflicts or changes to the PREEMPT_RT code. You can get this release via the git tree at: git://git.kernel.org/pub/scm/linux/kernel/git/rt/linux-stable-rt.git

[ANNOUNCE] 4.9.232-rt150

Hello RT-list! I'm pleased to announce the 4.9.232-rt150 stable release. Please note that the 4.9-rt branch is in maintenance mode and is strictly a merge of the upstream stable release with no changes to the PREEMPT_RT code. You can get this release via the git tree at:

[ANNOUNCE] 4.14.191-rt90

Hello RT-list! I'm pleased to announce the 4.14.191-rt90 stable release. You can get this release via the git tree at: git://git.kernel.org/pub/scm/linux/kernel/git/rt/linux-stable-rt.git branch: v4.14-rt Head SHA1: ef64ca5950d5d71384d61cd40187ac5d23e5db6e Or to build 4.14.191-rt90

[ANNOUNCE] 4.9.231-rt149

Hello RT-list! I'm pleased to announce the 4.9.231-rt149 stable release. Note that since v4.9-rt is in maintenance mode, this is strictly a merge of the latest stable updates for 4.9 and there are no changes to the PREEMPT_RT code. You can get this release via the git tree at:

[ANNOUNCE] 4.14.189-rt88

Hello RT-list! I'm pleased to announce the 4.14.189-rt88 stable release. This is strictly a backport of the stable update with no changes to PREEMPT_RT code. You can get this release via the git tree at: git://git.kernel.org/pub/scm/linux/kernel/git/rt/linux-stable-rt.git branch: v4.14-rt

[ANNOUNCE] 4.14.188-rt87

Hello RT-list! I'm pleased to announce the 4.14.188-rt87 stable release. This is strictly a merge of stable kernels v4.14.187 and v4.14.188, no updates to the PREEMPT_RT series. You can get this release via the git tree at: git://git.kernel.org/pub/scm/linux/kernel/git/rt/linux-stable-rt.git

[ANNOUNCE] 4.9.230-rt148

Hello RT-list! I'm pleased to announce the 4.9.230-rt148 stable release. Since the 4.9 RT kernel is in maintenance mode this is just a merge of the v4.9.229 and v4.9.230 stable updates. No changes to the PREEMPT_RT series. You can get this release via the git tree at:

[ANNOUNCE] 4.14.186-rt86

Hello RT-list! I'm pleased to announce the 4.14.186-rt86 stable release. Note: This update required dealing with a conflict in net/core/dev.c, where devnet_rename_seq was moved from a seqence count to an RWSEWM and renamed to devnet_rename_sem. If you encounter runtime issues that show

[ANNOUNCE] 4.14.185-rt85

Hello RT-list! I'm pleased to announce the 4.14.185-rt85 stable release. You can get this release via the git tree at: git://git.kernel.org/pub/scm/linux/kernel/git/rt/linux-stable-rt.git branch: v4.14-rt Head SHA1: 0997f0bdf9eb2aa24695fbd8a228cef4422cf1b6 Or to build 4.14.185-rt85

[ANNOUNCE] 4.9.227-rt146

Hello RT-list! I'm pleased to announce the 4.9.227-rt146 stable release. Note that v4.9-rt is in maintenance mode so no RT backports are included, this is strictly a merge of the upstream stable changes for v4.9. You can get this release via the git tree at:

[ANNOUNCE] 4.9.227-rt146

Hello RT-list! I'm pleased to announce the 4.9.227-rt146 stable release. Note that v4.9-rt is in maintenance mode so no RT backports are included, this is strictly a merge of the upstream stable changes for v4.9. You can get this release via the git tree at:

[ANNOUNCE] 4.14.184-rt84

Hello RT-list! I'm pleased to announce the 4.14.184-rt84 stable release. In addition to the 4.14.184 stable release merge, this release contains the following three RT fixes: 5bba64129745 tasklet: Address a race resulting in double-enqueue 886fa0cf47d6 mm: slub: Always flush the delayed empty

[ANNOUNCE] 4.14.183-rt83

Hello RT-list! I'm pleased to announce the 4.14.183-rt83 stable release. This update is strictly application of upstream stable kernel updates and no changes to the PREEMPT_RT patchset. You can get this release via the git tree at:

[ANNOUNCE] 4.9.226-rt145

Hello RT-list! I'm pleased to announce the 4.9.226-rt145 stable release. Note that since 4.9-rt is in maintenance mode, this is just the result of merging in the latest linux-stable releases; no changes were made to the PREEMPT_RT patches for the 4.9 tree. You can get this release via the git

[ANNOUNCE] 4.9.224-rt144

Hello RT-list! I'm pleased to announce the 4.9.224-rt144 stable release. Note that since 4.9-rt is in maintenance mode, this is just the merge/rebase to the latest upstream stable releases with no changes to the RT patchset. You can get this release via the git tree at:

[PATCH] i915: reduce scope of irq disable when signaling breadcrumbs

From: Clark Williams Rather than disable irqs around the call to intel_engine_breadcrumbs_irq() use raw_spin_lock_irq() around the signalers loop inside intel_engine_breadcrumbs_irq(). It's entirely possible that we only need local_irq_{disable, enable} around the call

[PREEMPT_RT PATCH 0/3] i915 fixups for lockdep/lockdebugging

From: Clark Williams The i915 driver was throwing splats on my home test box running v5.2-rt3 when I turned on lockdep and lock debugging configs. This was mainly due to the non-side effects of the spin*_irq*() macros which do nothing to IRQs on PREEMPT_RT. Converting the various irq_lock

[PREEMPT_RT PATCH 2/3] i915: convert all irq_locks spinlocks to raw spinlocks

From: Clark Williams The following structures contain a member named 'irq_lock'. These three locks are of type spinlock_t and are used in multiple contexts including atomic: struct drm_i915_private struct intel_breadcrumbs strict intel_guc Convert them all to be raw_spinlock_t so

[PREEMPT_RT PATCH 3/3] i915: convert uncore lock to raw spinlock

From: Clark Williams The structure intel_uncore contains a spinlock member named 'lock' which is used in multiple contexts. Convert it to a raw spinlock so that lockdep and the lock debugging code will be happy. Signed-off-by: Clark Williams --- drivers/gpu/drm/i915/i915_gem.c | 4

[PREEMPT_RT PATCH 1/3] i915: do not call lockdep_assert_irqs_disabled() on PREEMPT_RT

From: Clark Williams The 'breadcrumb' code in the i915 driver calls lockdep_assert_irqs_disabled() when starting some operations. This is valid on a stock kernel but on a PREEMPT_RT kernel the spin_lock_irq*() calls to not disable interrupts and likewise the spin_unlock_irq*() calls

Re: [RT PATCH] sched/deadline: Make inactive timer run in hardirq context

ctive_task_timer(struct sched_dl_entity > *dl_se) > { > struct hrtimer *timer = _se->inactive_timer; > > - hrtimer_init(timer, CLOCK_MONOTONIC, HRTIMER_MODE_REL); > + hrtimer_init(timer, CLOCK_MONOTONIC, HRTIMER_MODE_REL_HARD); > timer->function

Re: [PREEMPT_RT] splat in v5.2-rt1: r t_mutex_owner(lock) != current

On Wed, 17 Jul 2019 08:34:59 +0200 Juri Lelli wrote: > Hi Clark, > > On 16/07/19 17:55, Clark Williams wrote: > > Saw this after applying my thermal lock to raw patch and the change in i915 > > for lockdep. The > > splat occurred on boot when creating

[PREEMPT_RT] splat in v5.2-rt1: r t_mutex_owner(lock) != current

Saw this after applying my thermal lock to raw patch and the change in i915 for lockdep. The splat occurred on boot when creating the kdump initramfs. System is an Intel NUC i7 with 32GB ram and 256GB SSD for rootfs. The booting kernel has rt_mutex debugging turned on as well as lockdep and

Re: [patch 1/1] Kconfig: Introduce CONFIG_PREEMPT_RT

it. To achieve that the > existing PREEMPT choice is renamed to PREEMPT_LL which select PREEMPT as > well. > > No functional change. > > Signed-off-by: Thomas Gleixner Excited to see this Thomas. Now I can start planning to build from a single tree rather than an RT tree off to the

[PREEMPT_RT] bogus lockdep assert from i915 on v5.2-rt1

:00 2001 From: Clark Williams Date: Sun, 14 Jul 2019 16:42:21 -0500 Subject: [PATCH 1/2] i915: avoid calling lockdep_assert_irqs_disabled on PREEMPT_RT_FULL The PREEMPT_RT_FULL patchset keeps irqs enabled when operating on spin_locks. Avoid this lockdep call on RT since in most cases it will f

[PATCH] x86_pkg_temp_thermal: make pkg_temp_lock a raw spinlock

The spinlock pkg_temp_lock has the potential of being taken in atomic context on v5.2-rt PREEMPT_RT. It's static and limited scope so go ahead and make it a raw spinlock. Signed-off-by: Clark Williams --- drivers/thermal/intel/x86_pkg_temp_thermal.c | 24 ++-- 1 file changed, 12

[PATCH] hwlatdetect: disable/enable c-state transitions during detection

the /dev/cpu_dma_latency mechanism to disable c-state transitions while running the hardware latency detector. Open the file /dev/cpu_dma_latency and write a 32-bit zero to it, which will prevent c-state transitions while the file is open. Signed-off-by: Clark Williams --- src/hwlatdetect

Re: [ptrace, rt] erratic behaviour in PTRACE_SINGLESET on 4.13-rt and later.

Joe, This looks interesting. Do you have a git repo where I can pull the source? Clark On Tue, 20 Nov 2018 12:29:00 -0500 Steven Rostedt wrote: > [ Adding Clark and John who manage the rt-tests repo ] > > -- Steve > > On Mon, 19 Nov 2018 19:46:23 + > Joe Korty wrote: > > > Hi Julia &

Re: [ptrace, rt] erratic behaviour in PTRACE_SINGLESET on 4.13-rt and later.

Joe, This looks interesting. Do you have a git repo where I can pull the source? Clark On Tue, 20 Nov 2018 12:29:00 -0500 Steven Rostedt wrote: > [ Adding Clark and John who manage the rt-tests repo ] > > -- Steve > > On Mon, 19 Nov 2018 19:46:23 + > Joe Korty wrote: > > > Hi Julia &

Re: [PATCH] kasan: convert kasan/quarantine_lock to raw_spinlock

18:30:18 [+0200], To Clark Williams wrote: > > This is the minimum to get this working on RT splat free. There is one > > memory deallocation with irqs off which should work on RT in its current > > way. > > Once this and the on_each_cpu() invocation, I was wondering if… &

Re: [PATCH] kasan: convert kasan/quarantine_lock to raw_spinlock

18:30:18 [+0200], To Clark Williams wrote: > > This is the minimum to get this working on RT splat free. There is one > > memory deallocation with irqs off which should work on RT in its current > > way. > > Once this and the on_each_cpu() invocation, I was wondering if… &

[PATCH RT] rt: convert mm/kasan/quarantine_lock to raw_spinlock

kernel but is problematic on an RT kernel where spin locks are converted to rt_mutex_t, which can sleep. Convert the quarantine_lock to a raw spinlock. The usage of quarantine_lock is confined to quarantine.c and the work performed while the lock is held is limited. Signed-off-by: Clark Williams

[PATCH RT] rt: convert mm/kasan/quarantine_lock to raw_spinlock

kernel but is problematic on an RT kernel where spin locks are converted to rt_mutex_t, which can sleep. Convert the quarantine_lock to a raw spinlock. The usage of quarantine_lock is confined to quarantine.c and the work performed while the lock is held is limited. Signed-off-by: Clark Williams

[PATCH RT] fix IPI balancing for 4.14-rt

From 8ea8311b75a40bdea03e7f8228a0578b6367e9d1 Mon Sep 17 00:00:00 2001 From: Clark Williams <willi...@redhat.com> Date: Mon, 20 Nov 2017 14:26:12 -0600 Subject: [PATCH] [rt] sched/rt: fix panic in double_lock_balance with simplified IPI RT balancing I was testing 4.14-rt1 on a large

[PATCH RT] fix IPI balancing for 4.14-rt

From 8ea8311b75a40bdea03e7f8228a0578b6367e9d1 Mon Sep 17 00:00:00 2001 From: Clark Williams Date: Mon, 20 Nov 2017 14:26:12 -0600 Subject: [PATCH] [rt] sched/rt: fix panic in double_lock_balance with simplified IPI RT balancing I was testing 4.14-rt1 on a large system (cores == 96) and saw

Re: [PATCH] usb: Use _nort in usb_hcd_pci_remove

usb_hcd_irq(0, hcd); > - local_irq_enable(); > + local_irq_enable_nort(); > > /* Note: dev_set_drvdata must be called while holding the rwsem */ > if (dev->class == CL_EHCI) { > -- > 2.11.0 > > -- > To unsubscribe from this list: send the line &

Re: [PATCH] usb: Use _nort in usb_hcd_pci_remove

local_irq_enable_nort(); > > /* Note: dev_set_drvdata must be called while holding the rwsem */ > if (dev->class == CL_EHCI) { > -- > 2.11.0 > > -- > To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in > the body of

Re: [PATCH] sched/rt: RT_RUNTIME_GREED sched feature

On Mon, 7 Nov 2016 13:30:46 -0500 Steven Rostedt <rost...@goodmis.org> wrote: > On Mon, 7 Nov 2016 12:22:21 -0600 > Clark Williams <willi...@redhat.com> wrote: > > > I'm still reviewing the patch, but I have to wonder why bother with making > > it a scheduler

Re: [PATCH] sched/rt: RT_RUNTIME_GREED sched feature

On Mon, 7 Nov 2016 13:30:46 -0500 Steven Rostedt wrote: > On Mon, 7 Nov 2016 12:22:21 -0600 > Clark Williams wrote: > > > I'm still reviewing the patch, but I have to wonder why bother with making > > it a scheduler feature? > > > > The SCHED_FIFO definiti

Re: [PATCH] sched/rt: RT_RUNTIME_GREED sched feature

On Mon, 7 Nov 2016 09:17:55 +0100 Daniel Bristot de Oliveira wrote: > The rt throttling mechanism prevents the starvation of non-real-time > tasks by CPU intensive real-time tasks. In terms of percentage, > the default behavior allows real-time tasks to run up to 95% of a >

Re: [PATCH] sched/rt: RT_RUNTIME_GREED sched feature

On Mon, 7 Nov 2016 09:17:55 +0100 Daniel Bristot de Oliveira wrote: > The rt throttling mechanism prevents the starvation of non-real-time > tasks by CPU intensive real-time tasks. In terms of percentage, > the default behavior allows real-time tasks to run up to 95% of a > given period,

Re: [RFC][PATCH 0/3] tracing: Add Hardware Latency detector tracer

On Thu, 4 Aug 2016 11:30:33 -0400 Steven Rostedt wrote: > Note, I'm currently working on adding code to detect NMIs to this as > well. And perhaps even tracing SMI counters. Just to show what caused > the latency, as latency isn't measured by the counters (that I know of). >

Re: [RFC][PATCH 0/3] tracing: Add Hardware Latency detector tracer

On Thu, 4 Aug 2016 11:30:33 -0400 Steven Rostedt wrote: > Note, I'm currently working on adding code to detect NMIs to this as > well. And perhaps even tracing SMI counters. Just to show what caused > the latency, as latency isn't measured by the counters (that I know of). > I like the trace

Re: [PATCH][RT] netpoll: Always take poll_lock when doing polling

On Sun, 5 Jun 2016 08:16:58 -0700 Alison Chaiken wrote: > Steven Rostedt suggests in reference to "[PATCH][RT] netpoll: Always > take poll_lock when doing polling" > >> [ Alison, can you try this patch ] > > Sebastian follows up: > >Alison, did you try it? > >

Re: [PATCH][RT] netpoll: Always take poll_lock when doing polling

On Sun, 5 Jun 2016 08:16:58 -0700 Alison Chaiken wrote: > Steven Rostedt suggests in reference to "[PATCH][RT] netpoll: Always > take poll_lock when doing polling" > >> [ Alison, can you try this patch ] > > Sebastian follows up: > >Alison, did you try it? > > Sorry for not responding

Re: [PATCH] cyclictest: stop any tracing after hitting a breaktrace threshold

On Tue, 3 May 2016 15:56:44 -0400 Luiz Capitulino <lcapitul...@redhat.com> wrote: > On Tue, 3 May 2016 12:59:53 -0500 > Clark Williams <willi...@redhat.com> wrote: > > > John, > > > > This patch is against the devel/v0.98 branch. It turns off tracing i

Re: [PATCH] cyclictest: stop any tracing after hitting a breaktrace threshold

On Tue, 3 May 2016 15:56:44 -0400 Luiz Capitulino wrote: > On Tue, 3 May 2016 12:59:53 -0500 > Clark Williams wrote: > > > John, > > > > This patch is against the devel/v0.98 branch. It turns off tracing in the > > tracemark() so that we don't lose informa

[PATCH] cyclictest: stop any tracing after hitting a breaktrace threshold

the marker to the trace buffers and then write a "0\n" to the tracing_on file to turn off tracing, otherwise we lose the information immediately prior to the point where we hit the latency. Signed-off-by: Clark Williams <willi...@redhat.com> --- src/cyclictest/c

[PATCH] cyclictest: stop any tracing after hitting a breaktrace threshold

the marker to the trace buffers and then write a "0\n" to the tracing_on file to turn off tracing, otherwise we lose the information immediately prior to the point where we hit the latency. Signed-off-by: Clark Williams --- src/cyclictest/cyclictest.c | 32 ++-- 1 fi

Re: [RT PATCH] cputime: remove raw locks introduced by RT patchset

Revert "vtime: Split lock and seqcount" > > which is what you want, correct? > > > > Signed-off-by: Rik van Riel <r...@redhat.com> > > Signed-off-by: Clark Williams <willi...@redhat.com> > > Sebastian > Yes, that's it. I just want

Re: [RT PATCH] cputime: remove raw locks introduced by RT patchset

it lock and seqcount" > > which is what you want, correct? > > > > Signed-off-by: Rik van Riel > > Signed-off-by: Clark Williams > > Sebastian > Yes, that's it. I just wanted to get rid of the redundant locking operations and reduce the accounting overhead

[RT PATCH] cputime: remove raw locks introduced by RT patchset

with isolcpus/rcu_nocbs/nohz_full cpus. No ill effects seen. Signed-off-by: Rik van Riel <r...@redhat.com> Signed-off-by: Clark Williams <willi...@redhat.com> --- kernel/sched/cputime.c | 18 -- 1 file changed, 18 deletions(-) diff --git a/kernel/sched/cputime.c b/

[RT PATCH] cputime: remove raw locks introduced by RT patchset

with isolcpus/rcu_nocbs/nohz_full cpus. No ill effects seen. Signed-off-by: Rik van Riel Signed-off-by: Clark Williams --- kernel/sched/cputime.c | 18 -- 1 file changed, 18 deletions(-) diff --git a/kernel/sched/cputime.c b/kernel/sched/cputime.c index 0f75a38cff96..9a823ced7e4a

[PATCH] cyclictest: avoid using libnuma cpumask parsing functions

quot; when trying to place a measurement thread on an isolated cpu. This patch removes the wrapper function which uses libnuma cpumask parsing functions and instead uses the parser function we wrote for when libnuma is not available. Signed-off-by: Clark Williams <willi...@redhat.com> ---

[PATCH] cyclictest: avoid using libnuma cpumask parsing functions

quot; when trying to place a measurement thread on an isolated cpu. This patch removes the wrapper function which uses libnuma cpumask parsing functions and instead uses the parser function we wrote for when libnuma is not available. Signed-off-by: Clark Williams --- src/cyclictest/rt_n

Re: [RT] Warning from swake_up_all_locked in rt-4.4.4-rt11

On Fri, 1 Apr 2016 12:33:18 +0200 Sebastian Andrzej Siewior <bige...@linutronix.de> wrote: > * Thomas Gleixner | 2016-03-14 09:49:52 [+0100]: > > >On Sun, 13 Mar 2016, Clark Williams wrote: > > > >> I'm hitting the WARN_ON(wakes > 2) in $SUBJECT when resu

Re: [RT] Warning from swake_up_all_locked in rt-4.4.4-rt11

On Fri, 1 Apr 2016 12:33:18 +0200 Sebastian Andrzej Siewior wrote: > * Thomas Gleixner | 2016-03-14 09:49:52 [+0100]: > > >On Sun, 13 Mar 2016, Clark Williams wrote: > > > >> I'm hitting the WARN_ON(wakes > 2) in $SUBJECT when resuming from suspend > >

Re: [RT] Warning from swake_up_all_locked in rt-4.4.4-rt11

On Wed, 30 Mar 2016 12:22:51 +0200 Sebastian Andrzej Siewior <bige...@linutronix.de> wrote: > * Thomas Gleixner | 2016-03-14 09:49:52 [+0100]: > > >On Sun, 13 Mar 2016, Clark Williams wrote: > > > >> I'm hitting the WARN_ON(wakes > 2) in $SUBJECT when resu

Re: [RT] Warning from swake_up_all_locked in rt-4.4.4-rt11

On Wed, 30 Mar 2016 12:22:51 +0200 Sebastian Andrzej Siewior wrote: > * Thomas Gleixner | 2016-03-14 09:49:52 [+0100]: > > >On Sun, 13 Mar 2016, Clark Williams wrote: > > > >> I'm hitting the WARN_ON(wakes > 2) in $SUBJECT when resuming from suspend > >

[RT] Warning from swake_up_all_locked in rt-4.4.4-rt11

I'm hitting the WARN_ON(wakes > 2) in $SUBJECT when resuming from suspend on my laptop (quad-core i7 with HT on). Looks like the warning gets hit 36 times on resume. E.g.: Call Trace: [] dump_stack+0x65/0x85 [] warn_slowpath_common+0x82/0xd0 [] warn_slowpath_null+0x1a/0x20 []

[RT] Warning from swake_up_all_locked in rt-4.4.4-rt11

I'm hitting the WARN_ON(wakes > 2) in $SUBJECT when resuming from suspend on my laptop (quad-core i7 with HT on). Looks like the warning gets hit 36 times on resume. E.g.: Call Trace: [] dump_stack+0x65/0x85 [] warn_slowpath_common+0x82/0xd0 [] warn_slowpath_null+0x1a/0x20 []

[PATCH RT] rcutorture: comment out rcu_bh ops on PREEMPT_RT_FULL

RT has dropped support of rcu_bh, comment out in rcutorture. Signed-off-by: Clark Williams <willi...@redhat.com> --- kernel/rcu/rcutorture.c | 7 +++ 1 file changed, 7 insertions(+) diff --git a/kernel/rcu/rcutorture.c b/kernel/rcu/rcutorture.c index d89328e260df..5bb3364a6284

[PATCH RT] rcutorture: comment out rcu_bh ops on PREEMPT_RT_FULL

RT has dropped support of rcu_bh, comment out in rcutorture. Signed-off-by: Clark Williams --- kernel/rcu/rcutorture.c | 7 +++ 1 file changed, 7 insertions(+) diff --git a/kernel/rcu/rcutorture.c b/kernel/rcu/rcutorture.c index d89328e260df..5bb3364a6284 100644 --- a/kernel/rcu

Re: [ANNOUNCE] 4.4.1-rt6

On Mon, 15 Feb 2016 22:53:58 -0600 Clark Williams <willi...@redhat.com> wrote: > On Sat, 13 Feb 2016 00:47:08 +0100 > Sebastian Andrzej Siewior <bige...@linutronix.de> wrote: > > > - There is a useless rcu_bh thread which has been deactivated. > > &

Re: [ANNOUNCE] 4.4.1-rt6

On Mon, 15 Feb 2016 22:53:58 -0600 Clark Williams wrote: > On Sat, 13 Feb 2016 00:47:08 +0100 > Sebastian Andrzej Siewior wrote: > > > - There is a useless rcu_bh thread which has been deactivated. > > > > For some strange reason I had RCU_TORTURE_TEST defined i

Re: [ANNOUNCE] 4.4.1-rt6

rcutorture.c wanted to test the (now ifdef'ed out) rcu_bh routines. This fixes the compile issue but is untested for actually *running* rcutorture. I'll try that on a test box tomorrow. Clark From a835ff3aad772520d34548dc336925788a649b17 Mon Sep 17 00:00:00 2001 From: Clark Williams <will

Re: [ANNOUNCE] 4.4.1-rt6

o test the (now ifdef'ed out) rcu_bh routines. This fixes the compile issue but is untested for actually *running* rcutorture. I'll try that on a test box tomorrow. Clark From a835ff3aad772520d34548dc336925788a649b17 Mon Sep 17 00:00:00 2001 From: Clark Williams Date: Mon, 15 Feb 2016 22:48:04 -0600 S

Re: [RT] oops in 4.1.3-rt3

On Mon, 3 Aug 2015 14:27:00 -0500 Clark Williams wrote: > Sebastian, > > Below is a traceback I hit while running 4.1.3-rt3 on my Lenovo T530. > > I was doing my normal, play music, copy files over the lan, do compiles, > do email, etc., so I I can't really point y

Re: [RT] oops in 4.1.3-rt3

On Mon, 3 Aug 2015 14:27:00 -0500 Clark Williams <willi...@redhat.com> wrote: > Sebastian, > > Below is a traceback I hit while running 4.1.3-rt3 on my Lenovo T530. > > I was doing my normal, play music, copy files over the lan, do compiles, > do email, etc., so I

[RT - hwlat_detector] correctly record max when the "outer" value is maximum

:00 2001 From: Clark Williams Date: Fri, 7 Aug 2015 15:07:30 -0500 Subject: [PATCH] hwlat_detector: update stats code to record when "outer" interval exceeds threshold The hwlat_detector polls the system clock (either ktime_get() or trace_clock_local()) source looking for intervals b

[RT - hwlat_detector] correctly record max when the outer value is maximum

: Clark Williams willi...@redhat.com Date: Fri, 7 Aug 2015 15:07:30 -0500 Subject: [PATCH] hwlat_detector: update stats code to record when outer interval exceeds threshold The hwlat_detector polls the system clock (either ktime_get() or trace_clock_local()) source looking for intervals between

[RT] oops in 4.1.3-rt3

Sebastian, Below is a traceback I hit while running 4.1.3-rt3 on my Lenovo T530. I was doing my normal, play music, copy files over the lan, do compiles, do email, etc., so I I can't really point you at a reproducer. The graphics system stayed up somewhat but the actual trace I hit scrolled off.

[RT] oops in 4.1.3-rt3

Sebastian, Below is a traceback I hit while running 4.1.3-rt3 on my Lenovo T530. I was doing my normal, play music, copy files over the lan, do compiles, do email, etc., so I I can't really point you at a reproducer. The graphics system stayed up somewhat but the actual trace I hit scrolled off.

  1   2   3   >