From: Paul Gortmaker
Bruce,
So, I knew that i915 fix we dealt with on v6.1 was actually present in
the v5.15-rt branch and not just floating out in space.
So I figured I'd help out and also look at getting this older version
caught up with the where the linux-stable-rt repository is today.
We
From: Tvrtko Ursulin
commit e6eb0105c20694af5642c77bf63c9509e4f9bb28 in linux-stable-rt
[commit 40cd2835ced288789a685aa4aa7bc04b492dcd45 in linux-rt-devel]
Commit ade8a0f59844 ("drm/i915: Make all GPU resets atomic") added a
preempt disable section over the hardware reset callback to prepare th
From: Joseph Salisbury
commit e9e280348657bf29b5f35e37e34e4da26821116c in linux-stable-rt
Signed-off-by: Joseph Salisbury
Signed-off-by: Paul Gortmaker
---
localversion-rt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/localversion-rt b/localversion-rt
index 9b7de9345ef4.
From: Thomas Gleixner
commit 71c09b1d6b07a7e4d8d1c686b53f8d1442f8ec14 in linux-stable-rt
posix_timer_add() tries to allocate a posix timer ID by starting from the
cached ID which was stored by the last successful allocation.
This is done in a loop searching the ID space for a free slot one by
o
From: Sebastian Andrzej Siewior
commit 87572f0f6aa8cbb3c69a7085fae70786cd217653 in linux-stable-rt
bpf_free_inode() is invoked as a RCU callback. Usually RCU callbacks are
invoked within softirq context. By setting rcutree.use_softirq=0 boot
option the RCU callbacks will be invoked in a per-CPU
From: Peter Zijlstra
commit 1992720dff250e9d7d99696588ab1b197160c6b6 in linux-stable-rt
There is an explicit wait-type violation in debug_object_fill_pool()
for PREEMPT_RT=n kernels which allows them to more easily fill the
object pool and reduce the chance of allocation failures.
Lockdep's wai
From: Wander Lairson Costa
commit 20616d2c54d5db199f983ca9515630f361d5c995 in linux-stable-rt
In put_task_struct(), a spin_lock is indirectly acquired under the kernel
stock. When running the kernel in real-time (RT) configuration, the
operation is dispatched to a preemptible context call to ens
From: Sebastian Andrzej Siewior
commit f9fec545dea4aac71dfb54e3a6d187cc92af9ea4 in linux-stable-rt
__build_all_zonelists() acquires zonelist_update_seq by first disabling
interrupts via local_irq_save() and then acquiring the seqlock with
write_seqlock(). This is troublesome and leads to problem
From: Thomas Gleixner
commit ccf6bfd49a8a7d25bacc8e84ec5dbdfe513c29c3 in linux-stable-rt
The recent fix to ensure atomicity of lookup and allocation inadvertently
broke the pool refill mechanism.
Prior to that change debug_objects_activate() and debug_objecs_assert_init()
invoked debug_objecs_i
From: Sebastian Andrzej Siewior
commit 47364f671cbed35071551bd911dc7b89a1761804 in linux-stable-rt
On PREEMPT_RT, rw_semaphore and rwlock_t locks are unfair to writers.
Readers can indefinitely acquire the lock unless the writer fully acquired
the lock, which might never happen if there is alway
From: Paolo Abeni
commit e94601d32f4d7fdc28da15a72fe5262c63a5755a in linux-stable-rt
This reverts the following commits:
4cd13c21b207 ("softirq: Let ksoftirqd do its job")
3c53776e29f8 ("Mark HI and TASKLET softirq synchronous")
1342d8080f61 ("softirq: Don't skip softirq execution when so
From: Sebastian Andrzej Siewior
commit f1bd52382dcefb82cdc243575ab81f3966165b47 in linux-stable-rt
io_mapping_map_atomic_wc() disables preemption and pagefaults for
historical reasons. The conversion to io_mapping_map_local_wc(), which
only disables migration, cannot be done wholesale because q
Bruce,
This commit has lingered on a dead end branch in linux-stable-rt since August:
linux-stable-rt$git branch --contains 1a80b572f783a
v6.1-rt-next
linux-stable-rt$
I will contact the maintainer, but the updates are pretty slow over there.
Nothing wrong with the commit - in fact it is now
From: Paul Gortmaker
Unfortunately linux-stable backported this:
Subject: ima: Remove deprecated IMA_TRUSTED_KEYRING Kconfig
From: Nayna Jain
[ Upstream commit 5087fd9e80e539d2163accd045b73da64de7de95 ]
Time to remove "IMA_TRUSTED_KEYRING".
...to all releases still being maintained.
wrote:
> >
> > > > -Original Message-
> > > > From: linux-yocto@lists.yoctoproject.org > > > yo...@lists.yoctoproject.org> On Behalf Of Paul Gortmaker via
> > > > lists.yoctoproject.org
> > > > Sent: Friday, December 1, 202
[RE: [linux-yocto] [PATCH 3/5] x86-64: don't force EDAC support on everyone] On
30/11/2023 (Thu 19:29) Liu, Yongxin wrote:
> > -Original Message-
> > From: linux-yocto@lists.yoctoproject.org > yo...@lists.yoctoproject.org> On Behalf Of Paul Gortmaker via
>
[RE: [linux-yocto] [PATCH 4/5] x86-64: use the defaults for number of CPUs] On
30/11/2023 (Thu 20:12) Liu, Yongxin wrote:
> > -Original Message-
> > From: linux-yocto@lists.yoctoproject.org > yo...@lists.yoctoproject.org> On Behalf Of Paul Gortmaker via
> >
From: Paul Gortmaker
Consider this 5+ year old commit
commit bcbc7bbc4fb967d8d4ae6333f71b73491a80b94e
Author: Alexander Kanavin
Date: Thu Mar 1 16:00:41 2018 +0200
latencytop: remove recipe
Last commit and release were in 2009; website is down; it's a dead project.
From: Paul Gortmaker
Similar to the argument of why we shouldn't force NUMA on everyone, the
9 chip registered ECC RAM type stuff also tends to be found mostly on
larger server type stuff and less so on embedded targets.
We already have a skeleton EDAC feature, so move the features over
there.
From: Paul Gortmaker
A user reported getting NUMA warnings like the ones reported here:
https://www.suse.com/support/kb/doc/?id=21040
"Fail to get numa node for CPU:0 bus:0 dev:0 fn:1"
...and repeated for every core on the platform. Distracting.
When I asked if it was a crazy big server
From: Paul Gortmaker
Bruce,
Here are a few things that have bugged me and finally added up to make a
series possibly worthwhile.
We've been forcing NUMA and EDAC and 512 CPU support on everyone: even
people building for a point-of-sale terminal using an intel Atom.
Doesn't make sense. Let thos
From: Paul Gortmaker
No functional change - just makes further reorganizations and
refactoring more easy to review/parse.
Signed-off-by: Paul Gortmaker
---
bsp/intel-x86/intel-x86-64.cfg | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/bsp/intel-x86/intel-x86-64.cfg
From: Paul Gortmaker
The x86-64 BSP isn't quite the same as the "more specific" BSP like a
Beaglebone Black or the (now deleted) Edgerouter. Where we have exact
hardware specifics for boards like those, the x86-64 BSP is more of a
"generic" thing used as the baseline across an endless sea of boa
[Re: [linux-yocto] [V2-revised] Microchip polarfire SoC - yocto-kernel-cache &
linux-yocto V2 patch.] On 16/11/2023 (Thu 18:24) Kadambathur Subramaniyam,
Saravanan via lists.yoctoproject.org wrote:
> Hi Bruce,
> We have two requests, first one is for linux-yocto and the second one is for
> Yocto
[[linux-yocto][v5.10/standard/preempt-rt/base][PATCH] fix linux-yocto-rt
compile error] On 22/10/2023 (Sun 19:21) Li Wang via lists.yoctoproject.org
wrote:
> kernel-source/include/net/sch_generic.h:198:17: error: implicit
> declaration of function 'raw_write_seqcount_t_begin'; did you mean
> 'ra
[[linux-yocto] [PATCH] kernel/sched: Fix double free on invalid
isolcpus/nohz_full params] On 17/08/2023 (Thu 10:56) Adrian Cinal via
lists.yoctoproject.org wrote:
> A previous patch left behind a redundant call to free_bootmem_cpumask_var
> possibly leading to a double free (once in the if-bran
[Re: [linux-yocto] [PATCH] kernel/sched: Fix uninitialized read in
nohz_full/isolcpus setup] On 26/06/2023 (Mon 11:05) Paul Gortmaker wrote:
> [[linux-yocto] [PATCH] kernel/sched: Fix uninitialized read in
> nohz_full/isolcpus setup] On 25/06/2023 (Sun 18:50) Adrian Cinal via
> lists.yoctoproje
[[linux-yocto] [PATCH] kernel/sched: Fix uninitialized read in
nohz_full/isolcpus setup] On 25/06/2023 (Sun 18:50) Adrian Cinal via
lists.yoctoproject.org wrote:
> Fix reading uninitialized cpumask and using it to validate the nohz_full=
> and isolcpus= kernel command line parameters.
>
> An ol
[[linux-yocto] Trial merge of v5.15.111 v6.1.28 for linux-yocto] On 12/05/2023
(Fri 10:19) Kevin Hao via lists.yoctoproject.org wrote:
> Hi Bruce,
>
> This is a trial merge of the stable kernel v5.15.111 v6.1.28 for the
> following branches in the linux-yocto.
[...]
> This is a much bigger st
29 matches
Mail list logo
