Ubuntu 24.04.2 LTS, Dell Inc. Latitude 7390, Intel® Core™ i5-8350U × 8 This is a report and question. A short while ago my suspend quite waking up. Both if I simply walked away and it auto suspended or if I put it in suspend, it would not wake up. My research indicated this is a fairly common issue and kernel updates are often to blame. So I rebooted into the last kernel which is 6.8.0-52.53-generic 6.8.12, and suspend started working again. My question, is this more likely because my laptop is older? It's about 7 years old now. Also, how should I approach future kernel updates? Any reason not to leave it with kernel 6.8? Thanks all!
Asked
Active
Viewed 470 times
1 Answers
0
My question, is this more likely because my laptop is older? It's about 7 years old now.
No, it's unrelated. (to give you fun fact, on my previous work people couldn't make network card to run on some computer because there didn't exist Windows 7 drivers. The card worked just fine in modern Ubuntu though).
Also, how should I approach future kernel updates? Any reason not to leave it with kernel 6.8?
Well, this is a bug, some sort of regression.
As a user, if you don't want to dig into this, you could just avoid upgrading the kernel. It's not ideal, but it would work.
If you have motivation and spare time, you could try digging into it. First of all, it's worth testing latest released kernel, because 6.11 isn't the one. The version tagged as "stable" on this site is the latest one. Then you could try installing it by following these instructions and testing if it works.
Then if it does, you can again decide to leave your system at that kernel. Newer software is always better, 6.13 (latest one as of writing the words) has so many optimizations and features! If it doesn't work, you could report a bug to the kernel bugzilla. The point of testing latest mainline kernel here is so you can report upstream instead of downstream (downstream here is Ubuntu's "launchpad", and in my experience it's not the best place for bugs to be reported into…).
At that point, if you are still motivated, you could try to git-bisect the kernel to see which commit introduced the problem. That would require building the kernel manually, so it really requires some motivation on your part. But if you do that, regressions with known commits are usually easily fixed, you just send to the mailing list an email saying "[REGRESSION][BISECTED] …" and describing the bug and the bisection result, and adding to CC the offending commit author as well as the maintainers (maintainers and the mailing list could be found by running perl scripts/get_maintainer.pl -f path/to/problematic/source-code/file in the source tree).
Hi-Angel
- 4,810