All of lore.kernel.org
 help / color / mirror / Atom feed
From: Bjorn Helgaas <helgaas@kernel.org>
To: Naveen Kumar P <naveenkumar.parna@gmail.com>
Cc: linux-pci@vger.kernel.org, linux-acpi@vger.kernel.org,
	linux-kernel@vger.kernel.org,
	kernelnewbies <kernelnewbies@kernelnewbies.org>
Subject: Re: PCI: hotplug_event: PCIe PLDA Device BAR Reset
Date: Tue, 4 Mar 2025 14:45:56 -0600	[thread overview]
Message-ID: <20250304204556.GA257201@bhelgaas> (raw)
In-Reply-To: <CAMciSVU2Xeh+3KsFK33GGLK7h59n9A_1RANdFV+ghGv39qcxPw@mail.gmail.com>

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()

_______________________________________________
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

WARNING: multiple messages have this Message-ID (diff)
From: Bjorn Helgaas <helgaas@kernel.org>
To: Naveen Kumar P <naveenkumar.parna@gmail.com>
Cc: linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org,
	kernelnewbies <kernelnewbies@kernelnewbies.org>,
	linux-acpi@vger.kernel.org
Subject: Re: PCI: hotplug_event: PCIe PLDA Device BAR Reset
Date: Tue, 4 Mar 2025 14:45:56 -0600	[thread overview]
Message-ID: <20250304204556.GA257201@bhelgaas> (raw)
In-Reply-To: <CAMciSVU2Xeh+3KsFK33GGLK7h59n9A_1RANdFV+ghGv39qcxPw@mail.gmail.com>

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()

  parent reply	other threads:[~2025-03-04 20:46 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-02-19 12:22 PCI: hotplug_event: PCIe PLDA Device BAR Reset Naveen Kumar P
2025-02-19 17:06 ` Bjorn Helgaas
2025-02-19 17:06   ` Bjorn Helgaas
2025-02-24 12:15   ` Naveen Kumar P
2025-02-24 17:33     ` Bjorn Helgaas
2025-02-24 17:33       ` Bjorn Helgaas
2025-02-24 18:59       ` Naveen Kumar P
2025-02-24 19:54         ` Bjorn Helgaas
2025-02-24 19:54           ` Bjorn Helgaas
2025-02-25 13:16           ` Naveen Kumar P
2025-02-25 20:38             ` Bjorn Helgaas
2025-02-25 20:38               ` Bjorn Helgaas
2025-02-26 12:58               ` Naveen Kumar P
2025-02-28 12:27                 ` Naveen Kumar P
2025-02-28 16:01                 ` Bjorn Helgaas
2025-03-04  8:05                   ` Naveen Kumar P
2025-03-04 16:49                     ` Naveen Kumar P
2025-03-04 21:01                       ` Bjorn Helgaas
2025-03-04 21:01                         ` Bjorn Helgaas
2025-03-04 22:44                         ` Naveen Kumar P
2025-03-10 11:23                           ` Naveen Kumar P
2025-03-11 18:04                             ` Naveen Kumar P
2025-03-18 14:07                               ` Naveen Kumar P
2025-03-04 20:45                     ` Bjorn Helgaas [this message]
2025-03-04 20:45                       ` Bjorn Helgaas
2025-03-19 14:37       ` Naveen Kumar P
2025-03-19 21:41         ` Bjorn Helgaas
2025-03-19 21:41           ` Bjorn Helgaas
2025-04-02  5:24           ` Naveen Kumar P

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=20250304204556.GA257201@bhelgaas \
    --to=helgaas@kernel.org \
    --cc=kernelnewbies@kernelnewbies.org \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=naveenkumar.parna@gmail.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.