From: "Rafael J. Wysocki" <rafael@kernel.org>
To: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Cc: "Rafael J. Wysocki" <rafael@kernel.org>,
Zhang Rui <rui.zhang@intel.com>,
Robert Moore <robert.moore@intel.com>,
Erik Kaneda <erik.kaneda@intel.com>,
"Rafael J. Wysocki" <rafael.j.wysocki@intel.com>,
Len Brown <lenb@kernel.org>, Thomas Gleixner <tglx@linutronix.de>,
Peter Zijlstra <peterz@infradead.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
ACPI Devel Maling List <linux-acpi@vger.kernel.org>,
Stephen Berman <stephen.berman@gmx.net>,
"open list:ACPI COMPONENT ARCHITECTURE (ACPICA)"
<devel@acpica.org>
Subject: Re: power-off delay/hang due to commit 6d25be57 (mainline)
Date: Tue, 11 Aug 2020 16:02:17 +0200 [thread overview]
Message-ID: <CAJZ5v0jy08XwTRUwHwjQ-UgHhi=j80q9SW2_ze1J0RiArTRKsw@mail.gmail.com> (raw)
In-Reply-To: <20200811102735.yifejbx62ewzpfcs@linutronix.de>
On Tue, Aug 11, 2020 at 12:27 PM Sebastian Andrzej Siewior
<bigeasy@linutronix.de> wrote:
>
> On 2020-07-14 17:53:15 [+0200], Rafael J. Wysocki wrote:
> > acpi_evaluate_integer() doesn't show up in the trace, though, AFAICS.
> >
> > > I assumed acpi_ex_opcode_2A_0T_0R() since the other
> > > candidate was acpi_ev_asynch_execute_gpe_method().
> >
> > Which probably is the case. Specifically
> >
> > acpi_ev_asynch_execute_gpe_method: Evaluate _L66
> >
> > is likely to cause the Notify() to be dispatched.
> …
> > > Rafael, are you also interested in an ACPI dump?
> >
> > That might help a bit.
> >
> > So what probably happens is that poking at the TZ causes a GPE to
> > trigger and a Notify() to be dispatched which then goes into the
> > workqueue for execution.
> >
> > Now, I'm not sure what happens to those Notify() items, though. They
> > each should cause a handler (in the thermal driver) to be executed,
> > but does that happen?
>
> Stephen's trace contains a few backtraces, all of them look like this:
>
> | Call Trace:
> | acpi_ex_opcode_2A_0T_0R+0x93/0xdf
> | acpi_ds_exec_end_op+0x10d/0x701
> | acpi_ps_parse_loop+0x7f2/0x8c3
> | acpi_ps_parse_aml+0x1a5/0x540
> | acpi_ps_execute_method+0x1fe/0x2ba
> | acpi_ns_evaluate+0x345/0x4e2
> | acpi_evaluate_object+0x177/0x39f
> | acpi_evaluate_integer+0x4f/0x110
> | acpi_thermal_get_temperature.part.0+0x45/0xc4
> | thermal_get_temp.cold+0xc/0x2e
> | thermal_zone_get_temp+0x4c/0x70
> | thermal_zone_device_update.part.0+0x2a/0x110
> | acpi_thermal_notify+0xcf/0x140
> | acpi_ev_notify_dispatch+0x45/0x5a
> | acpi_os_execute_deferred_notify+0x34/0x60
This is Notify () processing.
The handler is acpi_thermal_notify() which calls acpi_thermal_check()
which is just a wrapper around thermal_zone_device_update() doing
update_temperature() and that calls thermal_zone_get_temp() (among
other things) which invokes the ->get_temp() callback for the target
thermal zone.
In the ACPI thermal driver the ->get_temp callback is
thermal_get_temp() which basically calls
acpi_thermal_get_temperature() and that evaluates _TMP (for the target
thermal zone).
It looks like on the machine in question the _TMP method contains
another Notify () targeting the same thermal zone which gets queued up
via the acpi_ex_opcode_2A_0T_0R() at the top. Obviously that Notify
() (when it gets executed) will cause acpi_thermal_notify() to be
executed again and so on, ad infinitum unless the Notify () in _TMP is
conditional on something.
> | process_one_work+0x1d2/0x3a0
> | worker_thread+0x45/0x3c0
> | kthread+0xf6/0x130
> | ret_from_fork+0x35/0x40
>
> so no GPE and it comes the notify callback while parsing the ACPI table.
Right.
> Any ideas? I guess acpi_ex_opcode_2A_0T_0R() uses the workqueue because
> it may sleep and it might be invoked from non-preemptible context.
No, it uses the workqueue because it queues up a Notify () which
always goes through a workqueue (kacpi_notify_wq to be precise) and
basically in order to avoid deadlocks (it runs under locks which may
need to be acquired again to handle the notification).
next prev parent reply other threads:[~2020-08-11 14:02 UTC|newest]
Thread overview: 42+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <87v9l65d2y.fsf@gmx.net>
[not found] ` <20200513220428.4nksinis2qs5dtmh@linutronix.de>
[not found] ` <87mu6aurfn.fsf@gmx.net>
[not found] ` <20200522164012.ynyvrjompv42jtmx@linutronix.de>
[not found] ` <87y2owwo2o.fsf@rub.de>
[not found] ` <20200609202339.cgy57twm2zdtjhje@linutronix.de>
[not found] ` <87tuzjcovq.fsf@gmx.net>
[not found] ` <20200610102514.4vdzu5u7d6vnpicn@linutronix.de>
[not found] ` <87imfyh6yx.fsf@gmx.net>
[not found] ` <87wo4dligz.fsf@gmx.net>
2020-06-12 11:01 ` power-off delay/hang due to commit 6d25be57 (mainline) Sebastian Andrzej Siewior
2020-06-14 12:12 ` Stephen Berman
2020-06-14 17:10 ` Sebastian Andrzej Siewior
2020-06-15 7:58 ` Stephen Berman
2020-06-15 14:51 ` Sebastian Andrzej Siewior
2020-06-15 15:41 ` Stephen Berman
2020-06-15 15:58 ` Sebastian Andrzej Siewior
2020-06-15 16:19 ` Stephen Berman
2020-06-15 16:32 ` Sebastian Andrzej Siewior
2020-06-16 7:14 ` Stephen Berman
2020-06-16 7:38 ` Sebastian Andrzej Siewior
2020-06-16 8:13 ` Stephen Berman
2020-06-16 15:55 ` Sebastian Andrzej Siewior
2020-06-16 20:28 ` Stephen Berman
2020-06-17 14:27 ` Sebastian Andrzej Siewior
2020-06-17 21:09 ` Stephen Berman
2020-06-24 20:11 ` Sebastian Andrzej Siewior
2020-06-24 21:49 ` Stephen Berman
2020-07-14 13:44 ` Sebastian Andrzej Siewior
2020-07-14 13:54 ` Rafael J. Wysocki
2020-07-14 14:11 ` Sebastian Andrzej Siewior
2020-07-14 15:53 ` Rafael J. Wysocki
2020-07-14 16:10 ` Sebastian Andrzej Siewior
2020-08-11 10:27 ` Sebastian Andrzej Siewior
2020-08-11 14:02 ` Rafael J. Wysocki [this message]
2020-07-19 10:07 ` Stephen Berman
2020-08-11 11:58 ` Stephen Berman
2020-08-11 13:29 ` Sebastian Andrzej Siewior
2020-08-11 14:34 ` Rafael J. Wysocki
2020-08-11 15:25 ` Sebastian Andrzej Siewior
[not found] ` <87ft8tayic.fsf@gmx.net>
2020-08-11 18:49 ` Sebastian Andrzej Siewior
2020-10-06 21:49 ` Sebastian Andrzej Siewior
2020-10-07 16:18 ` Rafael J. Wysocki
2020-10-26 17:20 ` Sebastian Andrzej Siewior
2020-12-02 18:03 ` Sebastian Andrzej Siewior
2020-12-02 18:31 ` Rafael J. Wysocki
2020-12-02 19:13 ` Rafael J. Wysocki
2020-12-31 20:46 ` Rafael J. Wysocki
2021-01-02 11:03 ` Rafael J. Wysocki
2021-01-04 15:38 ` Stephen Berman
2021-01-24 13:49 ` Stephen Berman
2021-01-25 16:25 ` Rafael J. Wysocki
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAJZ5v0jy08XwTRUwHwjQ-UgHhi=j80q9SW2_ze1J0RiArTRKsw@mail.gmail.com' \
--to=rafael@kernel.org \
--cc=bigeasy@linutronix.de \
--cc=devel@acpica.org \
--cc=erik.kaneda@intel.com \
--cc=lenb@kernel.org \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=peterz@infradead.org \
--cc=rafael.j.wysocki@intel.com \
--cc=robert.moore@intel.com \
--cc=rui.zhang@intel.com \
--cc=stephen.berman@gmx.net \
--cc=tglx@linutronix.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).