[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: No sound on laptop after linux-libre 5.15
From: |
Thiago Jung Bauermann |
Subject: |
Re: No sound on laptop after linux-libre 5.15 |
Date: |
Wed, 08 Dec 2021 23:34:24 -0300 |
Hello Paxton,
Em quarta-feira, 8 de dezembro de 2021, às 01:55:13 -03, Paxton Evans
escreveu:
> Rolling back to linux-libre 5.14.21 (guix
> ea7233befb9570cce47e5ca71725b285a580cd22) totally fixes this issue.
>
> Troubleshooting sound issues on GNU/Linux is such a nightmare that I'm
> hoping this list can help me, as I don't really know much about how
> sound on our favorite OS really works, and don't have enough information
> to file a bug. Can anyone give me pointers on where to start looking?
> dmesg on 5.15.6 didn't seem to report anything strange.
I’m not particularly familiar with the moving parts that make sound work
either, so I’ll focus on the kernel side of things. My first idea would be
trying to boot with the “debug” kernel command line option, which increases
the verbosity of kernel messages. Perhaps something helpful will show up in
dmesg that way?
If not, and if the only change in the working setup vs the non-working
setup is the kernel version, then it’s a regression in the kernel. If you
are willing to run the upstream Linux kernel on your machine (i.e., the
non-libre kernel), the first step would be to run Linux v5.15.6 and see if
sound works.
If it does, then it’s a bug in linux-libre itself and you should report the
problem to them. If it doesn’t, it’s a bug in Linux itself and the most
straightforward (but tedious and time-intensive) way to find the kernel
commit that caused the bug is to use “git bisect”:
https://wiki.gentoo.org/wiki/Kernel_git-bisect
That is, assuming that you are comfortable building kernels.
You need to use v5.14 as your known-good version not v5.14.21 because your
range should be a “straight line” in the version history, and v5.14.x
versions branch off from mainline and thus aren’t ancestors of v5.15.x.
Also, since you’d be running random kernel commits, it’s important to be
aware that there’s a small but non-zero risk of running a bad kernel
version which could corrupt something on your system. E.g., not long ago
during the v5.12 development cycle there was a filesystem corruption bug:
https://www.phoronix.com/scan.php?page=news_item&px=Linux-5.12-Corruption-Fixed
You wouldn’t be at risk of hitting that particular bug since your range
starts at v5.14, but it’s not inconceivable that there could be something
bad in your range (though I’m not aware of anything). The safest way to
address that is to run the bisect kernels in a temporary Linux installation
on your machine, such as in a USB flash drive rather than on your main Linux
installation.
--
Thanks,
Thiago