[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <fcc48e7c-cb26-4f20-8875-19e30362c3b5@arm.com>
Date: Tue, 27 Aug 2024 10:43:48 +0100
From: Hongyan Xia <hongyan.xia2@....com>
To: Peter Zijlstra <peterz@...radead.org>
Cc: mingo@...hat.com, juri.lelli@...hat.com, vincent.guittot@...aro.org,
dietmar.eggemann@....com, rostedt@...dmis.org, bsegall@...gle.com,
mgorman@...e.de, vschneid@...hat.com, linux-kernel@...r.kernel.org,
kprateek.nayak@....com, wuyun.abel@...edance.com, youssefesmat@...omium.org,
tglx@...utronix.de, efault@....de
Subject: Re: [PATCH 00/24] Complete EEVDF
On 22/08/2024 16:55, Peter Zijlstra wrote:
> On Wed, Aug 21, 2024 at 10:46:07AM +0100, Hongyan Xia wrote:
>> Okay, in case the trace I provided isn't clear enough, I traced the crash to
>> a call chain like this:
>>
>> dl_server_start()
>> enqueue_dl_entity()
>> update_stats_enqueue_dl()
>> update_stats_enqueue_sleeper_dl()
>> __schedstats_from_dl_se()
>> dl_task_of() <---------- crash
>>
>> If I undefine CONFIG_SCHEDSTATS, then it boots fine, and I wonder if this is
>> the reason why other people are not seeing this. This is probably not EEVDF
>> but DL refactoring related.
>
> Thanks for the report -- I'll see if I can spot something. Since you
> initially fingered these eevdf patches, could you confirm or deny that
> changing:
>
> kernel/sched/features.h:SCHED_FEAT(DELAY_DEQUEUE, true)
>
> to false, makes any difference in the previously failing case?
Sadly the issue persists. I'm seeing exactly the same backtrace on my
Juno board.
Powered by blists - more mailing lists