On Tue, Mar 04, 2025 at 01:35:14PM +0530, Naveen Kumar P wrote:
On Fri, Feb 28, 2025 at 9:31 PM Bjorn Helgaas <helgaas@kernel.org> wrote:
On Wed, Feb 26, 2025 at 06:28:33PM +0530, Naveen Kumar P wrote:
On Wed, Feb 26, 2025 at 2:08 AM Bjorn Helgaas <helgaas@kernel.org> wrote:
On Tue, Feb 25, 2025 at 06:46:02PM +0530, Naveen Kumar P wrote:
On Tue, Feb 25, 2025 at 1:24 AM Bjorn Helgaas <helgaas@kernel.org> wrote:
On Tue, Feb 25, 2025 at 12:29:00AM +0530, Naveen Kumar P wrote:
On Mon, Feb 24, 2025 at 11:03 PM Bjorn Helgaas <helgaas@kernel.org> wrote:
On Mon, Feb 24, 2025 at 05:45:35PM +0530, Naveen Kumar P wrote:
On Wed, Feb 19, 2025 at 10:36 PM Bjorn Helgaas <helgaas@kernel.org> wrote:
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. ...
I have downloaded the 6.13 kernel source and added additional debug logs in hotplug_event(), then built the kernel. After that rebooted with the new kernel using the following parameters: BOOT_IMAGE=/vmlinuz-6.13.0+ root=/dev/mapper/vg00-rootvol ro quiet libata.force=noncq pci=nomsi pcie_aspm=off pcie_ports=on "dyndbg=file drivers/pci/* +p; file drivers/acpi/* +p"
Why "pci=nomsi"? I don't think that should make a difference. Also, it contributes to the fact that Linux doesn't request OS control of several features that it ordinarily does, so you end up in a somewhat unusual state (which *should* still work, of course):
acpi PNP0A08:00: _OSC: OS supports [ExtendedConfig Segments HPX-Type3] acpi PNP0A08:00: _OSC: not requesting OS control; OS requires [ExtendedConfig ASPM ClockPM MSI]
Same for "pcie_aspm=off".
I initially suspected that the PCI BAR reset was happening due to the device entering a low-power state, so I set pcie_aspm=off to prevent it.
ASPM never makes a device lose its state. It's completely invisible from a software point of view.
As per your suggestion, I instrumented the PCI configuration accessors to log all reads and writes to my device (01:00.0). The corresponding patch (0002-instrumented-the-PCI-config-accessors-to-log-all-the.patch) is attached to this email. After applying the patch and rebooting with the same boot parameters, the issue reproduced after 193890 seconds.
The complete dmesg log (dmesg_march3rd_log.txt) is also attached. Could you check if this new log provides any useful clues?
[193890.407810] ACPI: \_SB_.PCI0.RP01: ACPI: ACPI_NOTIFY_BUS_CHECK event [193890.407973] ACPI: \_SB_.PCI0.RP01: acpiphp_glue: Bridge acquired in hotplug_event() [193890.408010] ACPI: \_SB_.PCI0.RP01: acpiphp_glue: Bus check in hotplug_event() [193890.408030] ACPI: \_SB_.PCI0.RP01: acpiphp_glue: Checking bridge in hotplug_event() [193890.408052] PCI READ: res=0, bus=01 dev=00 func=0 pos=0x00 len=4 data=0x55551556 [193890.408095] PCI READ: res=0, bus=01 dev=00 func=0 pos=0x00 len=4 data=0x55551556
Looks perfectly fine. This is reading the Vendor and Device IDs.
[193890.408122] ACPI: \_SB_.PCI0.RP01: acpiphp_glue: Enabling slot in acpiphp_check_bridge() [193890.408184] ACPI: Device [PXSX] status [0000000f] [193890.408236] ACPI: Device [D015] status [0000000f] [193890.408305] ACPI: \_SB_.PCI0.RP01: acpiphp_glue: Releasing bridge in hotplug_event()