[+cc linux-acpi] On Wed, Feb 19, 2025 at 05:52:47PM +0530, Naveen Kumar P wrote:

Hi all,

I am writing to seek assistance with an issue we are experiencing with a PCIe device (PLDA Device 5555) connected through PCI Express Root Port 1 to the host bridge.

We have observed that after booting the system, the Base Address Register (BAR0) memory of this device gets reset to 0x0 after approximately one hour or more (the timing is inconsistent). This was verified using the lspci output and the setpci -s 01:00.0 BASE_ADDRESS_0 command.

To diagnose the issue, we checked the dmesg log, but it did not provide any relevant information. I then enabled dynamic debugging for the PCI subsystem (drivers/pci/*) and noticed the following messages related ACPI hotplug in the dmesg log:

[ 0.465144] pci 0000:01:00.0: reg 0x10: [mem 0xb0400000-0xb07fffff] ... [ 6710.000355] ACPI: \_SB_.PCI0.RP01: acpiphp_glue: Bus check in hotplug_event() [ 7916.250868] perf: interrupt took too long (4072 > 3601), lowering kernel.perf_event_max_sample_rate to 49000 [ 7984.719647] perf: interrupt took too long (5378 > 5090), lowering kernel.perf_event_max_sample_rate to 37000 [11051.409115] ACPI: \_SB_.PCI0.RP01: acpiphp_glue: Bus check in hotplug_event() [11755.388727] ACPI: \_SB_.PCI0.RP01: acpiphp_glue: Bus check in hotplug_event() [12223.885715] ACPI: \_SB_.PCI0.RP01: acpiphp_glue: Bus check in hotplug_event() [14303.465636] ACPI: \_SB_.PCI0.RP01: acpiphp_glue: Bus check in hotplug_event() After these messages appear, reading the device BAR memory results in 0x0 instead of the expected value.

I would like to understand the following:

1. What could be causing these hotplug_event debug messages?

This is an ACPI Notify event. Basically the platform is telling us to re-enumerate the hierarchy below RP01 because a device might have been added or removed. Unfortunately the only real information we get is the ACPI device (RP01) and the notification value (ACPI_NOTIFY_BUS_CHECK). You could instrument acpiphp_check_bridge() to see what path we take. The main paths look like enable_slot() or disable_slot(), but those both include a pr_debug() than you apparently don't see. A remove followed by add would definitely reset the device, including its BARs. But you would normally see some messages related to enumerating a new device. If this doesn't help, try to reproduce the problem with a recent kernel, e.g., v6.13, and post the complete dmesg log.

2. Why does this result in the BAR memory being reset? 3. How can we resolve this issue?

I have verified that the issue occurs even without loading the driver for the PLDA Device 5555, so it does not appear to be related to the device driver.

Any help or guidance on debugging this issue would be greatly appreciated.

Thank you for your assistance.

Best regards, Naveen