On Mon, Feb 26, 2024 at 06:33:11PM +0100, Mathias De Weerdt wrote:
> Hi Ilpo
>
> That worked! I can now wake almost instantly from suspension.
Thanks for testing this!
I assume the sdhci_pci device (the SD card reader) worked before
suspend but does not work after wakeup, right? If so, we still need
to fix the card reader.
Your dmesg log at [1] shows:
[ 181.568485] pcieport 0000:00:1c.6: broken device, retraining non-functional downstream link at 2.5GT/s
[ 182.568501] pcieport 0000:00:1c.6: retraining failed
[ 183.801823] pcieport 0000:00:1c.6: broken device, retraining non-functional downstream link at 2.5GT/s
[ 184.801799] pcieport 0000:00:1c.6: retraining failed
...
[ 251.188524] sdhci-pci 0000:2f:00.0: not ready 65535ms after resume; giving up
[ 251.188680] sdhci-pci 0000:2f:00.0: Unable to change power state from D3cold to D0, device inaccessible
[ 251.252837] mmc0: enable PCI MSI failed, error=-22
[ 251.352851] mmc0: Reset 0x1 never completed.
[ 251.352852] mmc0: sdhci: ============ SDHCI REGISTER DUMP ===========
[ 251.352854] mmc0: sdhci: Sys addr: 0xffffffff | Version: 0x0000ffff
I found a report at [2] with the same symptom of "sdhci-pci ... Unable
to change power state from D3cold to D0, device inaccessible". That
one turned out to be a Linux problem with restoring the ASPM L1
substates configuration after resume. But I don't *think* that's what
you're seeing because:
- 4ff116d0d5fd ("PCI/ASPM: Save L1 PM Substates Capability for
suspend/resume") appeared in v6.1 and added the L1SS restore
- a7152be79b62 ("Revert "PCI/ASPM: Save L1 PM Substates Capability
for suspend/resume"") appeared in v6.2 and reverted 4ff116d0d5fd
- you're running a 6.7.6-arch1-1 kernel, and v6.7.6 doesn't appear
to have the L1SS restore code from 4ff116d0d5fd
But to make double sure, could you try manually disabling ASPM before
suspending by running these commands as root and collecting all the
output (use "script" or similar):
ROOT=00:1c.6
SD=2f:00.0
lspci -s$ROOT -vvxxxx
lspci -s$SD -vvxxxx
setpci -s$SD CAP_EXP+0x10.w=0x0000:0x0003
setpci -s$ROOT CAP_EXP+0x10.w=0x0000:0x0003
lspci -s$ROOT -vvxxxx
lspci -s$SD -vvxxxx
Then suspend, resume, and see if we still complain about putting the
sdhci-pci device in D0.
I expect the card reader probably will still not work, and if that's
the case, maybe something is wrong with power control for the 2f:00.0
sdhci-pci device, possibly a BIOS bug, e.g., BIOS knows how to put
2f:00.0 in D3cold, but doesn't know how to return it to D0.
It's possible a BIOS update could fix this, but it would be good to
know what machine and BIOS version this is so we could try to work
around this in Linux.
The dmesg log doesn't include the earliest boot messages, so I don't
know what machine this is or the BIOS version, etc. There should be a
complete boot-time log in /var/log/dmesg or similar.
[1] https://lore.kernel.org/r/CAKfmkPK+T0887-uQORxOzbcz-ZxBY+wKLYPRoiQiUfNhffQBEg@xxxxxxxxxxxxxx
[2] https://bugzilla.kernel.org/show_bug.cgi?id=216782
> On Mon, 26 Feb 2024 at 12:49, Ilpo Järvinen
> <ilpo.jarvinen@xxxxxxxxxxxxxxx> wrote:
> >
> > On Mon, 26 Feb 2024, Mathias De Weerdt wrote:
> >
> > > Hi Bjorn
> > >
> > > This has indeed never worked. I have even tried plenty of older
> > > kernels and now also the latest mainline.
> > >
> > > I collected the data you requested on the following kernel (Latest
> > > mainline as of yesterday)
> > > Linux core-arch 6.8.0-rc5-1-mainline #1 SMP PREEMPT_DYNAMIC Sun, 25
> > > Feb 2024 21:59:28 +0000 x86_64 GNU/Linux
> > >
> > > After booting the laptop I put it to sleep and woke it up and
> > > collected the dmesg and lspci logs. (They have been attached)
> > >
> > > Thanks for your quick response.
> > > If you need anything else please let me know.
> > >
> > > Kinds regards
> > > Mathias
> > >
> > > On Mon, 26 Feb 2024 at 00:31, Bjorn Helgaas <helgaas@xxxxxxxxxx> wrote:
> > > >
> > > > On Sun, Feb 25, 2024 at 11:38:35PM +0100, Mathias De Weerdt wrote:
> > > > > Hi
> > > > >
> > > > > I am writing to report a potential bug in the Linux kernel related to
> > > > > waking from suspend on a system(Laptop) with a Genesys Logic GL9755 SD
> > > > > Host Controller. Below are the details of the issue:
> > > >
> > > > Hi Mathias, thanks very much for this report. A few questions below.
> > > >
> > > > > Issue Description:
> > > > > After suspending the system, waking it up takes an extended amount of
> > > > > time, typically 1 to 2 minutes. The delay occurs consistently and is
> > > > > observed in the dmesg logs.
> > > > >
> > > > >
> > > > > System Information:
> > > > > - OS: Arch Linux x86_64
> > > > > - Kernel: 6.7.5-arch1-1 and 6.7.6-arch1-1
> > > > > - SD Host Controller: Genesys Logic GL9755 SD Host Controller (PCI ID:
> > > > > 17a0:9755)
> > > > >
> > > > > Observed Logs (dmesg):
> > > > > [ 642.483972] sdhci-pci 0000:2f:00.0: not ready 1023ms after resume; waiting
> > > > > [ 643.537370] sdhci-pci 0000:2f:00.0: not ready 2047ms after resume; waiting
> > > > > [ 645.724028] sdhci-pci 0000:2f:00.0: not ready 4095ms after resume; waiting
> > > > > [ 649.990655] sdhci-pci 0000:2f:00.0: not ready 8191ms after resume; waiting
> > > > > [ 658.310658] sdhci-pci 0000:2f:00.0: not ready 16383ms after resume; waiting
> > > > > [ 675.590673] sdhci-pci 0000:2f:00.0: not ready 32767ms after resume; waiting
> > > > > [ 709.723965] sdhci-pci 0000:2f:00.0: not ready 65535ms after resume; giving up
> > > > > [ 709.724183] sdhci-pci 0000:2f:00.0: Unable to change power state
> > > > > from D3cold to D0, device inaccessible
> >
> > Hi Mathias,
> >
> > In your dmesg, there's the Target Speed quirk triggering. Please try these
> > two patches, they should fix the logic bug that causes the long delay you
> > see:
> >
> > https://lore.kernel.org/linux-pci/alpine.DEB.2.21.2402092125070.2376@xxxxxxxxxxxxxxxxx/T/#t
> >
> > (They won't help to the link not coming up issue though).
> >
> > --
> > i.
