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
vss2idle
.
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.