Hi again, everyone.
So, while preparing to file the bug report with the requested
information, I got a trace completely unrelated to DRM (on a swapon
call, it seems).
[4.868340] rcu: INFO: rcu_sched detected expedited stalls on
CPUs/tasks: { 4- } 3 jiffies s: 265 root: 0x10/.
[
Hi, Paul,
On Thu, 13 Apr 2023 at 15:43, Paul E. McKenney wrote:
>
> My guess would be that you have CONFIG_RCU_EXP_CPU_STALL_TIMEOUT set to
> some small non-zero number, for example, you might have set up a recent
> Android .config or some such. The default of zero would give you about
> 21
Hi, Paul,
On Thu, 13 Apr 2023 at 17:21, Paul E. McKenney wrote:
>
> Been there, done that!
>
> And actually, it is kind of reassuring that the Linux kernel avoids
> tens-of-milliseocnds latency blows in the common case on your system.
Especially since we're talking about a HZ=100 non-preemptive
Hi, Jani,
On Wed, 12 Apr 2023 at 10:28, Jani Nikula wrote:
>
> Please file a bug at fdo gitlab [1]. Add drm.debug=0xe and maybe
> log_buf_len=4M or similar kernel parameters, and attach dmesg all the
> way from boot to reproducing the problem.
Sure, will do, thanks!
> How long is "for some
Hi, everyone,
I apologise in advance if I've sent this to {too many, the wrong}
people. For some time now, I've been getting sporadic (in about one
out of five boots) DRM-related RCU complaints on an Ivy Bridge-based
(Core i7-3720QM) Mac Mini. Call trace (on Linux 6.3-rc6) follows:
[
