TB4 dock issues with wake from sleep, workaround, s2idle vs deep and firmware question (11 gen)

So a few days ago I installed this TB4 dock and overall had a good experience. Over this time I had to implement a couple of workarounds that I felt deserved their own thread as they point to a possible combination of Linux specific quirks and also questions for Framework re: the firmware and specifically the behavior of the EC/TB controllers.

  • Is s2idle “officially” supported for Linux?

I’m asking because in order to use it, I have to tell Linux to tell the firmware that it doesn’t support Windows 2020:

I still need to specify this in order to be able to use s2idle under Fedora 37 and latest 6.x kernels; otherwise, the machine immediately wakes up immediately after every suspend attempt.

Anyway, at some point after I had made that post above I had switched back to deep sleep, because the way the acpi_osi arg ends up being escaped in /etc/default/grub is causing an error to be emitted during kernel updates. Even though there seemed to be no actual damage from this, I didn’t like the idea. Here’s what this would look like in /etc/default/grub:

GRUB_CMDLINE_LINUX="... "acpi_osi=!Windows 2020""

Those extra double quotes were throwing some install/update script off.

So, first question: @Matt_Hartley is this acpi_osi workaround for s2idle “expected” with Linux, and/or, is it a known issue that we can expect to be addressed in a firmware update?

Moving on:

  • TB behavior in deep vs s2idle.

Once I started using the TB dock I quickly found that upon wakeup from S3/deep sleep, the thunderbolt link would not be powered up again. The dock has a LED that shows link status and it stayed off after the laptop was woken up, so external monitor/keyboard etc would not work.

So back to s2idle I went, as I noted in my (very slightly premature) victory declaration in the dock megathread:

That worked well for a few days, until yesterday I noticed that despite the acpi_osi workaround, when suspending while docked the machine would now immediately wake up again.

Not sure what changed, since it didn’t do that before. It might even be some state change in the dock for all I know, as I had other machines connected to it in the meantime.

I assumed that something in the new devices exposed through the dock (and specifically a state change that is reported on one of them when going to sleep) was being treated as a wakeup trigger by the (firmware? kernel?)

So I have worked around this issue by applying my cargocult level understanding of ACPI wakeup triggers and blacklisting everything except the power button:

#!/usr/bin/bash

for device in `tail -n +2 /proc/acpi/wakeup |egrep -v 'PWRB|PXSX' |grep enabled |cut -f 1`; do
  echo "disabling $device"
  sh -c "echo $device > /proc/acpi/wakeup"
done

From the journal, this finds and disables several devices that are TB dock related:

PEG0
XHCI
RP10
TXHC
TDM0
TDM1
TRP0
TRP1
TRP2
TRP3

So far I haven’t had any issues with the laptop waking up after suspend, including when unplugging and replugging it to the dock. Still using s2idle.

So, another question for FW: Is there something in the future improvements that have been mentioned for the 11th gen firmware that could improve this? Thinking of the (in)famous USB retimers here although I have no idea if they really apply.

We have good support for TB4 devices. I am running an eGPU successfully for example. That said, suspend connected to a third party device falls outside of our support scope. We try to help when we have time with any suggestions that may occur to us. But we simply provide ThunderBolt Certified support 12th gen. Whether it suspends successfully or not will depend on the dock, the dock’s vendor, their tech, etc.

We welcome any community insights, etc. But we lack access to the various docks and are focused making sure the laptop itself, works.

Personally, I don’t suspend anything with docks attached.

If you’re having success with

GRUB_CMDLINE_LINUX="… “acpi_osi=!Windows 2020"”

This is what I would suggest be used. I know this isn’t ideal, but it’s a logistical reality as we’re a small team.

No dock, there is no special parameter needing to be added for s2idle on supported distros (Ubuntu and Fedora).

For this, there are always improvements being implemented. But I do not have any timelines.

Thanks for getting back Matt!

I did mix several distinct issues in this post but felt it was better to do so as there is also interplay between them once the dock is brought into the picture, so it was better to have the full scenario in one place.

On the s2idle issue in isolation: Requiring the acpi_osi="!Windows 2020" kernel cmdline arg is completely independent of the dock. I’ve faced that since more than a year ago. Just tested it again on a clean, undocked boot minutes ago to make sure:

Without that arg, the laptop doesn’t go “completely” into s2idle sleep. At the very least, the keyboard backlight stays on and the power button remains solid on, instead of “breathing”. This on a supported distro (Fedora 35/36/37), starting with BIOS 3.07 back then IIRC, through to 3.17 now. So I was wondering what else on my hardware could be special, since it seems this extra argument “shouldn’t” be required. Could it be the disk?

01:00.0 Non-Volatile memory controller: Samsung Electronics Co Ltd NVMe SSD Controller SM981/PM981/PM983

$ udisksctl status
MODEL                     REVISION  SERIAL               DEVICE
--------------------------------------------------------------------------
Samsung SSD 970 EVO Plus 2TB 2B2QEXM7  ............      nvme0n1 

Because of the need of this extra argument to get s2idle to work “completely” and the additional warning that its addition (via grubby) causes wrt /etc/default/grub, several months ago (still no dock in the picture) I switched to S3/deep sleep. I only revisited this about a week ago because of the dock: Resuming from deep sleep while docked now created its own set of issues, which I understand is pushing the envelope too far. So back to acpi_osi and s2idle I went.

For what it’s worth though, just for completeness, with s2idle sleep the dock has been pretty good across suspend/resume, including when forcing a “dock status change while sleeping”: suspend, dock (or undock), resume. I’ll take that unsupported win :slight_smile: