TGL-U: Can't suspend with USB-C device connected

[alexgallotta]

I have a lemp10 lemur pro, I update the firmware few days ago. After the reboot and firmware installation, every time I put the laptop in sleep mode while it is connected to a USB-C hub (plugged with a monitor and mouse+keyboard) the fan starts spinning continuously after 10 seconds or so. When I resume and login, the fan stops. I tried to run fwudp for update history, but got nothing

fwupdmgr get-history                                                                             1 ↵
No history

[kepelrs]

I have the same issue on the lemp10.

[curiousercreative]

Same issue on galp5 when connected to Dell U2720Q. Possibly related, system doesn't resume from hibernation properly anymore.

[curiousercreative]

Likely culprint: https://github.com/system76/firmware-open/commit/236914e8e8f8b0acf3f14116e66ba04c7befc6e5

[jackpot51]

Are these Thunderbolt hubs?

[curiousercreative]

@jackpot51 My display is USB-C (not TB) but connected to TB/USB4 port of my galp5.

[curiousercreative]

Notably, when the same display and cable are connected to my galp5 on the opposite side, suspend works as expected. On that side, the display doesn't receive a signal and there's no PD.

[jackpot51]

Very interesting. I had noticed some issues with suspend when using Thunderbolt devices. Usually eGPUs. This was expected due to the Thunderbolt device itself keeping the CPU from going to s0ix.

But I haven't seen a non-Thunderbolt USB-C device keep the system from suspending. If you have any other USB-C devices please test those as well, so I can know if it is specific to some form of hardware. So far it looks like DisplayPort monitors are used on both @curiousercreative and @alexgallotta USB-C ports

[jacobgkau]

I can recreate this when connected to the ViewSonic VP2771 via USB-C, and also when connected to a hard drive enclosure via USB-C (non-Thunderbolt).

[jackpot51]

If updating the microcode caused the issue, @jacobgkau can you test with the old microcode firmware? We will need to make sure https://github.com/pop-os/linux/issues/41 is still fixed. I will check for even newer microcode

[jacobgkau]

I rolled back the microcode by reverting 236914e8e8f8b0acf3f14116e66ba04c7befc6e5. Power-off works, but the suspend w/ USB-C issue is still occurring.

[jackpot51]

Yeah, I don't think this is a microcode issue. Probably introduced in kernel updates

[curiousercreative]

@jackpot51 I rolled back to 5.8 from the advice here, but no difference. https://www.reddit.com/r/System76/comments/mylbea/fan_keeps_spinning_when_suspend_lemur_pro/

[curiousercreative]

note, uname -r shows kernel 5.8 while kernelstub -p shows 5.11...

[curiousercreative]

I tried unplugging every USB peripheral from the monitor one by one until I was left with just the monitor and that still results in fans on suspend. Interestingly enough though, just having my USB headset plugged into the same TB3/USB4 port blocks suspend, but instead of blank screen and fans, suspend seems to exit immediately and return to lock screen. Here's some output from kern.log for the headset:

Apr 30 21:26:54 galp-curiouser kernel: [ 1280.642203] usb 3-6: new full-speed USB device number 25 using xhci_hcd
Apr 30 21:26:55 galp-curiouser kernel: [ 1280.865659] usb 3-6: New USB device found, idVendor=18d1, idProduct=5033, bcdDevice= 0.20
Apr 30 21:26:55 galp-curiouser kernel: [ 1280.865664] usb 3-6: New USB device strings: Mfr=1, Product=2, SerialNumber=3
Apr 30 21:26:55 galp-curiouser kernel: [ 1280.865665] usb 3-6: Product: Pixel USB-C earbuds
Apr 30 21:26:55 galp-curiouser kernel: [ 1280.865667] usb 3-6: Manufacturer: Google
Apr 30 21:26:55 galp-curiouser kernel: [ 1280.865668] usb 3-6: SerialNumber: xxxxx
Apr 30 21:26:55 galp-curiouser kernel: [ 1280.888300] input: Google Pixel USB-C earbuds as /devices/pci0000:00/0000:00:14.0/usb3/3-6/3-6:1.3/0003:18D1:5033.001A/input/input79
Apr 30 21:26:55 galp-curiouser kernel: [ 1280.946792] hid-generic 0003:18D1:5033.001A: input,hidraw2: USB HID v1.11 Device [Google Pixel USB-C earbuds] on usb-0000:00:14.0-6/input3
Apr 30 21:26:55 galp-curiouser kernel: [ 1281.083722] input: Google Pixel USB-C earbuds as /devices/pci0000:00/0000:00:14.0/usb3/3-6/3-6:1.3/0003:18D1:5033.001B/input/input80
Apr 30 21:26:55 galp-curiouser kernel: [ 1281.146856] hid-generic 0003:18D1:5033.001B: input,hidraw2: USB HID v1.11 Device [Google Pixel USB-C earbuds] on usb-0000:00:14.0-6/input3
Apr 30 21:26:59 galp-curiouser kernel: [ 1285.273126] wlp0s20f3: deauthenticating from 20:c0:47:e5:ac:aa by local choice (Reason: 3=DEAUTH_LEAVING)
Apr 30 21:27:04 galp-curiouser kernel: [ 1289.927632] rfkill: input handler enabled
Apr 30 21:27:04 galp-curiouser kernel: [ 1289.942331] PM: suspend entry (s2idle)
Apr 30 21:27:04 galp-curiouser kernel: [ 1290.425696] Filesystems sync: 0.483 seconds
Apr 30 21:27:09 galp-curiouser kernel: [ 1290.993058] Freezing user space processes ... (elapsed 0.002 seconds) done.
Apr 30 21:27:09 galp-curiouser kernel: [ 1290.995517] OOM killer disabled.
Apr 30 21:27:09 galp-curiouser kernel: [ 1290.995518] Freezing remaining freezable tasks ... (elapsed 0.024 seconds) done.
Apr 30 21:27:09 galp-curiouser kernel: [ 1291.019573] printk: Suspending console(s) (use no_console_suspend to debug)
Apr 30 21:27:09 galp-curiouser kernel: [ 1292.013717] ACPI: EC: interrupt blocked
Apr 30 21:27:09 galp-curiouser kernel: [ 1292.117996] ACPI: EC: interrupt unblocked
Apr 30 21:27:09 galp-curiouser kernel: [ 1292.674600] mei_me xxxxx: hbm: dma setup response: failure = 3 REJECTED
Apr 30 21:27:09 galp-curiouser kernel: [ 1293.224023] mei_hdcp xxxxxxx (ops i915_hdcp_component_ops [i915])
Apr 30 21:27:09 galp-curiouser kernel: [ 1295.023746] OOM killer enabled.
Apr 30 21:27:09 galp-curiouser kernel: [ 1295.023750] Restarting tasks ... done.
Apr 30 21:27:09 galp-curiouser kernel: [ 1295.039495] thermal thermal_zone1: failed to read out thermal zone (-61)
Apr 30 21:27:09 galp-curiouser kernel: [ 1295.122449] video LNXVIDEO:00: Restoring backlight state
Apr 30 21:27:09 galp-curiouser kernel: [ 1295.141777] PM: suspend exit
Apr 30 21:27:09 galp-curiouser kernel: [ 1295.394975] rfkill: input handler disabled

hmmmm, may have spoke too soon. after a reboot, the same USB headset suspended fine:

Apr 30 21:42:22 galp-curiouser kernel: [  298.116641] usb 3-6: new full-speed USB device number 15 using xhci_hcd
Apr 30 21:42:22 galp-curiouser kernel: [  298.342744] usb 3-6: New USB device found, idVendor=18d1, idProduct=5033, bcdDevice= 0.20
Apr 30 21:42:22 galp-curiouser kernel: [  298.342748] usb 3-6: New USB device strings: Mfr=1, Product=2, SerialNumber=3
Apr 30 21:42:22 galp-curiouser kernel: [  298.342749] usb 3-6: Product: Pixel USB-C earbuds
Apr 30 21:42:22 galp-curiouser kernel: [  298.342750] usb 3-6: Manufacturer: Google
Apr 30 21:42:22 galp-curiouser kernel: [  298.342750] usb 3-6: SerialNumber: xxxxxxx
Apr 30 21:42:22 galp-curiouser kernel: [  298.344782] input: Google Pixel USB-C earbuds as /devices/pci0000:00/0000:00:14.0/usb3/3-6/3-6:1.3/0003:18D1:5033.000E/input/input52
Apr 30 21:42:22 galp-curiouser kernel: [  298.404898] hid-generic 0003:18D1:5033.000E: input,hidraw1: USB HID v1.11 Device [Google Pixel USB-C earbuds] on usb-0000:00:14.0-6/input3
Apr 30 21:42:22 galp-curiouser kernel: [  298.446058] usbcore: registered new interface driver snd-usb-audio
Apr 30 21:42:23 galp-curiouser kernel: [  298.535142] input: Google Pixel USB-C earbuds as /devices/pci0000:00/0000:00:14.0/usb3/3-6/3-6:1.3/0003:18D1:5033.000F/input/input53
Apr 30 21:42:23 galp-curiouser kernel: [  298.592488] hid-generic 0003:18D1:5033.000F: input,hidraw1: USB HID v1.11 Device [Google Pixel USB-C earbuds] on usb-0000:00:14.0-6/input3
Apr 30 21:42:27 galp-curiouser kernel: [  303.062370] usb usb2-port1: Cannot enable. Maybe the USB cable is bad?
Apr 30 21:42:31 galp-curiouser kernel: [  307.168543] usb usb2-port1: Cannot enable. Maybe the USB cable is bad?
Apr 30 21:42:31 galp-curiouser kernel: [  307.168625] usb usb2-port1: attempt power cycle
Apr 30 21:42:36 galp-curiouser kernel: [  311.570538] usb usb2-port1: Cannot enable. Maybe the USB cable is bad?
Apr 30 21:42:39 galp-curiouser kernel: [  315.292795] magicmouse 0005:004C:0269.0010: unknown main item tag 0x0
Apr 30 21:42:39 galp-curiouser kernel: [  315.292861] input: xxxxxx as /devices/pci0000:00/0000:00:14.0/usb3/3-10/3-10:1.0/bluetooth/hci0/hci0:256/0005:004C:0269.0010/input/input54
Apr 30 21:42:39 galp-curiouser kernel: [  315.292985] magicmouse 0005:004C:0269.0010: input,hidraw2: BLUETOOTH HID v1.07 Mouse on 18:cc:18:98:9c:c4
Apr 30 21:42:39 galp-curiouser kernel: [  315.437088] hid-generic 0005:004C:0269.0010: unknown main item tag 0x0
Apr 30 21:42:39 galp-curiouser kernel: [  315.437164] input: xxxx as /devices/pci0000:00/0000:00:14.0/usb3/3-10/3-10:1.0/bluetooth/hci0/hci0:256/0005:004C:0269.0010/input/input55
Apr 30 21:42:39 galp-curiouser kernel: [  315.437540] input: xxxxxxas /devices/pci0000:00/0000:00:14.0/usb3/3-10/3-10:1.0/bluetooth/hci0/hci0:256/0005:004C:0269.0010/input/input56
Apr 30 21:42:39 galp-curiouser kernel: [  315.437685] hid-generic 0005:004C:0269.0010: input,hidraw2: BLUETOOTH HID v1.07 Mouse on 18:cc:18:98:9c:c4
Apr 30 21:42:40 galp-curiouser kernel: [  315.664654] usb usb2-port1: Cannot enable. Maybe the USB cable is bad?
Apr 30 21:42:40 galp-curiouser kernel: [  315.664719] usb usb2-port1: unable to enumerate USB device
Apr 30 21:42:41 galp-curiouser kernel: [  317.469019] hid_magicmouse: unknown parameter 'scroll_delay_pos_x' ignored
Apr 30 21:42:41 galp-curiouser kernel: [  317.469026] hid_magicmouse: unknown parameter 'scroll_delay_pos_y' ignored
Apr 30 21:42:42 galp-curiouser kernel: [  317.551933] magicmouse 0005:004C:0269.0010: unknown main item tag 0x0
Apr 30 21:42:42 galp-curiouser kernel: [  317.552017] input: xxx as /devices/pci0000:00/0000:00:14.0/usb3/3-10/3-10:1.0/bluetooth/hci0/hci0:256/0005:004C:0269.0010/input/input57
Apr 30 21:42:42 galp-curiouser kernel: [  317.552279] magicmouse 0005:004C:0269.0010: input,hidraw2: BLUETOOTH HID v1.07 Mouse on 18:cc:18:98:9c:c4
Apr 30 21:42:44 galp-curiouser kernel: [  320.355361] wlp0s20f3: deauthenticating from xxxxxxx by local choice (Reason: 3=DEAUTH_LEAVING)
Apr 30 21:42:49 galp-curiouser kernel: [  324.925588] rfkill: input handler enabled
Apr 30 21:42:50 galp-curiouser kernel: [  325.666313] PM: suspend entry (s2idle)
Apr 30 21:42:50 galp-curiouser kernel: [  326.444214] Filesystems sync: 0.778 seconds
Apr 30 21:43:00 galp-curiouser kernel: [  326.984474] Freezing user space processes ... (elapsed 0.002 seconds) done.
Apr 30 21:43:00 galp-curiouser kernel: [  326.987359] OOM killer disabled.
Apr 30 21:43:00 galp-curiouser kernel: [  326.987360] Freezing remaining freezable tasks ... (elapsed 0.001 seconds) done.
Apr 30 21:43:00 galp-curiouser kernel: [  326.988763] printk: Suspending console(s) (use no_console_suspend to debug)
Apr 30 21:43:00 galp-curiouser kernel: [  327.985397] ACPI: EC: interrupt blocked
Apr 30 21:43:00 galp-curiouser kernel: [  334.916584] ACPI: EC: interrupt unblocked
Apr 30 21:43:00 galp-curiouser kernel: [  335.474012] mei_me 0000:00:16.0: hbm: dma setup response: failure = 3 REJECTED
Apr 30 21:43:00 galp-curiouser kernel: [  336.024721] OOM killer enabled.
Apr 30 21:43:00 galp-curiouser kernel: [  336.024724] Restarting tasks ... done.
Apr 30 21:43:00 galp-curiouser kernel: [  336.028392] thermal thermal_zone1: failed to read out thermal zone (-61)
Apr 30 21:43:00 galp-curiouser kernel: [  336.028457] mei_hdcp xxxxxxxxxxxx (ops i915_hdcp_component_ops [i915])
Apr 30 21:43:00 galp-curiouser kernel: [  336.103106] video LNXVIDEO:00: Restoring backlight state
Apr 30 21:43:00 galp-curiouser kernel: [  336.116797] PM: suspend exit

[curiousercreative]

on kernel 5.8, suspend with USB-C display doesn't work, but it also doesn't spin the fans. 5.11 spins fans

[alexrelis]

• Computer: galp5
• Kernel/OS: Linux alex-pc 5.10.0-6-amd64 #1 SMP Debian 5.10.28-1 (2021-04-09) x86_64 GNU/Linux

I might be having a similar issue to you folks. When I press "Fn + Suspend (moon icon)" to suspend, my system's screen will turn off as if it were attempting to enter s0ix but then the screen turns back on. After the suspend fails, the fan spins on constantly and a kworker process consumes a significant amount of CPU.

    PID     USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND
    1396345 root      20   0       0      0      0 R  78.4   0.0   2:18.99 kworker/0:3+kacpid

I asked an expert and they told me to check my /sys/firmware/acpi/interrupts/.

alex@alex-pc:~$  grep . -r /sys/firmware/acpi/interrupts/         
/sys/firmware/acpi/interrupts/gpe2F:       0         invalid      unmasked
/sys/firmware/acpi/interrupts/gpe23:       0         invalid      unmasked
/sys/firmware/acpi/interrupts/gpe5D:       0         invalid      unmasked
/sys/firmware/acpi/interrupts/gpe51:       0         invalid      unmasked
/sys/firmware/acpi/interrupts/gpe1F:       0         invalid      unmasked
/sys/firmware/acpi/interrupts/gpe13:       0         invalid      unmasked
/sys/firmware/acpi/interrupts/gpe4D:       0         invalid      unmasked
/sys/firmware/acpi/interrupts/gpe41:       0         invalid      unmasked
/sys/firmware/acpi/interrupts/gpe7B:       0         invalid      unmasked
/sys/firmware/acpi/interrupts/gpe0F:       0         invalid      unmasked
/sys/firmware/acpi/interrupts/gpe03:       0         invalid      unmasked
/sys/firmware/acpi/interrupts/gpe3D:       0         invalid      unmasked
/sys/firmware/acpi/interrupts/gpe31:       0         invalid      unmasked
/sys/firmware/acpi/interrupts/gpe6B:       0         invalid      unmasked
/sys/firmware/acpi/interrupts/gpe2D:       0         invalid      unmasked
/sys/firmware/acpi/interrupts/gpe21:       0         invalid      unmasked
/sys/firmware/acpi/interrupts/gpe5B:       0         invalid      unmasked
/sys/firmware/acpi/interrupts/gpe1D:       0         invalid      unmasked
/sys/firmware/acpi/interrupts/ff_pwr_btn:       0  EN     enabled      unmasked
/sys/firmware/acpi/interrupts/gpe78:       0         invalid      unmasked
/sys/firmware/acpi/interrupts/gpe11:       0         invalid      unmasked
/sys/firmware/acpi/interrupts/gpe4B:       0     STS invalid      unmasked
/sys/firmware/acpi/interrupts/gpe0D:       0         invalid      unmasked
/sys/firmware/acpi/interrupts/gpe68:       0         invalid      unmasked
/sys/firmware/acpi/interrupts/gpe01:       0         invalid      unmasked
/sys/firmware/acpi/interrupts/gpe3B:       0         invalid      unmasked
/sys/firmware/acpi/interrupts/gpe58:       0         invalid      unmasked
/sys/firmware/acpi/interrupts/gpe2B:       0         invalid      unmasked
/sys/firmware/acpi/interrupts/ff_rt_clk:       0         disabled     unmasked
/sys/firmware/acpi/interrupts/ff_pmtimer:       0         invalid      unmasked
/sys/firmware/acpi/interrupts/gpe48:       0         invalid      unmasked
/sys/firmware/acpi/interrupts/gpe1B:       0         invalid      unmasked
/sys/firmware/acpi/interrupts/gpe76:       0         invalid      unmasked
/sys/firmware/acpi/interrupts/gpe38:       0         invalid      unmasked
/sys/firmware/acpi/interrupts/gpe0B:       0         invalid      unmasked
/sys/firmware/acpi/interrupts/gpe66:       0     STS invalid      unmasked
/sys/firmware/acpi/interrupts/gpe28:       0         invalid      unmasked
/sys/firmware/acpi/interrupts/gpe56:       0         invalid      unmasked
/sys/firmware/acpi/interrupts/gpe18:       0         invalid      unmasked
/sys/firmware/acpi/interrupts/gpe46:       0         invalid      unmasked
/sys/firmware/acpi/interrupts/gpe74:       0         invalid      unmasked
/sys/firmware/acpi/interrupts/gpe08:       0         invalid      unmasked
/sys/firmware/acpi/interrupts/gpe36:       0         invalid      unmasked
/sys/firmware/acpi/interrupts/gpe64:       0         invalid      unmasked
/sys/firmware/acpi/interrupts/gpe26:       0         invalid      unmasked
/sys/firmware/acpi/interrupts/error:       0
/sys/firmware/acpi/interrupts/gpe54:       0         invalid      unmasked
/sys/firmware/acpi/interrupts/gpe16:       0         invalid      unmasked
/sys/firmware/acpi/interrupts/sci:134480049
/sys/firmware/acpi/interrupts/gpe44:       0         invalid      unmasked
/sys/firmware/acpi/interrupts/gpe7E:       0         invalid      unmasked
/sys/firmware/acpi/interrupts/gpe72:       0         invalid      unmasked
/sys/firmware/acpi/interrupts/gpe06:       0         invalid      unmasked
/sys/firmware/acpi/interrupts/gpe34:       0         invalid      unmasked
/sys/firmware/acpi/interrupts/gpe6E: 5774379  EN     enabled      unmasked
/sys/firmware/acpi/interrupts/gpe62:       0         invalid      unmasked
/sys/firmware/acpi/interrupts/gpe24:       0         invalid      unmasked
/sys/firmware/acpi/interrupts/gpe5E:       0         invalid      unmasked
/sys/firmware/acpi/interrupts/gpe52:       0         invalid      unmasked
/sys/firmware/acpi/interrupts/gpe14:       0         invalid      unmasked
/sys/firmware/acpi/interrupts/gpe4E:       0         invalid      unmasked
/sys/firmware/acpi/interrupts/gpe42:       0     STS invalid      unmasked
/sys/firmware/acpi/interrupts/gpe7C:       0         invalid      unmasked
/sys/firmware/acpi/interrupts/gpe70:       0         invalid      unmasked
/sys/firmware/acpi/interrupts/gpe04:       0         invalid      unmasked
/sys/firmware/acpi/interrupts/gpe3E:       0         invalid      unmasked
/sys/firmware/acpi/interrupts/gpe32:       0         invalid      unmasked
/sys/firmware/acpi/interrupts/gpe6C:       0         invalid      unmasked
/sys/firmware/acpi/interrupts/gpe60:       0         invalid      unmasked
/sys/firmware/acpi/interrupts/gpe2E:       0         invalid      unmasked
/sys/firmware/acpi/interrupts/gpe22:       0         invalid      unmasked
/sys/firmware/acpi/interrupts/gpe5C:       0         invalid      unmasked
/sys/firmware/acpi/interrupts/gpe50:       0         invalid      unmasked
/sys/firmware/acpi/interrupts/gpe1E:       0         invalid      unmasked
/sys/firmware/acpi/interrupts/gpe79:       0         invalid      unmasked
/sys/firmware/acpi/interrupts/gpe12:       0         invalid      unmasked
/sys/firmware/acpi/interrupts/gpe4C:       0         invalid      unmasked
/sys/firmware/acpi/interrupts/gpe40:       0         invalid      unmasked
/sys/firmware/acpi/interrupts/gpe7A:       0         invalid      unmasked
/sys/firmware/acpi/interrupts/gpe0E:       0         invalid      unmasked
/sys/firmware/acpi/interrupts/gpe69:129050743     STS enabled      unmasked
/sys/firmware/acpi/interrupts/gpe02:       0         invalid      unmasked
/sys/firmware/acpi/interrupts/gpe3C:       0         invalid      unmasked
/sys/firmware/acpi/interrupts/gpe30:       0         invalid      unmasked
/sys/firmware/acpi/interrupts/gpe6A:       0         invalid      unmasked
/sys/firmware/acpi/interrupts/gpe59:       0         invalid      unmasked
/sys/firmware/acpi/interrupts/gpe2C:       0         invalid      unmasked
/sys/firmware/acpi/interrupts/gpe20:       0         invalid      unmasked
/sys/firmware/acpi/interrupts/gpe5A:       0         invalid      unmasked
/sys/firmware/acpi/interrupts/gpe49:       0         invalid      unmasked
/sys/firmware/acpi/interrupts/gpe1C:       0         invalid      unmasked
/sys/firmware/acpi/interrupts/gpe77:       0         invalid      unmasked
/sys/firmware/acpi/interrupts/gpe10:       0         invalid      unmasked
/sys/firmware/acpi/interrupts/gpe4A:       0         invalid      unmasked
/sys/firmware/acpi/interrupts/gpe39:       0         invalid      unmasked
/sys/firmware/acpi/interrupts/gpe0C:       0         invalid      unmasked
/sys/firmware/acpi/interrupts/gpe67:       0         invalid      unmasked
/sys/firmware/acpi/interrupts/gpe00:       0         invalid      unmasked
/sys/firmware/acpi/interrupts/gpe3A:       0         invalid      unmasked
/sys/firmware/acpi/interrupts/gpe_all:134826391
/sys/firmware/acpi/interrupts/gpe29:       0         invalid      unmasked
/sys/firmware/acpi/interrupts/gpe57:       0         invalid      unmasked
/sys/firmware/acpi/interrupts/gpe2A:       0         invalid      unmasked
/sys/firmware/acpi/interrupts/gpe19:       0         invalid      unmasked
/sys/firmware/acpi/interrupts/gpe47:       0         invalid      unmasked
/sys/firmware/acpi/interrupts/gpe1A:       0         invalid      unmasked
/sys/firmware/acpi/interrupts/gpe75:       0         invalid      unmasked
/sys/firmware/acpi/interrupts/gpe09:       0         invalid      unmasked
/sys/firmware/acpi/interrupts/gpe37:       0         invalid      unmasked
/sys/firmware/acpi/interrupts/gpe0A:       0         invalid      unmasked
/sys/firmware/acpi/interrupts/gpe65:       0         invalid      unmasked
/sys/firmware/acpi/interrupts/gpe27:       0         invalid      unmasked
/sys/firmware/acpi/interrupts/gpe55:       0         invalid      unmasked
/sys/firmware/acpi/interrupts/gpe17:       0         invalid      unmasked
/sys/firmware/acpi/interrupts/gpe45:       0         invalid      unmasked
/sys/firmware/acpi/interrupts/gpe7F:       0         invalid      unmasked
/sys/firmware/acpi/interrupts/gpe73:       0  EN     invalid      unmasked
/sys/firmware/acpi/interrupts/ff_gbl_lock:       0  EN     enabled      unmasked
/sys/firmware/acpi/interrupts/gpe07:       0         invalid      unmasked
/sys/firmware/acpi/interrupts/sci_not: 1211254
/sys/firmware/acpi/interrupts/gpe35:       0         invalid      unmasked
/sys/firmware/acpi/interrupts/gpe6F:       0         invalid      unmasked
/sys/firmware/acpi/interrupts/gpe63:       0         invalid      unmasked
/sys/firmware/acpi/interrupts/gpe25:       0         invalid      unmasked
/sys/firmware/acpi/interrupts/gpe5F:       0         invalid      unmasked
/sys/firmware/acpi/interrupts/gpe53:       0         invalid      unmasked
/sys/firmware/acpi/interrupts/gpe15:       0         invalid      unmasked
/sys/firmware/acpi/interrupts/gpe4F:       0         invalid      unmasked
/sys/firmware/acpi/interrupts/gpe43:       0         invalid      unmasked
/sys/firmware/acpi/interrupts/gpe7D:       0         invalid      unmasked
/sys/firmware/acpi/interrupts/gpe71:       0         invalid      unmasked
/sys/firmware/acpi/interrupts/gpe05:       0         invalid      unmasked
/sys/firmware/acpi/interrupts/gpe3F:       0         invalid      unmasked
/sys/firmware/acpi/interrupts/gpe33:       0         invalid      unmasked
/sys/firmware/acpi/interrupts/gpe6D:    1268         disabled     unmasked
/sys/firmware/acpi/interrupts/ff_slp_btn:       0         invalid      unmasked
/sys/firmware/acpi/interrupts/gpe61:       0  EN     enabled      unmasked

He then told me to manually disable gpe69.

root@alex-pc:~#  echo "disable" | tee /sys/firmware/acpi/interrupts/gpe69
disable

This temporarily stops the excessive CPU usage, but it happens again when I attempt to suspend again. Not sure if this changes anything, but a Logitech wireless receiver is connected to the USB-A and my smartphone is connected to the USB-C Thunderbolt port. I hope that there's a way to fix this.

Also, this is my first ever Github comment. Hi.

[curiousercreative]

@alexrelis welcome and thanks for the detailed report! Does suspend work fine with no devices connected on a fresh boot? Does it work with just the USB-A device or just the USB-C device?

[demiangz]

same exact issue with the lemp10. When connected to monitor through thunderbolt. kernel 5.11. Did happened in the previous one as well.

[alexrelis]

@curiousercreative You're welcome! After a fresh boot, while charging and not charging, suspend works fine with nothing plugged in, everything plugged in, the smartphone via USB-C plugged and not the mouse via USB-A plugged in, and the mouse via USB-A plugged in and not the smartphone via USB-C plugged in, but there is a caveat! With my smartphone connected via the Thunderbolt USB-C port, it seems like the status light on the right of the machine doesn't blink like it normally does in s0ix. This doesn't happen on the non-Thunderbolt USB-C port. At the same time, I still believe the machine is suspending in some form, since the screen doesn't turn back on unless I press a key on the keyboard or the power button. So far, my computer has been on for 6 hours and I haven't been experiencing the issue. I have a Thunderbolt dock (this Ikling one: https://www.amazon.com/Adapter-Charging-Ethernet-Compatible-Thunderbolt/dp/B07TVSLDND/ref=sr_1_4?keywords=usb+c+hub&qid=1569187498&s=electronics&sr=1-4) that I will test to see if that's what's causing my issue when I get the chance. I'm curious to see what causes this.

[atinybeardedman]

Having this issue with lemp9 as well. However I'm noticing it without devices connected. I shut the lid and the fans keep going and it's real hot. Started after I updated firmware as well.

[alexgallotta]

Since it seems that it will take a while to fix, can we get the firmware version before 2021-04-07_236914e? I see no tags in this repo, if you could tag the previous firmware it would be easier for us to flash it

[curiousercreative]

@alexgallotta in your firmware update app, I believe you can list previous firmware releases. While they're not tagged in this repo (probably because releases are device specific), you can git checkout 236914e && git submodule update for the release that you mention. Basically, what comes after the date is a commit hash (abbreviated).

[alexgallotta]

Thanks @curiousercreative for the explanation. I don't see the previous firmware in the firmware manager UI Following your indication I should checkout the commit be04aea for the previous version and if the issue continue I would try the original one 0e80285. I will try and report back if it solved our issue!

[curiousercreative]

Following your indication I should checkout the commit be04aea for the previous version and if the issue continue I would try the original one 0e80285.

Yep, you got it.

[alexgallotta]

I tried to flash the be04aea version, issue was still there. I also tried 0e80285, same result. I upgraded back to the current version(236914e), problem still there obviously. I noticed that, during the upgrade, there was something about "preserving old" something, so maybe there is some flipped bit that is kept the way it is now, no idea. If anyone feels like trying the firmware downgrade too, it is pretty easy checking those commits and running the steps in the readme (I also rm- rf build/ every time)

[curiousercreative]

@alexgallotta perhaps you can attempt a kernel rollback. Do you have 5.8 installed still? Do you know how to set with kernelstub? -i and -k args.

Also, all of this is only with USB-C device connected?

[alexgallotta]

PopOS give the option to run the previous kernel (it was 5.8 when I tried) and I still had the issue. Yes, it happens only when a USB-C is connected. I played around yesterday and the behavior is:

• sleep laptop while USB-C is connected, fan not running -> fan spins after 10 seconds of sleep
• I unplug USB-C (laptop still sleeping) -> fan stops after 5-10 seconds
• I plug the USB-C again (laptop still sleeping) -> fan spins again after 5-10 seconds
• I wake the laptop -> fan stops

[demiangz]

PopOS give the option to run the previous kernel (it was 5.8 when I tried) and I still had the issue. Yes, it happens only when a USB-C is connected. I played around yesterday and the behavior is:

* sleep laptop while USB-C is connected, fan not running -> fan spins after 10 seconds of sleep

* I unplug USB-C (laptop still sleeping) -> fan stops after 5-10 seconds

* I plug the USB-C again (laptop still sleeping)  -> fan spins again after 5-10 seconds

* I wake the laptop -> fan stops

yes, exactly what I am experiencing

[thomas-zimmerman]

@ care has a customer that hit this as well. He has logs for:

A1: Started lemp10 with Sonnet box disconnected
A2: Hot-plug Sonnet box:  Neither the box or the eGPU are recognized, but the laptop does charge through the USB-C
A3: Hot-unplug Sonnet box, no apparent changes from lsusb.
A4: Tried to suspend laptop by closing screen lid. Power light stays solid green and if I open lid screen turns on but I cannot use the keyboard or click with mouse. Had to forcefully restart using the power button.

B1: Starting Lemur with Sonnet box already connected. System correctly recognized the box, the NVidia RTX8000 is set in compute mode, and the additional USB ports are available on the box. The laptop is also charging through USB-C.
B2: Hot-unplugging the Sonnet box correctly removed the items associated with the box from lsusb output.
B3: Tried to suspend laptop by closing lid. Power light stays solid green, but if I open screen lid I am able to type my password and unlock the computer to regain access to my gnome session.

Support case 59643

[bryanspears]

I've recently encountered this with a new Darter Pro (darp7) using both Pop OS and Arch

Latest firmware (2021-04-07_236914e) Latest kernel as well (5.11.0-7614-generic)

[u-f-0]

I am encountering this as well on Lemur Pro (lemp10) running both Arch and Pop OS.

Latest firmware (2021-04-07_236914e) Arch kernel: 5.12.13-arch1-2

Like i have flashed both the latest and the previous firmware version with the same results. Please let me know if i can help out to get this resolved in any way!

EDIT: I have tested out a few different docks now and it seems to be limited to thunderbolt docks. Usb-C displays with build in hubs seem to not cause the issue.

[julienlarena]

I don't know if it is the same issue, but I just experienced that on my lemp10: lid down, on AC power, the fan starts spinning with interruption and I can;t wake up from suspend, This is the first time it happens, but I usually only shuts the lid down when on battery. I said I was not sure if it was the same issue since it is not on USB-C but on the barrel power chord. I am running 21.04 with kernel 5.11, up-to-date.

[mvysin]

Hi. I'm experiencing this on lemp10 as well -- the behavior described here matches identically.

I'm running:

• 2021-04-07_236914e. I also tried rolling back the microcode update 236914e and had equally unhelpful results.
• Currently running Ubuntu 21.04 kernel 5.11.0-7620-generic, have also tried a 5.8 kernel, 5.12 kernel, and even older. Have also tried Pop OS. Same results.
• Both the Dell U2520D and the Lenovo P27h-20 monitors cause this behavior. I believe these use displayport lanes (and is reported in xrandr as DP-1-8 if relevant?), rather than thunderbolt-proper, but this is an area I'm very fuzzy in.

I followed the Linux S0ix Troubleshooting Guide and discovered that:

• booting the kernel with initcall_debug doesn't report any failures during the suspend or resume process.
• turbostat reports PC10 residency and graphics RC6 residency (can share the output if helpful)
• The counter at /sys/kernel/debug/pmc_core/slp_s0_residency_usec increments when in the 'bad suspend' state, which would seem to indicate the CPU reached S0ix

• The command turbostat --show Pkg%pc2,Pkg%pc3,Pkg%pc6,Pkg%pc7,Pkg%pc8,Pkg%pc9,Pk%pc10,SYS%LPI rtcwake -m freeze -s 60 gives the following output:

  Pkg%pc2 Pkg%pc3 Pkg%pc6 Pkg%pc7 Pkg%pc8 Pkg%pc9 Pk%pc10 SYS%LPI
  1.10    0.86    0.00    0.00    0.00    0.00    96.75   0.00
  1.10    0.86    0.00    0.00    0.00    0.00    96.75   0.00

  which suggests good PC10 behavior (similar, I suppose, to the second bullet point).

Speculation:

Based on the LED behavior, it would appear that the EC is reading C10_GATE_N high, yet that seems to contradict the turbostat output and s0ix counter. So I'm not sure if either that loop is not being reached (and the EC is busy elsewhere?) or if the pin is actually staying high. I may try to add debugging statements to get more information, but neither debug option is something I have available at the moment, so I'm hoping this can repro for someone who has this setup already.

[mvysin]

On a hunch I replaced C10_GATE_N in the LED loop with SLP_S0_N (and sped up the blink rate to verify my change worked at all), and it works -- I see the increased blink rate when I suspend -- both with and without USB-C peripherals attached.

Separately while playing with the fan curves, I noticed the sound from the fan behavior in this bug is consistent with 50% duty cycle as set here when the PECI fails. That code is also controlled by C10_GATE_N.

So I think I can refine what I'm seeing (and hopefully consistent with the OP) as: when USB-C monitor (+ power? I cannot test them in isolation yet) is connected, C10_GATE_N remains inactive despite SLP_S0_N becoming active. When nothing is attached to USB-C then both signals become active and the EC works as I expect. In both cases it would appear that the cpu is entering sleep mode, but something about the USB-C connection is preventing the power signals controlled by C10_GATE from being removed.

[hansmerkl]

I am seeing the same issue on my galp5. When the device goes into suspend and my USB-C hub is connected, the fan spins up after a few seconds.

Adding logs as requested in https://github.com/system76/firmware-open/issues/222

sudo dmesg > dmesg.txt sudo journalctl -r > journal.txt

dmesg.txt journal.txt

One observation: this happens only with kernel 5.11. With 5.8 it's OK.

[hansmerkl]

Just wondering: Is there any hope for this to get fixed? It's a pretty annoying issue.

[deifactor]

Kernel 5.10.61 FW 2021-07-20_93c2809

Note that I did flash a custom EC, but only to hardcode "fn lock" in and to swap fn and ctrl. I started with the same EC version as was used to build the firmware version.

I am, perversely, experienceng this in a different way. Using a Plugabje UD-CA1a, starting with the dock attached, with no monitor plugged in:

1. I hit suspend. The laptop suspends (verified by looking at the slp_r0_residency_usec counter) but the LED stays solid. Fans aren't on.
2. Unplug the dock. The fans start spinning.
3. Plug the dock back in. Fans stop spinning.

If I have a monitor plugged into the HDMI output of the dock, then although the LED still stays solid, the fans never turn on even after unplugging and replugging.

One note: when the machine is docked and sleeping, I get a consistent clicking noise from the CPU which I assume is coil whine. I do get a small amount in normal use, but this is much louder and more consistent. The pattern is also different: "bad sleep" clicks about 4-5 times a second, but "good sleep" pauses occasionally. Undocked sleep doesn't click at all.

Testing with a USB-C monitor (i.e. no dock) acts like testing a dock with the HDMI monitor.

[hansmerkl]

One more observation: I booted Manjaro and Ubuntu from a USB drive and they showed the same behavior.

[hansmerkl]

Any news on this?

[Seibz]

If Pop!_OS installs have been updated to the more recent 5.13 kernel, this issue may be resolved.

[Seibz]

One more observation: I booted Manjaro and Ubuntu from a USB drive and they showed the same behavior.

Are you seeing this with the 5.13 and 5.14 kernels available for Manjaro?

[hansmerkl]

I didn’t check this. I guess I can take a look. Do you know how to do this when you boot from USB? I am pretty new to Linux.

On Wed, Oct 20, 2021 at 07:49 Seibz @.***> wrote:

One more observation: I booted Manjaro and Ubuntu from a USB drive and they showed the same behavior.

Are you seeing this with the 5.13 and 5.14 kernels available for Manjaro?

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/system76/firmware-open/issues/199#issuecomment-947744277, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABWJT65UH2USWWVCFZ46UL3UH3JJFANCNFSM43AEAVHA . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

[hansmerkl]

I managed to boot the latest Manjaro with kernel 5.13. Same behavior: Device doesn't suspend properly and the fan turns on.

[curiousercreative]

I'm no expert, but based on the findings above, this seems firmware related rather than kernel. Perhaps @mvysin has new findings?

[hansmerkl]

I'm no expert, but based on the findings above, this seems firmware related rather than kernel. Perhaps @mvysin has new findings?

I agree. How can we convince System76 to take a look at this? I find this a pretty annoying issue which almost makes me regret buying the galp5.

One thing to keep in mind is that at least for my machine things worked fine with kernel 5.8

[curiousercreative]

One thing to keep in mind is that at least for my machine things worked fine with kernel 5.8

Have you tried to repro the issue now running 5.8? I recall my problems persisting.

How can we convince System76 to take a look at this? I find this a pretty annoying issue which almost makes me regret buying the galp5.

Have you opened a support ticket? Maybe I'm in the minority here, but because I only have a dock at my in-laws and I'm affected by this bug so infrequently it's pretty back burner. If this was affecting me daily, I bet I would have been motivated to push the ball forward and make some progress. In general, S76 engineers are busy, but maintaining activity on an issue and helping with reproduction steps or troubleshooting to better define and identify the source of the problem goes a long way. (From personal experience with a couple issues that were eventually resolved here)

[hansmerkl]

One thing to keep in mind is that at least for my machine things worked fine with kernel 5.8

Have you tried to repro the issue now running 5.8? I recall my problems persisting.

How can we convince System76 to take a look at this? I find this a pretty annoying issue which almost makes me regret buying the galp5.

Have you opened a support ticket? Maybe I'm in the minority here, but because I only have a dock at my in-laws and I'm affected by this bug so infrequently it's pretty back burner. If this was affecting me daily, I bet I would have been motivated to push the ball forward and make some progress. In general, S76 engineers are busy, but maintaining activity on an issue and helping with reproduction steps or troubleshooting to better define and identify the source of the problem goes a long way. (From personal experience with a couple issues that were eventually resolved here)

I used to switch the kernel back to 5.8 but since one of the last updates Wifi doesn't work anymore when I do that. So that's not an option anymore.

I use the galp5 as one of my main work machines so it's most of the time connected to a USB dock with external monitor, mouse and keyboard. So this issue hits me a lot and I suspect a lot of other people who use it professionally.

I have submitted a support ticket and also a Github issue which then got merged with this one. I don't know what else I can do to help reproducing this. It seems it hits quite a few people (many others may not even have noticed this) and the description in this thread is pretty clear.

I am definitely a little disappointed that such a fundamental issue doesn't get addressed for months.

[curiousercreative]

@crawfxrd @jackpot51 any tips for troubleshooting next steps? We have a couple of good reproduction reports (here's one) that strongly suggest firmware rather than kernel. Do we have the ability to ec log during suspend or are we getting into additional hardware requirements?

[hansmerkl]

@crawfxrd @jackpot51 any tips for troubleshooting next steps? We have a couple of good reproduction reports (here's one) that strongly suggest firmware rather than kernel. Do we have the ability to ec log during suspend or are we getting into additional hardware requirements?

I would be happy to provide any kind of log or other information that’s needed. I am not a Linux developer but with some instruction i could run debuggers or whatever.

The issue is 100% reproducible on my machine.

[crawfxrd]

It is the firmware. But I wasn't able to determine what was causing it.

What I saw was C10_GATE# constantly asserted/deasserted, which results in:

• Linux reporting some PC10 residency time
• Power LED stays green because it's less that 1s
• Presumably, CPU constantly being put in/out of C10 causes a temperature spike, which turns on the fan

If you want EC logs during suspend, you will need a Mega 2560 and set up EC debugging.