From: Bert Karwatzki <spasswolf@web.de>
To: "Christian König" <christian.koenig@amd.com>,
linux-kernel@vger.kernel.org
Cc: linux-next@vger.kernel.org, regressions@lists.linux.dev,
linux-pci@vger.kernel.org, linux-acpi@vger.kernel.org,
Mario Limonciello <superm1@kernel.org>,
"Rafael J . Wysocki" <rafael.j.wysocki@intel.com>,
spasswolf@web.de
Subject: Re: [REGRESSION 00/04] Crash during resume of pcie bridge
Date: Tue, 07 Oct 2025 08:50:30 +0200 [thread overview]
Message-ID: <93d21bb6887310d331fa67a3766e47af9669dfc3.camel@web.de> (raw)
In-Reply-To: <e60d2cf59666b6f670996bac80cb948acb1d7b5c.camel@web.de>
Am Montag, dem 06.10.2025 um 18:22 +0200 schrieb Bert Karwatzki:
>
> >
> Even versions that did crash can be stable for 24h of uptime so I think this
> will take too long.
> I think I've already chased down the crash to this part of rpm_resume()
> (I'm currently doing a testrun with more dev_info()s in this part):
>
> skip_parent:
>
> if (!strcmp(dev_name(dev), "0000:00:01.1"))
> dev_info(dev, "%s %d\n", __func__, __LINE__); // this is the last reported line in netconsole
> if (dev->power.no_callbacks)
> goto no_callback; /* Assume success. */
>
> __update_runtime_status(dev, RPM_RESUMING);
>
> callback = RPM_GET_CALLBACK(dev, runtime_resume);
>
> dev_pm_disable_wake_irq_check(dev, false);
> retval = rpm_callback(callback, dev);
> if (retval) {
> __update_runtime_status(dev, RPM_SUSPENDED);
> pm_runtime_cancel_pending(dev);
> dev_pm_enable_wake_irq_check(dev, false);
> } else {
> no_callback:
>
>
> Bert Karwatzki
The testrun is already finished the crash occured after 10h and ~700 GPP0 notifies,
the part of rpm_resume() above was monitored like this:
skip_parent:
if (!strcmp(dev_name(dev), "0000:00:01.1"))
dev_info(dev, "%s %d\n", __func__, __LINE__);
if (dev->power.no_callbacks)
goto no_callback; /* Assume success. */
if (!strcmp(dev_name(dev), "0000:00:01.1"))
dev_info(dev, "%s %d\n", __func__, __LINE__);
__update_runtime_status(dev, RPM_RESUMING);
if (!strcmp(dev_name(dev), "0000:00:01.1"))
dev_info(dev, "%s %d\n", __func__, __LINE__);
callback = RPM_GET_CALLBACK(dev, runtime_resume);
if (!strcmp(dev_name(dev), "0000:00:01.1"))
dev_info(dev, "%s %d callback = %px\n", __func__, __LINE__, (void *) callback);
dev_pm_disable_wake_irq_check(dev, false);
if (!strcmp(dev_name(dev), "0000:00:01.1"))
dev_info(dev, "%s %d\n", __func__, __LINE__); // This is the last reported line!
retval = rpm_callback(callback, dev);
if (!strcmp(dev_name(dev), "0000:00:01.1"))
dev_info(dev, "%s %d\n", __func__, __LINE__);
if (retval) {
if (!strcmp(dev_name(dev), "0000:00:01.1"))
dev_info(dev, "%s %d\n", __func__, __LINE__);
__update_runtime_status(dev, RPM_SUSPENDED);
pm_runtime_cancel_pending(dev);
dev_pm_enable_wake_irq_check(dev, false);
} else {
no_callback:
The result is that in the case of the crash rpm_callback() didn't return, so
I'll continue the investigation in rpm_callback().
The whole calltrace is:
acpiphp_check_bridge()->pm_runtime_get_sync()->__pm_runtime_resume()->rpm_resume()->rpm_callback()
Bert Karwatzki
next prev parent reply other threads:[~2025-10-07 6:51 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-10-06 12:09 [REGRESSION 00/04] Crash during resume of pcie bridge Bert Karwatzki
2025-10-06 12:09 ` [REGRESSION 01/04] " Bert Karwatzki
2025-10-06 12:09 ` [REGRESSION 02/04] " Bert Karwatzki
2025-10-06 12:09 ` [REGRESSION 03/04] " Bert Karwatzki
2025-10-06 12:09 ` [REGRESSION 04/04] " Bert Karwatzki
2025-10-06 12:39 ` [REGRESSION 00/04] " Christian König
2025-10-06 16:22 ` Bert Karwatzki
2025-10-07 6:50 ` Bert Karwatzki [this message]
2025-10-07 21:33 ` Mario Limonciello
2025-10-13 16:29 ` Bert Karwatzki
2025-10-13 18:51 ` Mario Limonciello
2025-10-14 10:50 ` Christian König
[not found] ` <1853e2af7f70cf726df278137b6d2d89d9d9dc82.camel@web.de>
2025-10-31 13:38 ` Bert Karwatzki
2025-10-31 13:47 ` Bert Karwatzki
2025-10-31 18:35 ` Bert Karwatzki
2025-11-05 11:44 ` Bert Karwatzki
2025-11-05 21:31 ` Mario Limonciello (AMD) (kernel.org)
2025-11-07 13:09 ` Bert Karwatzki
2025-11-07 17:09 ` Bert Karwatzki
2025-11-10 13:33 ` Christian König
2025-11-16 21:08 ` Crash during resume of pcie bridge due to infinite loop in ACPICA Bert Karwatzki
2025-11-17 16:40 ` Rafael J. Wysocki
2025-11-24 22:34 ` Bert Karwatzki
2025-11-25 19:46 ` Rafael J. Wysocki
2025-11-27 0:08 ` Bert Karwatzki
2025-11-27 13:02 ` Rafael J. Wysocki
2025-11-28 20:47 ` Bert Karwatzki
2025-12-02 18:59 ` Rafael J. Wysocki
2025-12-02 19:53 ` Bert Karwatzki
2025-12-02 20:01 ` Rafael J. Wysocki
2025-12-05 10:05 ` Crash during resume of pcie bridge due to incorrect error handling Bert Karwatzki
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=93d21bb6887310d331fa67a3766e47af9669dfc3.camel@web.de \
--to=spasswolf@web.de \
--cc=christian.koenig@amd.com \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-next@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=rafael.j.wysocki@intel.com \
--cc=regressions@lists.linux.dev \
--cc=superm1@kernel.org \
/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).