linux-kernel - Re: Linux warns `sched: DL replenish lagged too much`

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <Z7cvifR-y0CWK1e6@jlelli-thinkpadt14gen4.remote.csb>
Date: Thu, 20 Feb 2025 14:35:05 +0100
From: Juri Lelli <juri.lelli@...hat.com>
To: Paul Menzel <pmenzel@...gen.mpg.de>
Cc: Ingo Molnar <mingo@...hat.com>, Peter Zijlstra <peterz@...radead.org>,
	Vincent Guittot <vincent.guittot@...aro.org>,
	LKML <linux-kernel@...r.kernel.org>
Subject: Re: Linux warns `sched: DL replenish lagged too much`

Dear Paul,

On 20/02/25 11:47, Paul Menzel wrote:
> Dear Linux folks,
> 
> 
> On the Intel Kaby Lake laptop Dell XPS 13 with Linux
> 6.14.0-rc3-00060-g6537cfb395f3, waking it up from ACPI S3 with an LMP USB-C
> mini dock connected, that had an Ethernet cable and a power adapter plugged
> in, everything was lagging, and also the video in the opened Firefox Nightly
> browser lagged quite a bit. This has happened in the past, but not that bad
> and long. Today for the first time, Linux logged the warning below:
> 
>     sched: DL replenish lagged too much
> 
> (This is from `kernel/sched/deadline.c`.)
> 
> I have no idea, if it’s related to the hardware itself, that causes it to
> lag, that a suspend/resume cycle fixes, or if it’s related to the USB-C
> controller that has bugs in that early generation, or if it’s related to
> GNOME/Mutter (*mutter-common* 48~beta-3) or Firefox or the Web video player
> used by the site.
> 
> As often the case with this, I have no way to reliably reproduce it, and in
> this case to reproduce the warning. I can only say, that this warning has
> not been logged in the available log files since September 2024. Linux
> “6.11-rc0” was used then. Please find the log messages attached.
> 
> In case this information is not useful, should this happen again, it’d be
> great if you could suggest what and how I should collect debugging
> information next time.

Assuming no explicit usage of SCHED_DEADLINE, I would say the warning
message might be related to the recently introduced deadline servers:
5f6bd380c7bd ("sched/rt: Remove default bandwidth control") and related
commits.

They were merged in v6.12 (IIRC), though, so I would expect you had
noticed already before if they introduced issues on your setup? That
said, it might also be the case that something else changed more
recently that now triggers a corner case.

The warning message per-se it's not fatal, it just warns that the kernel
is recovering from an unexpected situation. Did you notice that things
went back to normal (no lag from a user perspective) right after that
message was printed?

Thanks,
Juri