Re: [BUG] Genesys GL9750 (17a0:9750) does not respond after its PCIe slot is powered back on from D3cold, on s2idle resume and at runtime (ASUS Vivobook 14 Flip TP3407SA, kernel 7.3.1)

Re: [BUG] Genesys GL9750 (17a0:9750) does not respond after its PCIe slot is powered back on from D3cold, on s2idle resume and at runtime (ASUS Vivobook 14 Flip TP3407SA, kernel 7.3.1)

[Kyle Baedke]

On Wednesday, November 4th, 2026 at 2:52 PM, Kyle Baedke <kylebaedke@protonmail.com> wrote:
First copy was in html mode this should be in plaintext
> The GL9750 SD host controller in my laptop is dead after its PCIe slot has
> been powered off and back on through the root port's ACPI power resource.
> This happens on resume from s2idle, and I can also reproduce it at runtime
> with no sleep involved. In both cases the link below the root port never
> comes up, so the device reads as all-ones. The sdhci errors are a
> consequence of that. I'm writing to the sdhci maintainers because the
> device is driven by sdhci-pci-gli, but the failure occurs before the
> driver can talk to the device.
> 
> == System ==
> 
>   Laptop:    ASUS Vivobook 14 Flip TP3407SA
>   BIOS:      TP3407SA.308, 03/05/2026 (the latest available)
>   Kernel:    7.3.1 (NixOS 26.11), x86_64
>   Device:    0000:2c:00.0  Genesys Logic GL9750 [17a0:9750] rev 1,
>              subsystem 1043:202f
>   Upstream:  root port 0000:00:1c.4 (ACPI \_SB.PC00.RP05), link 2.5GT/s x1
>   Cmdline:   intel_iommu=on iommu=pt pcie_aspm.policy=powersave
>              (the relevant parameters)
>   Sleep:     /sys/power/mem_sleep = [s2idle] deep. Selecting "deep" (S3)
>              hangs the machine and needs power to be cut to recover, so
>              s2idle is the only usable sleep mode.
> 
> The root port's ACPI node has power resources (power_resources_D0 and
> power_resources_D3hot in sysfs). The endpoint's ACPI node has none.
> 
> Other firmware/kernel messages seen at boot:
> 
>   ACPI: \_SB_.PEPD: Duplicate LPS0 _DSM functions (mask: 0x1)
>   pci 0000:00:1c.4: mask Replay Timer Timeout Correctable Errors due to
>       0000:2c:00.0 hardware defect
> 
> == Symptom ==
> 
> After the slot is powered back on, config space reads of the device return
> ffff, the port's Link Status stays 0x1011 (Data Link Layer Link Active = 0,
> not training), and sdhci reports:
> 
>   mmc0: sdhci: Version: 0x0000ffff   (register dump is all 0xff)
>   mmc0: enable PCI MSI failed, error=-22
>   mmc0: Reset 0x1 never completed.
>   mmc0: 3.3V regulator output did not become stable
>   mmc0: Controller never released inhibit bit(s).
> 
> On a healthy boot the port's Link Status is 0x3011.
> 
> == Resume trace ==
> 
> Captured with rtcwake -m mem -s 15 (s2idle), pm_debug_messages=1 and
> dynamic debug enabled for drivers/pci/*, drivers/acpi/power.c and
> drivers/acpi/device_pm.c:
> 
>   [  145.370215] sdhci-pci 0000:2c:00.0: PCI PM: Suspend power state: D3hot
>   [  145.406917] ACPI: \_SB_.PC00.RP05.PXP_: ACPI: PM: Power resource turned off
>   [  145.406948] pcieport 0000:00:1c.4: PCI PM: Suspend power state: D3cold
>   ...
>   [  159.865842] ACPI: \_SB_.PC00.RP05: PM: Power state change: D3cold -> D0
>   [  160.263869] ACPI: \_SB_.PC00.RP05.PXP_: ACPI: PM: Power resource turned on
>   [  160.264234] ACPI: \_SB_.PC00.RP05: PM: Power state changed to D0
>   [  160.264241] pcieport 0000:00:1c.4: power state changed by ACPI to D0
>   [  160.276459] pcieport 0000:00:1c.4: ready 0ms after power up D3hot->D0uninitialized
>   [  160.276866] pcieport 0000:00:1c.4: waiting 100 ms for downstream link, after activation
>   [  161.297053] pcieport 0000:00:1c.4: Data Link Layer Link Active not set in 100 msec
>   [  161.303943] sdhci-pci 0000:2c:00.0: restore config 0x3c: 0xffffffff -> 0x000001ff
>   [  161.321478] mmc0: enable PCI MSI failed, error=-22
>   [  161.421611] mmc0: Reset 0x1 never completed.
>   [  161.741170] mmc0: 3.3V regulator output did not become stable
> 
> The slot was off for about 15 s (145.407 to 160.264), so this is not a
> short-off-time problem.
> 
> == Reproduction without suspend ==
> 
> From a healthy boot (device alive, no SD card inserted):
> 
>   echo 1    > /sys/bus/pci/devices/0000:2c:00.0/remove
>   echo 1    > /sys/bus/pci/devices/0000:00:1c.4/d3cold_allowed
>   echo auto > /sys/bus/pci/devices/0000:00:1c.4/power/control
>   # the root port's power_state reached D3cold after about 2 s
>   sleep 1
>   echo on   > /sys/bus/pci/devices/0000:00:1c.4/power/control
>   # port is D0 again, but its Link Status is 0x1011 (DLActive = 0)
>   echo 1    > /sys/bus/pci/rescan     # repeated once per second for 15 s
> 
> The device never reappears, and Link Status stays 0x1011 for the whole
> 15 s. This uses only a 1 s off time.
> 
> == What I tried ==
> 
> Suspend variants, each run with rtcwake -m mem -s 15 (s2idle), no SD card
> inserted. All of these failed on the first cycle:
> 
>   - no changes
>   - endpoint power/control=on
>   - root port power/control=on
>   - endpoint link/l1_2_aspm and link/l1_2_pcipm set to 0
>   - endpoint link/l1_aspm, l1_1_aspm, l1_2_aspm, l1_1_pcipm, l1_2_pcipm
>     all set to 0
>   - endpoint removed before suspend, rescanned after resume
> 
> This one passed 10/10 cycles (device alive 2 s and 8 s after resume, port
> Link Status 0x3011 each time):
> 
>   - d3cold_allowed=0 on both the endpoint and the root port, set just
>     before suspend and restored to 1 right after resume
> 
> Recovery attempted after a failed resume, with the root port held in D0
> (power/control=on) and the rescan polled for 15 s per stage. None brought
> the device back, and Link Status stayed 0x1011 throughout:
> 
>   - remove + rescan
>   - secondary bus reset on the root port, then rescan
>   - Link Disable / enable on the root port, then rescan
> 
> == Questions ==
> 
> 1. Is this a known issue with this device or this platform's slot power-on
>    method?
> 2. What additional tracing would help (ACPI AML debugging, GPIO/pinctrl
>    state before and after the power resource turns on, anything else)?
> 
> I can build and test patches on this machine.
> 
> Thanks,
> Kyle
> 
> Sent with Proton Mail secure email.

Re: [BUG] Genesys GL9750 (17a0:9750) does not respond after its PCIe slot is powered back on from D3cold, on s2idle resume and at runtime (ASUS Vivobook 14 Flip TP3407SA, kernel 7.3.1)

[Adrian Hunter]

+ Ben Chuang

On 05/11/2026 05:32, Kyle Baedke wrote:
> 
> 
> On Wednesday, November 4th, 2026 at 2:52 PM, Kyle Baedke <kylebaedke@protonmail.com> wrote:
> First copy was in html mode this should be in plaintext
>> The GL9750 SD host controller in my laptop is dead after its PCIe slot has
>> been powered off and back on through the root port's ACPI power resource.
>> This happens on resume from s2idle, and I can also reproduce it at runtime
>> with no sleep involved. In both cases the link below the root port never
>> comes up, so the device reads as all-ones. The sdhci errors are a
>> consequence of that. I'm writing to the sdhci maintainers because the
>> device is driven by sdhci-pci-gli, but the failure occurs before the
>> driver can talk to the device.
>>
>> == System ==
>>
>>   Laptop:    ASUS Vivobook 14 Flip TP3407SA
>>   BIOS:      TP3407SA.308, 03/05/2026 (the latest available)
>>   Kernel:    7.3.1 (NixOS 26.11), x86_64
>>   Device:    0000:2c:00.0  Genesys Logic GL9750 [17a0:9750] rev 1,
>>              subsystem 1043:202f
>>   Upstream:  root port 0000:00:1c.4 (ACPI \_SB.PC00.RP05), link 2.5GT/s x1
>>   Cmdline:   intel_iommu=on iommu=pt pcie_aspm.policy=powersave
>>              (the relevant parameters)
>>   Sleep:     /sys/power/mem_sleep = [s2idle] deep. Selecting "deep" (S3)
>>              hangs the machine and needs power to be cut to recover, so
>>              s2idle is the only usable sleep mode.
>>
>> The root port's ACPI node has power resources (power_resources_D0 and
>> power_resources_D3hot in sysfs). The endpoint's ACPI node has none.
>>
>> Other firmware/kernel messages seen at boot:
>>
>>   ACPI: \_SB_.PEPD: Duplicate LPS0 _DSM functions (mask: 0x1)
>>   pci 0000:00:1c.4: mask Replay Timer Timeout Correctable Errors due to
>>       0000:2c:00.0 hardware defect
>>
>> == Symptom ==
>>
>> After the slot is powered back on, config space reads of the device return
>> ffff, the port's Link Status stays 0x1011 (Data Link Layer Link Active = 0,
>> not training), and sdhci reports:
>>
>>   mmc0: sdhci: Version: 0x0000ffff   (register dump is all 0xff)
>>   mmc0: enable PCI MSI failed, error=-22
>>   mmc0: Reset 0x1 never completed.
>>   mmc0: 3.3V regulator output did not become stable
>>   mmc0: Controller never released inhibit bit(s).
>>
>> On a healthy boot the port's Link Status is 0x3011.
>>
>> == Resume trace ==
>>
>> Captured with rtcwake -m mem -s 15 (s2idle), pm_debug_messages=1 and
>> dynamic debug enabled for drivers/pci/*, drivers/acpi/power.c and
>> drivers/acpi/device_pm.c:
>>
>>   [  145.370215] sdhci-pci 0000:2c:00.0: PCI PM: Suspend power state: D3hot
>>   [  145.406917] ACPI: \_SB_.PC00.RP05.PXP_: ACPI: PM: Power resource turned off
>>   [  145.406948] pcieport 0000:00:1c.4: PCI PM: Suspend power state: D3cold
>>   ...
>>   [  159.865842] ACPI: \_SB_.PC00.RP05: PM: Power state change: D3cold -> D0
>>   [  160.263869] ACPI: \_SB_.PC00.RP05.PXP_: ACPI: PM: Power resource turned on
>>   [  160.264234] ACPI: \_SB_.PC00.RP05: PM: Power state changed to D0
>>   [  160.264241] pcieport 0000:00:1c.4: power state changed by ACPI to D0
>>   [  160.276459] pcieport 0000:00:1c.4: ready 0ms after power up D3hot->D0uninitialized
>>   [  160.276866] pcieport 0000:00:1c.4: waiting 100 ms for downstream link, after activation
>>   [  161.297053] pcieport 0000:00:1c.4: Data Link Layer Link Active not set in 100 msec
>>   [  161.303943] sdhci-pci 0000:2c:00.0: restore config 0x3c: 0xffffffff -> 0x000001ff
>>   [  161.321478] mmc0: enable PCI MSI failed, error=-22
>>   [  161.421611] mmc0: Reset 0x1 never completed.
>>   [  161.741170] mmc0: 3.3V regulator output did not become stable
>>
>> The slot was off for about 15 s (145.407 to 160.264), so this is not a
>> short-off-time problem.
>>
>> == Reproduction without suspend ==
>>
>> From a healthy boot (device alive, no SD card inserted):
>>
>>   echo 1    > /sys/bus/pci/devices/0000:2c:00.0/remove
>>   echo 1    > /sys/bus/pci/devices/0000:00:1c.4/d3cold_allowed
>>   echo auto > /sys/bus/pci/devices/0000:00:1c.4/power/control
>>   # the root port's power_state reached D3cold after about 2 s
>>   sleep 1
>>   echo on   > /sys/bus/pci/devices/0000:00:1c.4/power/control
>>   # port is D0 again, but its Link Status is 0x1011 (DLActive = 0)
>>   echo 1    > /sys/bus/pci/rescan     # repeated once per second for 15 s
>>
>> The device never reappears, and Link Status stays 0x1011 for the whole
>> 15 s. This uses only a 1 s off time.
>>
>> == What I tried ==
>>
>> Suspend variants, each run with rtcwake -m mem -s 15 (s2idle), no SD card
>> inserted. All of these failed on the first cycle:
>>
>>   - no changes
>>   - endpoint power/control=on
>>   - root port power/control=on
>>   - endpoint link/l1_2_aspm and link/l1_2_pcipm set to 0
>>   - endpoint link/l1_aspm, l1_1_aspm, l1_2_aspm, l1_1_pcipm, l1_2_pcipm
>>     all set to 0
>>   - endpoint removed before suspend, rescanned after resume
>>
>> This one passed 10/10 cycles (device alive 2 s and 8 s after resume, port
>> Link Status 0x3011 each time):
>>
>>   - d3cold_allowed=0 on both the endpoint and the root port, set just
>>     before suspend and restored to 1 right after resume
>>
>> Recovery attempted after a failed resume, with the root port held in D0
>> (power/control=on) and the rescan polled for 15 s per stage. None brought
>> the device back, and Link Status stayed 0x1011 throughout:
>>
>>   - remove + rescan
>>   - secondary bus reset on the root port, then rescan
>>   - Link Disable / enable on the root port, then rescan
>>
>> == Questions ==
>>
>> 1. Is this a known issue with this device or this platform's slot power-on
>>    method?
>> 2. What additional tracing would help (ACPI AML debugging, GPIO/pinctrl
>>    state before and after the power resource turns on, anything else)?
>>
>> I can build and test patches on this machine.
>>
>> Thanks,
>> Kyle
>>
>> Sent with Proton Mail secure email.