On Sat, 2023-11-11 at 10:54 +0100, Pavel Machek wrote:
> Hi!
>
> > I'm pleased to announce the 5.10.199-rt97 stable release.
> >
> > This release is an update to the new stable 5.10.199 version and no
> > RT-specific changes were made, with the exception of a fix to a build
> > failure due to
The following commit has been merged into the x86/urgent branch of tip:
Commit-ID: 5849cdf8c120e3979c57d34be55b92d90a77a47e
Gitweb:
https://git.kernel.org/tip/5849cdf8c120e3979c57d34be55b92d90a77a47e
Author:Mike Galbraith
AuthorDate:Fri, 16 Apr 2021 14:02:07 +02:00
On Fri, 2021-04-16 at 23:44 +0200, Thomas Gleixner wrote:
>
> Can all of you involved stop this sandpit fight and do something useful
> to fix that obvious bug already?
?? We're not fighting afaik. Boris hated my changelog enough to offer
to write a better one, and I'm fine with that. It's a
On Fri, 2021-04-16 at 16:44 +0200, Borislav Petkov wrote:
> On Fri, Apr 16, 2021 at 03:16:07PM +0200, Mike Galbraith wrote:
> > On Fri, 2021-04-16 at 14:16 +0200, Borislav Petkov wrote:
> > >
> > > Please be more verbose and structure your commit message like thi
[6.343387] BUG: KASAN: slab-out-of-bounds in
acpi_cppc_processor_probe+0x15c/0xa50
[6.343474] Read of size 4 at addr 888120cf1630 by task swapper/0/1
[6.343565] CPU: 1 PID: 1 Comm: swapper/0 Tainted: G I
5.12.0.g8b1fdf9-tip #2
[6.343654] Hardware name: HP HP
On Fri, 2021-04-16 at 14:16 +0200, Borislav Petkov wrote:
>
> Please be more verbose and structure your commit message like this:
Hrmph, I thought it was too verbose for dinky one-liner if anything. I
showed the complaint along with an 8x10 color glossy crime scene photo,
then explained why it
er region */
326 start = image->arch.elf_load_addr;
(gdb)
Append missing struct crash_mem_range to cmem.
Signed-off-by: Mike Galbraith
---
arch/x86/kernel/crash.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/arch/x86/kernel/crash.c
+++ b/arch/x86/kernel/crash
On Fri, 2021-04-16 at 19:07 +0800, Dave Young wrote:
>
> > We're excluding two ranges, allocate the scratch space we need to do that.
>
> I think 1 range should be fine, have you tested 1?
Have now, and vzalloc(struct_size(cmem, ranges, 1)) worked just fine.
-Mike
On Wed, 2021-04-14 at 07:26 +0200, Dmitry Vyukov wrote:
>
> > [ 15.428008]
> > ==
> > [ 15.428011] BUG: KASAN: vmalloc-out-of-bounds in
> > crash_setup_memmap_entries+0x17e/0x3a0
>
> This looks like a genuine kernel bug on first
d;
323 cmem->nr_ranges = 1;
324
325 /* Exclude elf header region */
326 start = image->arch.elf_load_addr;
(gdb)
We're excluding two ranges, allocate the scratch space we need to do that.
Signed-off-by: Mike Galbraith
---
arch/x86/kernel/crash.c |2 +-
1
On Wed, 2021-04-14 at 08:15 +0200, Mike Galbraith wrote:
> On Wed, 2021-04-14 at 07:26 +0200, Dmitry Vyukov wrote:
> > On Wed, Apr 14, 2021 at 6:00 AM Mike Galbraith wrote:
> >
> > > [0.692437] BUG: sleeping function called from invalid context at
> >
On Wed, 2021-04-14 at 07:29 +, Zhang, Qiang wrote:
>
> if CONFIG_PREEMPT_RT is enabled and but not in preemptible, the prealloc
> should be allowed
No, you can't take an rtmutex when not preemptible.
-Mike
On Wed, 2021-04-14 at 07:26 +0200, Dmitry Vyukov wrote:
> On Wed, Apr 14, 2021 at 6:00 AM Mike Galbraith wrote:
>
> > [0.692437] BUG: sleeping function called from invalid context at
> > kernel/locking/rtmutex.c:943
> > [0.692439] in_atomic(): 1, irqs_disabled():
f8 f8 f8
f8
[ 15.428169] ^
[ 15.428171] c9426080: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8
f8
[ 15.428172] c9426100: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8
f8
[ 15.428173]
======
[ 15.4281
On Fri, 2021-03-26 at 16:20 -0500, Andrew Halaney wrote:
> Hi,
>
> I booted the RT kernel (v5.12-rc3-rt3) with KASAN enabled for the first
> time today and noticed this:
That should probably be one of the auto-disabled config options. I
started down the fix the KASAN gripes path, and quickly
On Sun, 2021-03-21 at 08:46 +0100, Mike Galbraith wrote:
> On Sat, 2021-03-20 at 09:18 +0100, Mike Galbraith wrote:
> > On Fri, 2021-03-19 at 23:33 +0100, Sebastian Andrzej Siewior wrote:
> > > Dear RT folks!
> > >
> > > I'm pleased to announce the v5.12-rc3-rt
On Sat, 2021-03-20 at 09:18 +0100, Mike Galbraith wrote:
> On Fri, 2021-03-19 at 23:33 +0100, Sebastian Andrzej Siewior wrote:
> > Dear RT folks!
> >
> > I'm pleased to announce the v5.12-rc3-rt3 patch set.
>
> My little rpi4b is fairly unhappy with 5.12-rt, w
On Fri, 2021-03-19 at 23:33 +0100, Sebastian Andrzej Siewior wrote:
> Dear RT folks!
>
> I'm pleased to announce the v5.12-rc3-rt3 patch set.
My little rpi4b is fairly unhappy with 5.12-rt, whereas 5.11-rt works
fine on it. The below spew is endless, making boot endless. I turned
it into a
On Fri, 2021-03-19 at 17:15 +0800, 王擎 wrote:
> >> On Fri, 2021-03-19 at 10:59 +0800, Wang Qing wrote:
> >> > Using wake_up_process() is more simpler and friendly,
> >> > and it is more convenient for analysis and statistics
> >>
> >> I likely needn't bother, and don't have a NAK to paste on this
On Fri, 2021-03-19 at 06:21 +0100, Mike Galbraith wrote:
> On Fri, 2021-03-19 at 10:59 +0800, Wang Qing wrote:
> > Using wake_up_process() is more simpler and friendly,
> > and it is more convenient for analysis and statistics
>
> I likely needn't bother, and don'
On Fri, 2021-03-19 at 10:59 +0800, Wang Qing wrote:
> Using wake_up_process() is more simpler and friendly,
> and it is more convenient for analysis and statistics
I likely needn't bother, and don't have a NAK to paste on this thing,
but here's another copy of my NOPE for yet another gratuitous
On Thu, 2021-03-18 at 10:14 +0800, 王擎 wrote:
> >>
> >> * Mike Galbraith wrote:
> >>
> >> > On Tue, 2021-03-16 at 19:20 +0800, Wang Qing wrote:
> >> > > Why not just use wake_up_process().
> >> >
> >> > IMO this is
On Wed, 2021-03-17 at 10:46 +0100, Ingo Molnar wrote:
> * Mike Galbraith wrote:
>
> > On Tue, 2021-03-16 at 19:20 +0800, Wang Qing wrote:
> > > Why not just use wake_up_process().
> >
> > IMO this is not an improvement. There are other places where explici
On Tue, 2021-03-16 at 19:59 +0800, Wang Qing wrote:
> This function just puts wait into queue, and does not do an operation similar
> to prepare_to_wait() in wait.c.
> And during the operation, the caller needs to hold the lock to protect.
I see zero benefit to churn like this. You're taking a
On Tue, 2021-03-16 at 19:20 +0800, Wang Qing wrote:
> Why not just use wake_up_process().
IMO this is not an improvement. There are other places where explicit
TASK_NORMAL is used as well, and they're all perfectly clear as is.
> Signed-off-by: Wang Qing
> ---
> kernel/sched/swait.c | 2 +-
>
On Mon, 2021-03-15 at 09:53 +0100, Mike Galbraith wrote:
> On Mon, 2021-03-15 at 09:05 +0100, Christian König wrote:
> > Hi Mike,
> >
> > I'm pretty sure your bisection is a bit off.
>
> (huh?) Ah crap, yup, the spew from hell you plugged obliterated the
> lockdep
On Mon, 2021-03-15 at 09:05 +0100, Christian König wrote:
> Hi Mike,
>
> I'm pretty sure your bisection is a bit off.
(huh?) Ah crap, yup, the spew from hell you plugged obliterated the
lockdep gripe I was grepping for as go/nogo, and off into lala land we
go.. twice.. whee :) Oh well, the
of "fixing stuff exposes other busted stuff".
On Wed, 2021-03-10 at 10:58 +0100, Mike Galbraith wrote:
> [ 29.966927] ==
> [ 29.966929] WARNING: possible circular locking dependency detected
> [ 29.966932] 5.12.0.g05a59d7-mast
Box is aging i4790 box w. GTX980+nouveau.
[2.833432] [ cut here ]
[2.833448] unexpected static_call insn opcode 0xe9 at
drm_gem_check_release_pagevec+0x2a/0x30 [drm]
[2.833505] WARNING: CPU: 2 PID: 329 at arch/x86/kernel/static_call.c:77
[ 29.966927] ==
[ 29.966929] WARNING: possible circular locking dependency detected
[ 29.966932] 5.12.0.g05a59d7-master #2 Tainted: GW E
[ 29.966934] --
[ 29.966937] X/2145
On Thu, 2021-03-04 at 19:47 +0100, Thomas Gleixner wrote:
> On Thu, Mar 04 2021 at 10:12, Mike Galbraith wrote:
> > On Mon, 2021-03-01 at 18:29 +0100, Ben Hutchings wrote:
> >
> > --- a/kernel/futex.c
> > +++ b/kernel/futex.c
> > @@ -874,8 +874,12 @@ static
On Thu, 2021-03-04 at 14:11 +0100, Greg Kroah-Hartman wrote:
> On Thu, Mar 04, 2021 at 10:12:56AM +0100, Mike Galbraith wrote:
>
> > futex: fix 4.4-stable 34c8e1c2c025 backport inspired lockdep complaint
> >
> > 1. 34c8e1c2c025 "futex: Provide and use pi_state_update
camper again.
futex: fix 4.4-stable 34c8e1c2c025 backport inspired lockdep complaint
1. 34c8e1c2c025 "futex: Provide and use pi_state_update_owner()" was backported
to stable, leading to the therein assertion that pi_state->pi_mutex.wait_lock
be held triggering in 4.4-stable. Fixing that
On Wed, 2021-02-10 at 16:34 +0100, Christian König wrote:
> Any objections that I add a Reported-and-tested-by: Mike Galbraith
> ?
Fine by me.
-Mike
On Wed, 2021-02-10 at 14:26 +0100, Christian König wrote:
>
> Am 10.02.21 um 13:22 schrieb Mike Galbraith:
> > On Wed, 2021-02-10 at 12:44 +0100, Christian König wrote:
> >> Please try to add a "return NULL" at the beginning of ttm_pool_type_take().
> >>
&g
On Wed, 2021-02-10 at 12:44 +0100, Christian König wrote:
> Please try to add a "return NULL" at the beginning of ttm_pool_type_take().
>
> That should effectively disable using the pool.
That did away with the yield looping, but it doesn't take long for the
display to freeze. I ssh'd in from
On Wed, 2021-02-10 at 11:52 +0100, Christian König wrote:
>
>
> You could try to replace the "for (order = min(MAX_ORDER - 1UL,
> __fls(num_pages)); num_pages;" in ttm_pool_alloc() with "for (order = 0;
> num_pages;" to get the old behavior.
That's a nogo too.
-Mike
On Wed, 2021-02-10 at 11:42 +0100, Christian König wrote:
>
> Am 10.02.21 um 11:40 schrieb Mike Galbraith:
> > On Wed, 2021-02-10 at 11:34 +0100, Christian König wrote:
> >> Hi Mike,
> >>
> >> do you have more information than just system stuck in a
On Wed, 2021-02-10 at 11:34 +0100, Christian König wrote:
>
> What seems to happen here is that your system is low on resources and we
> just try to free up pages.
FWIW, box has oodles generic ram free right after boot.
-Mike
On Wed, 2021-02-10 at 11:34 +0100, Christian König wrote:
> Hi Mike,
>
> do you have more information than just system stuck in a loop?
No, strace shows no syscalls but sched_yield().
-Mike
Greetings,
The symptom is tasks stuck waiting for lord knows what by calling
sched_yield() in a loop (less than wonderful, sched_yield() sucks).
After boot to KDE login, I immediately see tracker-extract chewing cpu
in aforementioned loop. Firing up evolution and poking 'new' to
compose,
On Tue, 2021-02-09 at 17:19 +0100, Peter Zijlstra wrote:
> On Tue, Feb 09, 2021 at 05:13:15PM +0100, Peter Zijlstra wrote:
> > On Tue, Feb 09, 2021 at 05:05:14PM +0100, Mike Galbraith wrote:
> >
> > > ld: init/main.o: in function `trace_initcall_start':
> > > /back
On Tue, 2021-02-09 at 17:13 +0100, Peter Zijlstra wrote:
> On Tue, Feb 09, 2021 at 05:05:14PM +0100, Mike Galbraith wrote:
>
> > ld: init/main.o: in function `trace_initcall_start':
> > /backup/usr/local/src/kernel/linux-tip-rt/./include/trace/events/initcall.h:27:
> &
On Tue, 2021-02-09 at 16:13 +0100, Peter Zijlstra wrote:
> On Tue, Feb 09, 2021 at 02:45:37PM +0100, Mike Galbraith wrote:
> >
> > PREEMPT_RT and PREEMPT both needs PREEMPT_DYNAMIC to build, so move
> > selection of PREEMPT_DYNAMIC to the common denominator, PREEMPTION.
>
&
PREEMPT_RT and PREEMPT both needs PREEMPT_DYNAMIC to build, so move
selection of PREEMPT_DYNAMIC to the common denominator, PREEMPTION.
Signed-off-by: Mike Galbraith
---
kernel/Kconfig.preempt |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/kernel/Kconfig.preempt
+++ b/kernel
On Sun, 2020-12-20 at 21:20 +, Song Bao Hua (Barry Song) wrote:
>
> > -Original Message-
> > From: Mike Galbraith [mailto:efa...@gmx.de]
> > Sent: Sunday, December 20, 2020 8:48 PM
> > To: Vitaly Wool ; LKML
> > ; linux-mm
> > Cc: Song Bao Hu
On Sun, 2020-12-20 at 02:23 +0100, Mike Galbraith wrote:
> On Sun, 2020-12-20 at 02:22 +0200, Vitaly Wool wrote:
> > zsmalloc takes bit spinlock in its _map() callback and releases it
> > only in unmap() which is unsafe and leads to zswap complaining
> > about schedul
On Sun, 2020-12-20 at 02:23 +0100, Mike Galbraith wrote:
> On Sun, 2020-12-20 at 02:22 +0200, Vitaly Wool wrote:
> > zsmalloc takes bit spinlock in its _map() callback and releases it
> > only in unmap() which is unsafe and leads to zswap complaining
> > about schedul
On Sun, 2020-12-20 at 02:22 +0200, Vitaly Wool wrote:
> zsmalloc takes bit spinlock in its _map() callback and releases it
> only in unmap() which is unsafe and leads to zswap complaining
> about scheduling in atomic context.
>
> To fix that and to improve RT properties of zsmalloc, remove that
>
On Sun, 2020-12-20 at 02:22 +0200, Vitaly Wool wrote:
> zsmalloc takes bit spinlock in its _map() callback and releases it
> only in unmap() which is unsafe and leads to zswap complaining
> about scheduling in atomic context.
>
> To fix that and to improve RT properties of zsmalloc, remove that
>
(CC zsmalloc maintainers)
On Sat, 2020-12-19 at 11:59 +0100, Mike Galbraith wrote:
> On Sat, 2020-12-19 at 11:46 +0100, Vitaly Wool wrote:
> > On Sat, 19 Dec 2020, 11:27 Mike Galbraith, wrote:
> >
> > > The kernel that generated that splat was NOT an RT kernel, it was
On Sat, 2020-12-19 at 11:46 +0100, Vitaly Wool wrote:
> On Sat, 19 Dec 2020, 11:27 Mike Galbraith, wrote:
>
> > The kernel that generated that splat was NOT an RT kernel, it was plain
> > master.today with a PREEMPT config.
>
>
> I see, thanks. I don't think it makes
On Sat, 2020-12-19 at 11:20 +0100, Vitaly Wool wrote:
> Hi Mike,
>
> On Sat, Dec 19, 2020 at 11:12 AM Mike Galbraith wrote:
> >
> > (mailer partially munged formatting? resend)
> >
> > mm/zswap: fix zswap_frontswap_load() vs zsmalloc::map/unmap() might_sleep(
in zswap_frontswap_store().
Signed-off-by: Mike Galbraith
Fixes: 1ec3b5fe6eec "mm/zswap: move to use crypto_acomp API for hardware
acceleration"
---
mm/zswap.c |6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
--- a/mm/zswap.c
+++ b/mm/zswap.c
@@ -1258,20 +1258,20 @@
m/zswap: fix zswap_frontswap_load() vs zsmalloc::map/unmap() might_sleep()
splat
zsmalloc map/unmap methods use preemption disabling bit spinlocks.
Take the
mutex outside of pool map/unmap methods in zswap_frontswap_load() as is done
in zswap_frontswap_store().
Signed-off-by: Mike Galbraith
Fixes: 1ec3
On Fri, 2020-12-18 at 05:45 +1000, David Airlie wrote:
> Does the attached patch help?
Yup, that seems to have done the trick. Fast bug squashing by the drm
guys today, two slowly bisected, two quickly squashed.
-Mike
On Thu, 2020-12-17 at 17:38 +0100, Christian König wrote:
>
> Mike can you test the attached patch?
Yup, one-liner made it all better. That was quick like bunny.
-Mike
On Thu, 2020-12-17 at 17:24 +0100, Christian König wrote:
> Hi Mike,
>
> what exactly is the warning from qxl you are seeing?
[1.815561] WARNING: CPU: 7 PID: 355 at drivers/gpu/drm/ttm/ttm_pool.c:365
ttm_pool_alloc+0x41b/0x540 [ttm]
[1.815561] Modules linked in: ext4(E) crc16(E)
ee5d2a8e549e90325fcc31825269f89647cd6fac is the first bad commit
commit ee5d2a8e549e90325fcc31825269f89647cd6fac
Author: Christian König
Date: Sat Oct 24 13:10:28 2020 +0200
drm/ttm: wire up the new pool as default one v2
Provide the necessary parameters by all drivers and use the new
On Wed, 2020-12-16 at 14:31 +0100, Mike Galbraith wrote:
> When the below new to 5.11 cycle badness happens, it's time to reboot.
>
> ...
> [ 27.467260] NFSD: Using UMH upcall client tracking operations.
> [ 27.467273] NFSD: starting 90-second grace period (net f0a0)
On Wed, 2020-12-16 at 18:20 +0300, Kirill Tkhai wrote:
>
> We may consider a patch like the below till updated makedumpfile is not
> published:
It's nice to be considerate to the tool folks, but that can leave a
wake of cruft (thinks printk ringbuffer.. ew), so it's probably best to
just let it
On Wed, 2020-12-16 at 15:31 +0100, Mike Galbraith wrote:
> On Wed, 2020-12-16 at 17:23 +0300, Kirill Tkhai wrote:
> >
> > Does this regression only cause that one error message "check_release:
> > Can't get the kernel version"
> > is printed in
On Wed, 2020-12-16 at 17:23 +0300, Kirill Tkhai wrote:
>
> Does this regression only cause that one error message "check_release: Can't
> get the kernel version"
> is printed instead of another: "The kernel version is not supported."?
The thing does indeed mutter about the kernel version, with
On Wed, 2020-12-16 at 03:41 +0100, Mike Galbraith wrote:
> Little kvm works fine with nomodeset, so will be busy for a while
> bisecting two other problems that popped up here this cycle. (hohum)
>
> [1.815561] WARNING: CPU: 7 PID: 355 at drivers/gpu/drm/ttm/ttm_pool.c:365
>
On Wed, 2020-12-16 at 15:35 +0300, Kirill Tkhai wrote:
> Hi, Alexander,
>
> On 16.12.2020 14:02, Mike Galbraith wrote:
> > Greetings,
> >
> > With this commit, bisected and confirmed, kdump stops working here,
> > makedumpfile saying "check_release: Can't ge
When the below new to 5.11 cycle badness happens, it's time to reboot.
...
[ 27.467260] NFSD: Using UMH upcall client tracking operations.
[ 27.467273] NFSD: starting 90-second grace period (net f0a0)
[ 27.965138] Bridge firewalling registered
[ 39.096604] fuse: init (API version
Greetings,
With this commit, bisected and confirmed, kdump stops working here,
makedumpfile saying "check_release: Can't get the kernel version".
-Mike
Little kvm works fine with nomodeset, so will be busy for a while
bisecting two other problems that popped up here this cycle. (hohum)
[1.815561] WARNING: CPU: 7 PID: 355 at drivers/gpu/drm/ttm/ttm_pool.c:365
ttm_pool_alloc+0x41b/0x540 [ttm]
[1.815561] Modules linked in: ext4(E) crc16(E)
On Mon, 2020-12-14 at 13:33 +0100, Sebastian Andrzej Siewior wrote:
> On 2020-12-08 23:58:27 [+], Orivej Desh wrote:
> > Greetings!
> Hi,
>
> > With sched-Add-migrate_disable.patch first released in v5.9-rc8-rt14 [1]
> > linux-rt defines functions migrate_disable and migrate_enable.
> > They
isable bottom half while acquiring
listening_hash.lock. There are still two callers left which disable
bottom half before the lock is acquired.
Drop local_bh_disable() around __inet_hash() which acquires
listening_hash->lock, invoke inet_ehash_nolisten() with disabled BH.
inet_unhash() con
On Wed, 2020-12-09 at 07:13 +0100, Mike Galbraith wrote:
> On Wed, 2020-12-09 at 00:26 +0100, Vitaly Wool wrote:
> > Hi Mike,
> >
> > On 2020-12-07 16:41, Mike Galbraith wrote:
> > > On Mon, 2020-12-07 at 16:21 +0100, Vitaly Wool wrote:
> > >> On Mon, De
On Wed, 2020-12-09 at 00:26 +0100, Vitaly Wool wrote:
> Hi Mike,
>
> On 2020-12-07 16:41, Mike Galbraith wrote:
> > On Mon, 2020-12-07 at 16:21 +0100, Vitaly Wool wrote:
> >> On Mon, Dec 7, 2020 at 1:34 PM Mike Galbraith wrote:
> >>>
> >>
&
On Mon, 2020-12-07 at 16:21 +0100, Vitaly Wool wrote:
> On Mon, Dec 7, 2020 at 1:34 PM Mike Galbraith wrote:
> >
>
> > Unfortunately, that made zero difference.
>
> Okay, I suggest that you submit the patch that changes read_lock() to
> write_lock() in __release
On Mon, 2020-12-07 at 12:52 +0100, Vitaly Wool wrote:
>
> Thanks. This trace beats me because I don't quite get how this could
> have happened.
I swear there's a mythical creature loose in there somewhere ;-)
Everything looks just peachy up to the instant it goes boom, then you
find in the
On Mon, 2020-12-07 at 02:05 +0100, Vitaly Wool wrote:
>
> Could you please try the following patch in your setup:
crash> gdb list *z3fold_zpool_free+0x527
0xc0e14487 is in z3fold_zpool_free (mm/z3fold.c:341).
336 if (slots->slot[i]) {
337
On Thu, 2020-12-03 at 14:39 +0100, Sebastian Andrzej Siewior wrote:
> On 2020-12-03 09:18:21 [+0100], Mike Galbraith wrote:
> > On Thu, 2020-12-03 at 03:16 +0100, Mike Galbraith wrote:
> > > On Wed, 2020-12-02 at 23:08 +0100, Sebastian Andrzej Siewior wrote
On Thu, 2020-12-03 at 03:16 +0100, Mike Galbraith wrote:
> On Wed, 2020-12-02 at 23:08 +0100, Sebastian Andrzej Siewior wrote:
> Looks like...
>
> d8f117abb380 z3fold: fix use-after-free when freeing handles
>
> ...wasn't completely effective...
The top two hunks seem to have
On Wed, 2020-12-02 at 23:08 +0100, Sebastian Andrzej Siewior wrote:
> On 2020-12-02 03:30:27 [+0100], Mike Galbraith wrote:
>
> > What I'm seeing is the below. rt_mutex_has_waiters() says yup we have
> > a waiter, rt_mutex_top_waiter() emits the missi
On Mon, 2020-11-30 at 17:03 +0100, Sebastian Andrzej Siewior wrote:
> On 2020-11-30 16:01:11 [+0100], Mike Galbraith wrote:
> > On Mon, 2020-11-30 at 15:52 +0100, Sebastian Andrzej Siewior wrote:
> > > How do you test this? I triggered a few oom-killer and I have here gi
On Mon, 2020-11-30 at 17:32 +0100, Sebastian Andrzej Siewior wrote:
> On 2020-11-30 17:27:17 [+0100], Mike Galbraith wrote:
> > > This just passed. It however killed my git-gc task which wasn't done.
> > > Let me try tomorrow with your config.
> >
> > FYI, I
On Mon, 2020-11-30 at 17:27 +0100, Mike Galbraith wrote:
> On Mon, 2020-11-30 at 17:03 +0100, Sebastian Andrzej Siewior wrote:
> > On 2020-11-30 16:01:11 [+0100], Mike Galbraith wrote:
> > > On Mon, 2020-11-30 at 15:52 +0100, Sebastian Andrzej Siewior wrote:
> > >
On Mon, 2020-11-30 at 17:32 +0100, Sebastian Andrzej Siewior wrote:
> On 2020-11-30 17:27:17 [+0100], Mike Galbraith wrote:
> > > This just passed. It however killed my git-gc task which wasn't done.
> > > Let me try tomorrow with your config.
> >
> > FYI, I
On Mon, 2020-11-30 at 17:03 +0100, Sebastian Andrzej Siewior wrote:
> On 2020-11-30 16:01:11 [+0100], Mike Galbraith wrote:
> > On Mon, 2020-11-30 at 15:52 +0100, Sebastian Andrzej Siewior wrote:
> > > How do you test this? I triggered a few oom-killer and I have here gi
On Mon, 2020-11-30 at 16:01 +0100, Mike Galbraith wrote:
> On Mon, 2020-11-30 at 15:52 +0100, Sebastian Andrzej Siewior wrote:
> > How do you test this? I triggered a few oom-killer and I have here git
> > gc running for a few hours now… Everything is fine.
>
> In an LTP in
On Mon, 2020-11-30 at 15:52 +0100, Sebastian Andrzej Siewior wrote:
> How do you test this? I triggered a few oom-killer and I have here git
> gc running for a few hours now… Everything is fine.
In an LTP install, ./runltp -f mm. Shortly after box starts swapping
insanely, it explodes quite
On Mon, 2020-11-30 at 14:20 +0100, Sebastian Andrzej Siewior wrote:
> On 2020-11-29 12:41:14 [+0100], Mike Galbraith wrote:
> > On Sun, 2020-11-29 at 12:29 +0100, Oleksandr Natalenko wrote:
> > >
> > > Ummm so do compressors explode under non-rt kernel in your tests a
On Sun, 2020-11-29 at 12:29 +0100, Oleksandr Natalenko wrote:
>
> Ummm so do compressors explode under non-rt kernel in your tests as
> well, or it is just -rt that triggers this?
I only tested a non-rt kernel with z3fold, which worked just fine.
-Mike
On Sun, 2020-11-29 at 10:21 +0100, Mike Galbraith wrote:
> On Sun, 2020-11-29 at 08:48 +0100, Mike Galbraith wrote:
> > On Sun, 2020-11-29 at 07:41 +0100, Mike Galbraith wrote:
> > > On Sat, 2020-11-28 at 15:27 +0100, Oleksandr Natalenko wrote:
> > > >
> > >
On Sun, 2020-11-29 at 08:48 +0100, Mike Galbraith wrote:
> On Sun, 2020-11-29 at 07:41 +0100, Mike Galbraith wrote:
> > On Sat, 2020-11-28 at 15:27 +0100, Oleksandr Natalenko wrote:
> > >
> > > > > Shouldn't the list manipulation be protected with
> >
On Sun, 2020-11-29 at 07:41 +0100, Mike Galbraith wrote:
> On Sat, 2020-11-28 at 15:27 +0100, Oleksandr Natalenko wrote:
> >
> > > > Shouldn't the list manipulation be protected with
> > > > local_lock+this_cpu_ptr instead of get_cpu_ptr+spin_lock?
> >
&
On Sat, 2020-11-28 at 15:27 +0100, Oleksandr Natalenko wrote:
>
> > > Shouldn't the list manipulation be protected with
> > > local_lock+this_cpu_ptr instead of get_cpu_ptr+spin_lock?
>
> Totally untested:
Hrm, the thing doesn't seem to care deeply about preemption being
disabled, so adding
[15561.391527] [ cut here ]
[15561.391560] WARNING: CPU: 0 PID: 20957 at
drivers/gpu/drm/nouveau/nvif/vmm.c:71 nvif_vmm_put+0x4a/0x50 [nouveau]
[15561.391562] Modules linked in: nls_utf8(E) isofs(E) fuse(E) msr(E)
xt_comment(E) br_netfilter(E) xt_physdev(E)
On Sat, 2020-11-14 at 13:24 -0600, Tom Zanussi wrote:
> On Sat, 2020-11-14 at 20:00 +0100, Mike Galbraith wrote:
>
> > __raw_write_seqcount_end() is an integral part of write_sequnlock(),
> > but we do seem to be missing a seqcount_release() in 5.4-rt.
> >
>
>
On Fri, 2020-11-13 at 14:14 -0600, Tom Zanussi wrote:
>
> This patch seems to fix it for me:
If there was any discussion about this patch, I missed it.
> From 4855377d0cb34b1b67a5c6d84cc8609c9da0bc3e Mon Sep 17 00:00:00 2001
> Message-Id:
>
The following commit has been merged into the locking/urgent branch of tip:
Commit-ID: 9f5d1c336a10c0d24e83e40b4c1b9539f7dba627
Gitweb:
https://git.kernel.org/tip/9f5d1c336a10c0d24e83e40b4c1b9539f7dba627
Author:Mike Galbraith
AuthorDate:Wed, 04 Nov 2020 16:12:44 +01:00
On Fri, 2020-11-06 at 21:26 +, tip-bot2 for Mike Galbraith wrote:
>
> ---
> kernel/futex.c | 16 ++--
> 1 file changed, 14 insertions(+), 2 deletions(-)
>
> diff --git a/kernel/futex.c b/kernel/futex.c
> index f8614ef..7406914 100644
> --- a/kernel/futex.
The following commit has been merged into the locking/urgent branch of tip:
Commit-ID: 63c1b4db662a0967dd7839a2fbaa5300e553901d
Gitweb:
https://git.kernel.org/tip/63c1b4db662a0967dd7839a2fbaa5300e553901d
Author:Mike Galbraith
AuthorDate:Wed, 04 Nov 2020 16:12:44 +01:00
On Thu, 2020-11-05 at 19:02 +0100, Rafael J. Wysocki wrote:
> On Thursday, November 5, 2020 4:08:30 PM CET Mike Galbraith wrote:
> > On Thu, 2020-11-05 at 15:31 +0100, Rafael J. Wysocki wrote:
> > > On Monday, November 2, 2020 7:18:41 AM CET Mike Galbraith wrote:
> > &
On Thu, 2020-11-05 at 15:31 +0100, Rafael J. Wysocki wrote:
> On Monday, November 2, 2020 7:18:41 AM CET Mike Galbraith wrote:
>
> > Desktop box did, it gained a working ondemand, while its previously
> > working powersave went broke.
>
> Most likely that's because it was
On Wed, 2020-11-04 at 16:12 +0100, Thomas Gleixner wrote:
> From: Mike Galbraith
Hrmph. How about a suggested-by, or just take it. That dinky diag hit
the mark (not _entirely_ by accident, but..;) is irrelevant, you did
all of the work to make it a patch.
-Mike
> Gratian m
1 - 100 of 5828 matches
Mail list logo
