Re: Boot regression: arm64: WARNING: kernel/sched/core.c:10851 at sched_change_end

[Mark Rutland <mark.rutland@arm.com>]

On Wed, Dec 17, 2025 at 12:41:39AM +0530, Naresh Kamboju wrote:
> Hi Mark,

Hi Naresh,

Sorry for the prior reply being a little blunt, and thanks for the good
natured reply; I've tried to provide some more constructive notes below.
:)

> On Tue, 16 Dec 2025 at 22:53, Mark Rutland <mark.rutland@arm.com> wrote:
> >
> > On Tue, Dec 16, 2025 at 05:09:52PM +0530, Naresh Kamboju wrote:
> > > The following boot warning is noticed on qemu-arm64 devices booting
> > > Linux next-20251215 on wards.

> > > - New regression? yes
> > > - Reproducibility? yes
> > >
> > > First seen on next-20251215
> > > Bad:  next-20251215 and next-20251216
> > > Good: next-20251212
> > >
> > > Boot regression: arm64: WARNING: kernel/sched/core.c:10851 at sched_change_end

> > The warning you quote should be the *FIRST* line after you mention "The
> > following boot warning".
> >
> > That should be quoted *exactly* as the kernel logged it, without being
> > prefixed by "Boot regression: arm64:", which the kernel didn't log, and
> > which is redundant given the title and surrounding context.
> 
> The additional prefixes were introduced for internal statistics
> tracking and report classification purposes. However, I acknowledge
> that they reduced clarity in this case.

That's fair enough. My key complaint here is just that the initial
message had:

| The following boot warning is noticed on qemu-arm64 devices booting
| Linux next-20251215 onwards.
|
| [ several lines that are not the warning ]
|
| Boot regression: arm64: WARNING: kernel/sched/core.c:10851 at sched_change_end

... where a reader has to skim through all the irrelevant lines, and
then it's not clear that the line beginning with "Boot regression:
arm64:" was the actual warning.

Whereas if that were formatted something like:

| The following boot warning is noticed on qemu-arm64 devices booting
| Linux next-20251215 onwards:
|
|   WARNING: kernel/sched/core.c:10851 at sched_change_end
|
| Note: full splat at the end of this mail.
|
| The testing system has characterized this as follows:
|
| - Architecture: arm64
| - Failure: Boot regression
| - New regression? yes
| - Reproducible? yes
| - First seen on next-20251215
| - Bad:  next-20251215 and next-20251216
| - Good: next-20251212
| - Some other attribute: foo
| - Yet another attribute: bar

... it'd be much easier for a reviewer to spot the exact warning, since
it's up-front, where they'd expect it, and exactly matching what the
kernel output, without any additional notes.

All the metadata being grouped together after that makes it easier for
someone to skip over it when they don't need it.

[...]

> > > [   14.696414] ------------[ cut here ]------------
> > > [   14.696418] WARNING: kernel/sched/core.c:10851 at sched_change_end+0x168/0x188, CPU#12: ktimers/12/117
> > > [   14.729321] Modules linked in: cppc_cpufreq(+) arm_dsu_pmu(+) fuse drm backlight
> > > [   14.736718] CPU: 12 UID: 0 PID: 117 Comm: ktimers/12 Not tainted 6.19.0-rc1-next-20251216 #1 PREEMPT_RT
> > > [   14.746190] Hardware name: WIWYNN Mt.Jade Server System B81.030Z1.0010/Mt.Jade Motherboard, BIOS 2.10.20250506-1P (SCP: 2.10.20250506) 2025/05/06
> >
> > This doesn't look like a "qemu-arm64 device" to me. Are you *sure* this
> > wasn't bare-metal on a "WIWYNN Mt.Jade Server System"?
> >
> > If not, why is QEMU passing that gunk to the guest!?
> 
> Apologies for the confusion regarding the platform identification.
> This warning was reproduced on both qemu-arm64 and Mt. Jade.
> The log is from the Mt. Jade system.

Cool; thanks for confirming!

Mark.