[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20190206012214.GA25642@x220>
Date: Wed, 6 Feb 2019 09:22:14 +0800
From: tomli@...li.me
To: Aaro Koskinen <aaro.koskinen@....fi>,
"Paul E. McKenney" <paulmck@...ux.ibm.com>,
"Rafael J. Wysocki" <rafael@...nel.org>,
Ville Syrjälä
<ville.syrjala@...ux.intel.com>
Cc: ak@...ux.intel.com, bp@...en8.de, hpa@...or.com,
linux-kernel@...r.kernel.org, mingo@...hat.com, rjw@...ysocki.net,
viresh.kumar@...aro.org, linux-mips@...r.kernel.org
Subject: Re: [REGRESSION 4.20-rc1] 45975c7d21a1 ("rcu: Define RCU-sched API
in terms of RCU for Tree RCU PREEMPT builds")
> OK, thanks. This looks slightly different from the Loongson problem:
>
> - In Loongson, we don't get stuck in RCU, but in
> cpufreq_dbs_governor_stop -> irq_work_sync().
>
> - I run non-preemptible kernel, and my system still gets stuck.
>
> What is common is that it's UP with i8259 PIC.
>
> A.
Now it's an interesting case. Because on my machine, the problem I
encountered seems to be the identical one of the original thread,
disabling preempting can effectively solve the lockup. Also, my
issue is not only occuring on 4.20-rc1, but also on earlier kernels,
with a lower probability.
But on your machine, you have another non-identical, but closely-
related issue. It seems the timing-dependent lockup of i8259 PIC can
be triggered in different ways.
The conclusion is clear though, there's a real lockup condition in
i8259 PIC driver, and it's causing real issues. Aaro, have you tried
submitting your i8259 patch to the mainline? Despite your concerns
about its underlying cause, I think a fix should be submitted. If there
are no objections from the maintainers, I suggest submitting it to the
mainline upstream, and send it to linux-stable, requesting it to be
applied on 3.16, 4.4, 4.9, 4.14, 4.19, 4.20 stable branches. If you
are busy, I can help submitting.
Tom Li
Powered by blists - more mailing lists