Upstream kernel: starting slack shuts down laptop (snd_pcsp module implicated)

Framework Laptop 16 Linux
1

Which Linux distro are you using?
Which release version?

Debian Sid, updated a few days ago.

Which kernel are you using?

Any unmodified upstream kernel around (at least) 6.10.0 to current git (6.12.0 rc4), compiled using .config file from Debian kernel as a basis (make oldconfig and accept defaults to handle differences).

Which BIOS version are you using?

3.03

Which Framework Laptop 16 model are you using? (AMD Ryzen™ 7040 Series)

AMD Ryzen 7 7840HS w/ Radeon 780M Graphics

I normally use the Debian-provided kernel, but recently I have been testing upstream kernels. I ran into a strange problem: when I start slack (the desktop client, not the web client at https://slack.com/), the laptop shuts down. It doesn’t hang, or show a kernel panic, or anything like that–it just powers off completely.

This happens within a few seconds of when slack finishes loading and rendering the window.

There are no relevant messages in journalctl -b -1. Apparently, if anything is logged, it never gets synced to disk.

The Debian kernels are not affected by this. I tracked the difference down to this patch:
https://sources.debian.org/patches/linux/6.11.4-1/debian/snd-pcsp-disable-autoload.patch

If I apply that patch on top of current upstream kernel git, then I do not get the shutdown.

I can also work around the problem by creating /etc/modprobe.d/no-snd_pcsp.conf:

install snd_pcsp /bin/false

(or by rmmod snd_pcsp, on a temporary basis).

I have not found any way to induce the problem other than by running slack.

The workaround is not a burden, but I spent a bunch of time narrowing down the problem, and hopefully this report will be useful to someone. I could not find the problem reported elsewhere.

-Corey

2

How about following man modprobe.d and setting blacklist snd_pcsp in that file? Does that work around this?

K3n.

3

How about following man modprobe.d and setting blacklist snd_pcsp in that file? Does that work around this?

I used install as a more thorough way of preventing a module from loading.

https://wiki.archlinux.org/title/Kernel_module#Blacklisting

In this case, blacklist does indeed work around the problem too, though.

The blacklist method still allows a manual sudo modprobe snd_pcsp to load the module. Oddly, it seems that loading the module manually after boot does not result in a shutdown when I run slack.

If instead the module is allowed to load at boot, then removed (rmmod), then loaded again (modprobe), slack does still cause a shutdown.

This doesn’t make much sense to me, but that is what I have observed.

-Corey

4

FWIW, I use the Slack flatpak from flathub and I haven’t seen this. Different distro though, Fedora 40 currently on 6.11.5-200.fc40.x86_64. pcspkr is loaded, but snd_pcsp isn’t. Default modprobe configuration, so no blacklisting involved.

5

Yes, Debian’s default kernel doesn’t have this problem either, due to the patch I mentioned. Fedora may have a similar patch. I only noticed this because I compiled and used an unmodified upstream kernel (for some unrelated testing).

Thanks,
Corey