Lenovo P16s crash on plug or unplug USB-C Thunderbolt

I have a Lenovo P16s (21K90038US) with AMD 7840U, 64GB, and 4k OLED, chipset AMD [1022:14e8], which is very nice but has difficulties. I had to add module_blacklist=ucsi_acpi to the boot line. The soldered-in wifi is incompatible with Xen so I have ath11k blacklisted. (The driver, when I let it try to initialize, wanted more than sys-net’s 400MB default; 650MB seemed to suffice.) I am using a BrosTrend AC5L usb wifi dongle (Realtek 0bda:c811 rtw88_8821cu) instead, which works fine. I make do without bluetooth.

What doesn’t work fine is the Thunderbolt USB-C sockets. This is a problem as the laptop charges through one of them. Plugging or unplugging one causes an instant crash and reboot, with a momentary little text-graphic of the Linux penguin. It doesn’t matter if it is at the login screen, or suspended. When booted from a Debian 12.11 live USB image, though, plugging and unplugging power and other USB-C gadgets works fine, as does the ath11k wifi. [Xen 4.17.5-7, Linux 6.14.4-1]

Usefully, I have discovered that keeping a multiport dongle (Lenovo LC700) plugged in to the USB-C port, and plugging and unplugging the charger from that, works fine. Unplugging the dongle itself, with or without power, crashes reliably. Thus, the laptop alone is not meaningfully portable, but the laptop + dongle treated as a unit is.

I have not fooled with BIOS settings yet, but the BIOS is up-to-date (R2FET61W 1.41). It has an internal socket meant for an M.2 B-key Quectel WWAN card, with antenna leads nicely delivered. Unfortunately, all M.2 Wifi cards I find are A+E-keyed instead.

I am posting this for anybody else who needs to get a Lenovo P16s or similar working, and to collect suggestions as to how to rehabilitate the Thunderbolt ports. And I hope that Xen will someday learn how to pass an ath11k through to sys-net.

But see https://forum.qubes-os.org/t/know-how-t470-usb-c-thunderbolt-how-to-use/30641

1 Like

See Issue 9777
Apparantly solution also reported but developers are not at all interested in patching.:angry:

“Supposedly this patch solves the problem” is not really a good basis for incorporating it in the main build for every single Qubes-os user. There is no indication of the origin of the patch, no assessment of its impact on security, on unaffected systems, and only one person in the linked thread who claims to have installed it. What does it even do ?
It am sure it is very painful for those using this laptop, but this is not yet sounding like a fully-baked solution.

You are right it’s not a good option for all maybe.
But it’s not like that it can’t be reviewed by Qubes OS developers, but right now they’re not interested it seems.

I understand your frustration, but I am guessing, without looking at the contextual code, that the review of that patch went something like this:

  • Problem sounds like an ACPI quirk, or Linux driver bug. It doesn’t immediately sound like a bug in xen…
  • Patch seems to be meddling with the deep innards of xen (I might be wrong, I am just guessing from the filename)
  • It is possible the patch is misguided, or even malicious.
  • Best to wait until a better analysis or more information is available, or an upstream fix.

Note that the Qubes Devs must concentrate on Qubes code… and trust the upstream Devs for their zones of expertise.
[Edit: …and that’s a good reason to trust the Qubes team!]

Anyway the workaround of keeping a USB hub/dongle plugged in means the bug need not make typical use of the laptop impossible.

1 Like

I add here that the Wi-fi dongle I use also needs rather more than the default memory allocated to sys-net, to start be able to start up. 800M suffices.