Linux-PCI Archive on
 help / color / Atom feed
From: Bjorn Helgaas <>
To: James Ettle <>
Cc: "吳昊澄 Ricky" <>,
	"Rui Feng" <>,
	"Arnd Bergmann" <>,
	"Greg Kroah-Hartman" <>,
	"Len Brown" <>,
	"Puranjay Mohan" <>,
	"" <>,
	"" <>,
	"Jacopo De Simoi" <>
Subject: Re: rtsx_pci not restoring ASPM state after suspend/resume
Date: Mon, 27 Jul 2020 09:14:38 -0500
Message-ID: <20200727141438.GA1743062@bjorn-Precision-5520> (raw)
In-Reply-To: <>

On Sat, Jul 25, 2020 at 09:27:11PM +0100, James Ettle wrote:
> On Fri, 2020-07-24 at 18:13 -0500, Bjorn Helgaas wrote:
> > 
> > Maybe we should simplify this a little bit more.  James, if you don't
> > touch ASPM config at all, either manually or via udev, does the ASPM
> > configuration stay the same across suspend/resume?
> Yes, it stays the same. Explicitly: 
> With the udev rule disabled, immediately following clean boot from
> power-off (and no additional tinkering), ASPM is OFF to the best of my
> knowledge:
>  - link/l1_aspm in sysfs is 0 for PCI devices 0000:01:00.[01];
>  - the processor sleeps no deeper than package C3.
> The situation above is the same following a suspend/resume cycle --
> both in terms of sysfs, and observed package C-state occupancy.
> [Tested on kernel 5.7.10, but the behaviour is the same as prior
> kernels.]

I don't know the connection between ASPM and package C-states, so I
need to simplify this even more.  All I want to do right now is verify
that if we don't have any outside influences on the ASPM configuration
(eg, no manual changes and no udev rules), it stays the same across

In, we saw that
ASPM L0s was disabled before suspend but was enabled after resume.
That should not happen.

You're looking at the sysfs link/l1_aspm file, which tells us what the
PCI core thinks the state is, but I'm not confident that's accurate,
especially because the driver fiddles with the state behind the back
of the PCI core.  So let's read the ASPM state directly from the
hardware like this:

  sudo lspci -vvs 00:1d.0 | egrep "^0|Lnk|L1|LTR|snoop"
  sudo lspci -vvs 01:00   | egrep "^0|Lnk|L1|LTR|snoop"

Can you try that before and after suspend/resume?

  reply index

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-07-23 16:56 Bjorn Helgaas
2020-07-23 17:12 ` Bjorn Helgaas
2020-07-24  7:16   ` 吳昊澄 Ricky
2020-07-24 23:13     ` Bjorn Helgaas
2020-07-25 20:27       ` James Ettle
2020-07-27 14:14         ` Bjorn Helgaas [this message]
2020-07-27 19:52           ` James Ettle
2020-07-27 21:47             ` Bjorn Helgaas
2020-07-28  5:46               ` 吳昊澄 Ricky
2020-07-28 20:57               ` James Ettle
2020-07-28 23:06                 ` Bjorn Helgaas
2020-08-02 16:30                   ` James Ettle

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:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20200727141438.GA1743062@bjorn-Precision-5520 \ \ \ \ \ \ \ \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

Linux-PCI Archive on

Archives are clonable:
	git clone --mirror linux-pci/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 linux-pci linux-pci/ \
	public-inbox-index linux-pci

Example config snippet for mirrors

Newsgroup available over NNTP:

AGPL code for this site: git clone