You’ve now completely disabled the intel_idle driver – which has the kernel retreat to the ACPI driver and which might in fact be good enough but you may also have some configuration available in your BIOS setup as to C-states and perhaps tweaking something there could cause you less battery than the possibly suboptimal ACPI driver (I’ve noticed that on a laptop you have less chance of that than on a desktop, though).
Anycase, yes, let’s first try and see if it does anything at all…
First just don’t do anything; I may be barking up a completely wrong tree here
It’s otherwise not related to Manjaro; you’d enter your BIOS-setup by tapping e.g. the Del key, or F2 or F9, or … when the system starts up and then look around for anything suspicious. But for now just wait and see.
Because maybe you have to take care of the other things i mentioned too.
When both audio servers run, in some instances, on some systems things can start to choke. Happened on one of my installs. Here is how to avoid that, if that could be part of your issue.
Same as explained from here:
but you use the intel_pstate=active kernel parameter instead.
on Grub boot menu you press the e key and then on the Linux Kernel Line, you add right after the quiet the intel_pstate=active and then press F10 to save it and continue booting. That is not a permanent entry
or permanent entry, by editing the file
but honestly, there is no point to repeat that …
You don’t. is required, but in order to not keep it active you simply install manjaro-pipewire and will do for you all is required. Just reboot after that to take effect.
If you did it from GRUB menu, then yes, you lose that upon reboot.
If you did it on /etc/default/grub then updated grub, then you don’t have to do it again.
You can, but if you now also add the by bogdancovaciu advised “intel_pstate=active” kernel parameter then you won’t know if it was that one or the earlier advised “intel_idle.max_cstate=0” parameter which you added before. It’s in that sense probably useful to test either in isolation – at the moment
cat /proc/cmdline
should be saying that you are running with “intel_idle.max_cstate=0”. If you let it run long enough to be satisfied that it’s now not freezing you’d have pinpointed it to that intel_idle driver.
I.e., again my advise is to for now sit back and do nothing until either the system freezes again or you’re satisfied that it won’t anymore.
Yup. If the system’s now stable for long enough without rebooting it’ll be confirmed that it’s that c-state thing again. You can in that case keep things as they are, try “intel_idle.max_cstate=1” instead, or as mentioned try and rummage through your BIOS setup (I believe it’s by the way for your machine a matter of tapping F10 while it’s starting to get there) to see if there’s anything possibly related to set there.