Page 1 of 1

an acpi menace to linux in some uefi-ed computers

Posted: Sat Apr 27, 2019 8:32 pm
by TJ Hoye
.
I have a new Dell Inspiron 5570 which I like a lot, but i think it has an ACPI system that probably
works well with a Dell Windows 10 uefi setup, but which shows about 32 complaints in dmesg
when booting MX-Linux booting in either legacy or uefi, and/or using one of several different kernels.

At a minimum it would be nice to have a boot option acpi=off for MX-18 Linux.
There are a few loaded modules in MX-18.2 which grep to acpi, but not enough, apparently.

Here's the typical dmesg evidence:

demo@mx1:~
$ alias dmx; dmx | grep -i acpi
alias dmx='dmesg | grep -i --color " bug\|warn\|fail\|error\|corrupt"'
[ 0.284218] ACPI Error: No pointer back to namespace node in package 000000000677283f (20181003/dsargs-303)
[ 0.284565] ACPI Error: No pointer back to namespace node in package 00000000280dc3bd (20181003/dsargs-303)
[ 0.284696] ACPI Error: No pointer back to namespace node in package 0000000028d6fd57 (20181003/dsargs-303)
[ 0.285257] ACPI Error: No pointer back to namespace node in package 000000000677283f (20181003/dsargs-303)
[ 0.285551] ACPI Error: No pointer back to namespace node in package 00000000280dc3bd (20181003/dsargs-303)
[ 0.285613] ACPI Error: No pointer back to namespace node in package 0000000028d6fd57 (20181003/dsargs-303)
[ 0.288528] ACPI: [Firmware Bug]: BIOS _OSI(Linux) query ignored
[ 0.293338] ACPI Error: No pointer back to namespace node in package 000000000677283f (20181003/dsargs-303)
[ 0.293355] ACPI Error: No pointer back to namespace node in package 00000000280dc3bd (20181003/dsargs-303)
[ 0.293362] ACPI Error: No pointer back to namespace node in package 0000000028d6fd57 (20181003/dsargs-303)
[ 0.294283] ACPI Error: No pointer back to namespace node in package 000000000677283f (20181003/dsargs-303)
[ 0.294300] ACPI Error: No pointer back to namespace node in package 00000000280dc3bd (20181003/dsargs-303)
[ 0.294307] ACPI Error: No pointer back to namespace node in package 0000000028d6fd57 (20181003/dsargs-303)
[ 0.294566] ACPI Error: No pointer back to namespace node in package 000000000677283f (20181003/dsargs-303)
[ 0.294583] ACPI Error: No pointer back to namespace node in package 00000000280dc3bd (20181003/dsargs-303)
[ 0.294589] ACPI Error: No pointer back to namespace node in package 0000000028d6fd57 (20181003/dsargs-303)
[ 0.294811] ACPI Error: No pointer back to namespace node in package 000000000677283f (20181003/dsargs-303)
[ 0.294827] ACPI Error: No pointer back to namespace node in package 00000000280dc3bd (20181003/dsargs-303)
[ 0.294833] ACPI Error: No pointer back to namespace node in package 0000000028d6fd57 (20181003/dsargs-303)
[ 0.295664] ACPI Error: No pointer back to namespace node in package 000000000677283f (20181003/dsargs-303)
[ 0.295681] ACPI Error: No pointer back to namespace node in package 00000000280dc3bd (20181003/dsargs-303)
[ 0.295687] ACPI Error: No pointer back to namespace node in package 0000000028d6fd57 (20181003/dsargs-303)
[ 0.295979] ACPI Error: No pointer back to namespace node in package 000000000677283f (20181003/dsargs-303)
[ 0.295995] ACPI Error: No pointer back to namespace node in package 00000000280dc3bd (20181003/dsargs-303)
[ 0.296002] ACPI Error: No pointer back to namespace node in package 0000000028d6fd57 (20181003/dsargs-303)
[ 0.296300] ACPI Error: No pointer back to namespace node in package 000000000677283f (20181003/dsargs-303)
[ 0.296317] ACPI Error: No pointer back to namespace node in package 00000000280dc3bd (20181003/dsargs-303)
[ 0.296323] ACPI Error: No pointer back to namespace node in package 0000000028d6fd57 (20181003/dsargs-303)
[ 0.304001] PCI: Using host bridge windows from ACPI; if necessary, use "pci=nocrs" and report a bug
[ 7.049840] ACPI Error: No pointer back to namespace node in package 000000000677283f (20181003/dsargs-303)
[ 7.049847] ACPI Error: Method parse/execution failed \_SB.PCI0.B0D4.PPCC, AE_AML_INTERNAL (20181003/psparse-516)
[ 7.051924] ACPI Warning: \_SB.IETM._TRT: Return Package has no elements (empty) (20181003/nsprepkg-96)
demo@mx1:~

Re: an acpi menace to linux in some uefi-ed computers

Posted: Sat Apr 27, 2019 9:25 pm
by Stevo
There were some acpi tweaks one could apply at boot for Dells, like the one in the troubleshooting section in the Debian wiki:
- If your laptop locks up during boot when starting the graphical display you may need to add a kernel parameter to set acpi_osi="!Windows 2015" or some variant.

This is a known ACPI problem with 2017 Dell XPS 15 and others

Re: an acpi menace to linux in some uefi-ed computers

Posted: Sat Apr 27, 2019 9:31 pm
by JayM
TJ Hoye wrote: Sat Apr 27, 2019 8:32 pm At a minimum it would be nice to have a boot option acpi=off for MX-18 Linux.
If you run MX Tools/MX Boot Options you can add acpi=off to your boot parameters. That utility will update grub for you when you click Apply.

Welcome to the forum.

Re: an acpi menace to linux in some uefi-ed computers

Posted: Sat Apr 27, 2019 11:06 pm
by Stevo
I would manually add boot commands like that in GRUB and make sure they worked before making them permanent. But that's me.

Re: an acpi menace to linux in some uefi-ed computers

Posted: Sat Apr 27, 2019 11:33 pm
by JayM
Stevo wrote: Sat Apr 27, 2019 11:06 pm I would manually add boot commands like that in GRUB and make sure they worked before making them permanent. But that's me.
Good point.

Re: an acpi menace to linux in some uefi-ed computers

Posted: Sun Apr 28, 2019 12:16 am
by BitJam
There should be an "acpi=off" option in the "F4 Options" menu in the live legacy bootloader. If it is not there, I will try to make sure it gets back in.

I believe TJ Hoye is always running live so the instructions for changing the bootloader parameters are a little different. Terry (TJ) was one of the early adopters of the MX-14.x live system. I believe he has been running MX live ever since. IIRC Terry came to MX from Knoppix (the running live grand-daddy) because of our live system.

A Google(ACPI Error: No pointer back to namespace node in package) shows there have been some kernel patches to get rid of these messages. Maybe the patches didn't make it into the main branch or maybe there was a reversion. Maybe the fix only works on certain hardware.

Re: an acpi menace to linux in some uefi-ed computers

Posted: Sun Apr 28, 2019 4:26 am
by JayM
BitJam wrote: Sun Apr 28, 2019 12:16 am There should be an "acpi=off" option in the "F4 Options" menu in the live legacy bootloader. If it is not there, I will try to make sure it gets back in.

I believe TJ Hoye is always running live so the instructions for changing the bootloader parameters are a little different. Terry (TJ) was one of the early adopters of the MX-14.x live system. I believe he has been running MX live ever since. IIRC Terry came to MX from Knoppix (the running live grand-daddy) because of our live system.

A Google(ACPI Error: No pointer back to namespace node in package) shows there have been some kernel patches to get rid of these messages. Maybe the patches didn't make it into the main branch or maybe there was a reversion. Maybe the fix only works on certain hardware.
A patch was issued in May 2018: https://bugzilla.kernel.org/show_bug.cgi?id=199413 I wonder what kernel TJ is using? Perhaps one from before the patch?

Other search results suggest that those ACPI warning messages during boot can be safely ignored. However, they do kind of clutter up the boot progress if you're booting nosplash to try to spot other messages so it would be nice to be rid of them.

Re: an acpi menace to linux in some uefi-ed computers

Posted: Sun Apr 28, 2019 6:14 pm
by TJ Hoye
Thanks to all for your suggestions.

As usual, I'm learning as I go, so I'll fill you in on a few more important details.
First, as BitJam already knows, I'm exclusively MX and exclusive LiveUSB.
Second, I have an older 1545 Inspiron that is failing, and a new 5570 Inspiron that has some Linux
ailments. I'm hoping to use a 64-bit MX 18.2 LiveUSB or its clone on both.
Third, the 1545 is only legacy mode. I originally thought I could use the 5570 in a legacy mode.
I now think that's not currently possible; the 5570 only works uefi AFAICS.

@ Stevo, thanks. No lock-ups AFAICT, but using acpi=off, I have to hit the power button to shut down.
I don't know how to wok on grub to fix anything.

@ JayM, thanks. I don't know how to change grub. I don't like ignoring warnings, maybe this
behavior is exploitable. I've only used 4.19.0 and 4.20.12 kernels myself on MX-18.2 Live.

@ BitJam, thanks also for PM tutoring. I don't have the F4 & F8 options on the 5570 since I don't
find a way to boot legacy except on the 1545. Still looking for a way to save the boot
command acpi=off.

TJH

Re: an acpi menace to linux in some uefi-ed computers

Posted: Sun Apr 28, 2019 7:32 pm
by BitJam
TJ Hoye wrote: Sun Apr 28, 2019 6:14 pm Still looking for a way to save the boot command acpi=off.
As I said in the PM, highlight the entry you want to boot from and then press 'e' to edit it. Add "acpi=off" and also add "menus=s" to the line that starts with "linux" then press <F10> to boot. You will be asked if you want to save these settings. Select "yes".

You can also directly edit the /boot/grub/grub.cfg file. If you are booting from a live-usb then you need to edit the file on the small fat32 partition on the live-usb. Starting with antiX-19, fehlix improved our live boot system so you will be able to edit the grub.cfg on the main live-usb partition mounted at /live/boot-dev/ to make changes like this.

IIRC, for a number of years the need to use "acpi=off" had decreased drastically but then the need shot up recently. It was usually older systems that needed it. Until now there has been very little (or no) demand for acpi=off when booting UEFI. If this problem isn't fixed upstream then we may need to add another grub entry with "acpi=off" but I hope it won't come to this.

Re: an acpi menace to linux in some uefi-ed computers

Posted: Sun Apr 28, 2019 8:35 pm
by TJ Hoye
BitJam wrote: Sun Apr 28, 2019 7:32 pm
TJ Hoye wrote: Sun Apr 28, 2019 6:14 pm Still looking for a way to save the boot command acpi=off.
{/quote}

As I said in the PM, highlight the entry you want to boot from and then press 'e' to edit it. Add "acpi=off" and also add "menus=s" to the line that starts with "linux" then press <F10> to boot. You will be asked if you want to save these settings. Select "yes".
[ /quote]

Thanks, BitJam.
I just tried this again and it works fine. I must have mis-typed. menus=s; I didn't get a choice to select "yes" earlier.

I'm no longer sure I can find any boot combination that allows me to legacy boot get a my 5570 with my MX LiveUSB. Does that seem reasonable?
I would like to get both uefi and acpi out of the equation here if I can. I don't want to just turn off the warnings, unless that's all I can do.

Using the 1545 and legacy boot there are fewer acpi errors and these seem to be a bug in 1545 which shuts down aspm automatically.
I think this says fix the 1545 or don't worry about the errors.

Using the 5570 and uefi there are 32 acpi errors, and i wonder if maybe some drivers are missing or if MX's uefi might be part of the problem.
I think this says either find out how to boot 5570 in legacy or get smarter about using uefi on acpi. Too many errors to ignore here.
So should I be able to find a way to boot 5570 in legacy mode?

Re: an acpi menace to linux in some uefi-ed computers

Posted: Mon Apr 29, 2019 3:38 pm
by TJ Hoye
demo@mx1:~
$ dmx | grep --count ACPI
32
demo@mx1:~
$ acpi -V
Battery 0: Full, 100%
Battery 0: design capacity 3684 mAh, last full capacity 3500 mAh = 95%
Adapter 0: on-line
Thermal 0: ok, 25.0 degrees C
Thermal 0: trip point 0 switches to mode critical at temperature 107.0 degrees C
Cooling 0: Processor 0 of 3
Cooling 1: Processor 0 of 3
Cooling 2: iwlwifi no state information available
Cooling 3: Processor 0 of 3
Cooling 4: Processor 0 of 3
Cooling 5: INT3400 Thermal no state information available
Cooling 6: Processor 0 of 3
Cooling 7: SEN1 no state information available
Cooling 8: Processor 0 of 3
Cooling 9: x86_pkg_temp no state information available
Cooling 10: Processor 0 of 3
Cooling 11: intel_powerclamp no state information available
Cooling 12: pch_skylake no state information available
Cooling 13: Processor 0 of 3
Cooling 14: TMEM no state information available
demo@mx1:~
$ lsmod | grep -i acpi
snd_soc_acpi_intel_match 28672 1 snd_soc_skl
snd_soc_acpi 16384 2 snd_soc_acpi_intel_match,snd_soc_skl
acpi_thermal_rel 16384 1 int3400_thermal
acpi_pad 20480 0
demo@mx1:~

Here's a few more clues:

1. I had a dream that a later kernel might know how to talk to uefi better.
ND. Still getting 32 dmesg gripes. Remastered, brought in 5.0.1 amd64 antiX kernel,
and used MX-Tools to do LiveUSB Kernel Install. Except(!) for acpi, 5.0.1 seems happy on Inspiron 5570 uefi boot.

2. Using acpi -V, some acpi functions are actually working; they were working for kernels 4.19 and 4.20 as well.

3. Grepping the modules loaded, four of them seem appropriate, just a minority of those required? Was same
for kernels 4.19 and 4.20.

4. I have the suspicion that there might be a missing cache of names which include catchwords like:
Thermal, Battery, Cooling, Adapter, possibly eight in all, that uefi wants to communicate-with concerning ACPI.
In this phantasy, it would be necessary to provide all of these names and the parameters they in turn require,
for this Inspiron 5570 to perform the necessary ACPI functionality. There a some tantalizing clues in acpi -V.

TJH

Re: an acpi menace to linux in some uefi-ed computers

Posted: Tue Apr 30, 2019 12:34 am
by Stevo
If the laptop works better even with the acpi warnings at boot, why turn acpi off?

Re: an acpi menace to linux in some uefi-ed computers

Posted: Tue Apr 30, 2019 11:10 am
by TJ Hoye
Stevo wrote: Tue Apr 30, 2019 12:34 am If the laptop works better even with the acpi warnings at boot, why turn acpi off?
Hello, Stevo.

It 'works' well enough either way, except that acpi features chores are short-changed.
I think uefi is telling us the linux kernels I've tried need to tell us more about this fabulous 5570 computer.
I wish I knew someone that could look at the 5.0 kernel source and see if there are some acpi hooks
that might be used, that normally wouldn't be of any use on a lot of 'older' computers.
Not being a programmer, that's something I could not probably pull off successfully myself.

TJH

Re: an acpi menace to linux in some uefi-ed computers

Posted: Tue Apr 30, 2019 12:50 pm
by j2mcgreg
Have you tried the Liquorix 5 series kernel that is available via MXPI? I installed it into my test machine and then made a snapshot which I used to successfully install MX18.2 on my troubled Acer Aspire 3 a315. I seem to remember some reference here that the newer Dells use the same Insydeh20 Set-up Utility as the Acer does.

Re: an acpi menace to linux in some uefi-ed computers

Posted: Tue Apr 30, 2019 1:10 pm
by TJ Hoye
j2mcgreg wrote: Tue Apr 30, 2019 12:50 pm Have you tried the Liquorix 5 series kernel that is available via MXPI? I installed it into my test machine and then made a snapshot which I used to successfully install MX18.2 on my troubled Acer Aspire 3 a315. I seem to remember some reference here that the newer Dells use the same Insydeh20 Set-up Utility as the Acer does.
Hello, j2ncgreg, and thanks for your question.

No, I have not tried a Liquorix 5 kernel. I've only added a repo to my Synaptic and brought in one of antiX's kernels.
It's just a hunch that antiX couldn't care less about acpi, since his genre seems to be more comfortable with 'older' hardware.
I'm probably not qualified myself to do much more than complain, but how might I go about getting some other kernel than
what I'm immediately able to find in MX and antiX territory?

Also, what do you get for dmesg comments re acpi, and what do you get for acpi -V? n.b. that's cap V.

TJH

Re: an acpi menace to linux in some uefi-ed computers

Posted: Tue Apr 30, 2019 3:24 pm
by Stevo
The latest Liquorix kernel is dead easy to install in the MX Package installer...

Also, if you do web searches for the ACPI warnings you're getting along with "Dell", I'm sure you will find other posts from concerned Dell owners in other distros' forums that should be informative.

Re: an acpi menace to linux in some uefi-ed computers

Posted: Tue Apr 30, 2019 7:06 pm
by TJ Hoye
Stevo wrote: Tue Apr 30, 2019 3:24 pm The latest Liquorix kernel is dead easy to install in the MX Package installer...

Also, if you do web searches for the ACPI warnings you're getting along with "Dell", I'm sure you will find other posts from concerned Dell owners in other distros' forums that should be informative.
Hello again, Stevo.

I tried using MX-Tools to install a Liquorix kernel.
This process failed, but returned me to a significantly different situation with the antiX 5.0 kernel.
1. There is now only one dmesg entry about ACPI instead of 32.
2. There are two less modules loaded which address ACPI.
3. acpi -V still says it isnt getting the stuff it needs to set up ACPI.

I'm using a LiveUSB, and I think using MX-Tool pkg installer is not meant to work for LIveUSB kernel installs.
That's why MX-Tools has a LiveUSB kernel installer. That installer uses Synaptic for its kernel material,
and I don't know where to point it to get Liquorix material.

So, without my participation, my antiX kernel is a lot quieter, but still not helping on the ACPI front.

Evidence is as follows, for comparison with previous similar commands.
BitJam can probably explain why the MX package installer fails for LiveUSB kernels.

demo@mx1:~
$ acpi -V
No support for device type: power_supply
No support for device type: power_supply
Cooling 0: intel_powerclamp no state information available
Cooling 1: x86_pkg_temp no state information available
Cooling 2: pch_skylake no state information available
Cooling 3: iwlwifi no state information available

demo@mx1:~
$ alias dmx; dmx | grep -c ACPI
alias dmx='dmesg | grep -i --color " bug\|warn\|fail\|error\|corrupt"'
1

demo@mx1:~
$ dmx | grep -i acpi
[ 1.736482] ACPI: <n/a>: failed to evaluate _DSM (0x1001)

demo@mx1:~
$ lsmod | grep -i acpi
snd_soc_acpi_intel_match 28672 1 snd_soc_skl
snd_soc_acpi 16384 2 snd_soc_acpi_intel_match,snd_soc_skl
demo@mx1:~

TJH

Re: an acpi menace to linux in some uefi-ed computers

Posted: Wed May 01, 2019 7:40 pm
by TJ Hoye
I have tentatively concluded the following about acpi in MX-Linux.

1. Acpi is an enormous black hole to avoid as much as we can.
A more experienced person than I has expressed his feeling this way:
https://www.markshuttleworth.com/archives/1332
2. You can't ignore it entirely without hurting yourself; for example,
acpi=off is not a good policy because it may disrupt other things.
3. All those features that help your battery last longer don't matter
much if you always power up with an ac adapter.
4. Acpi features which tell you about the thermal situation, and other
states of your computer may be available to you at the command line.
Try out acpi -V sometime at the command line; this begs for a little GUI
to present these a little more easily.
5. Some linuxes, MX-for example, don't fully implement all the features
of acpi, but acpi interfaces and unused hooks abound. And these are
both plentiful and well advertised. This would seem to me to be possibly
exploitable by someone smarter than me.
6. I have two laptop pcs: a Dell 1545 legacy-boot 10-year-old and
a brand-new, almost, Dell 5570 with uefi. These comments represent
my total personal hardware experience with acpi.

I'd be glad to hear other opinions than my own on this topic.

Re: an acpi menace to linux in some uefi-ed computers

Posted: Wed May 01, 2019 9:52 pm
by Stevo
How did the Package Installer fail to install the latest Liquorix kernel? That should have "just worked". Could you provide some more details?

Re: an acpi menace to linux in some uefi-ed computers

Posted: Wed May 01, 2019 10:52 pm
by TJ Hoye
Stevo wrote: Wed May 01, 2019 9:52 pm How did the Package Installer fail to install the latest Liquorix kernel? That should have "just worked". Could you provide some more details?
Hello again, Stevo.

You will have to ask BitJam to get a good technical answer here.

Back in MX-14 days I was as I still am working exclusively LiveUSB. Back then, both AntiX and BitJam were working on how to do a kernel upgrade on MX-LiveUSBs.
Not knowing why I had then tried to use the MX-Tools pkg installer to do this and failed. I repeated my mistake recently with your suggestion.
I never was a party to AntiX's and/or BitJam's solution except to cheer them on. BitJam gives me underserved credit other than being just a test case
for their invention.

All I know is for a LIveUSB the pkg installer fails somewhat softly, but may somewhat corrupt the initial LiveUSB kernel's install, IIRC.
The LiveUSB Kernel Installer works just fine for LiveUSBs, but it looks for kernel material in Synaptic.

TJH

Re: an acpi menace to linux in some uefi-ed computers

Posted: Fri May 03, 2019 3:48 pm
by TJ Hoye
@ Stevo

Operating LiveUSB with Liquorix 5.0 kernel.
Much the same acpi situation as with antiX 5.0 kernel.
On ac-adaptor power, acpi functions for Battery, Adapter, and first two Thermal functions identical to antiX kernel results.
Similarly, any higher acpi functions, whatever they might be, are apparently not functional at least on ac-adapter power.

If these modules are intended only for use when on battery power, this may be reasonable, except for iwlwifi.
iwlwifi is in use, working just fine on ac-adapter power using and wlan0.

Evidence is as follows:

demo@mx1:~
$ uname -a
Linux mx1 5.0.0-11.1-liquorix-amd64 #1 ZEN SMP PREEMPT liquorix 5.0-11.1~sid (2019-05-02) x86_64 GNU/Linux

demo@mx1:~
$ acpi -Vf
Battery 0: Full, 100%
Battery 0: design capacity 3684 mAh, last full capacity 3500 mAh = 95%
Adapter 0: on-line
Thermal 0: ok, 77.0 degrees F
Thermal 0: trip point 0 switches to mode critical at temperature 224.6 degrees F
Cooling 0: Processor 0 of 3
Cooling 1: Processor 0 of 3
Cooling 2: iwlwifi no state information available
Cooling 3: Processor 0 of 3
Cooling 4: Processor 0 of 3
Cooling 5: TMEM no state information available
Cooling 6: Processor 0 of 3
Cooling 7: SEN1 no state information available
Cooling 8: Processor 0 of 3
Cooling 9: x86_pkg_temp no state information available
Cooling 10: Processor 0 of 3
Cooling 11: intel_powerclamp no state information available
Cooling 12: pch_skylake no state information available
Cooling 13: Processor 0 of 3
Cooling 14: INT3400 Thermal no state information available

demo@mx1:~
$ lsmod | grep -i "acpi\|iwlwifi\|x86\|pch_skylake\|intel_power"
x86_pkg_temp_thermal 16384 0
intel_powerclamp 16384 0
snd_soc_acpi_intel_match 28672 1 snd_soc_skl
snd_soc_acpi 16384 2 snd_soc_acpi_intel_match,snd_soc_skl
iwlwifi 253952 1 iwlmvm
cfg80211 774144 3 iwlmvm,iwlwifi,mac80211
aes_x86_64 20480 1 aesni_intel
acpi_thermal_rel 16384 1 int3400_thermal
acpi_pad 24576 0

TJH

Re: an acpi menace to linux in some uefi-ed computers

Posted: Fri May 03, 2019 4:33 pm
by Stevo
We kernel packagers really don't have much to do with ACPI. Those kernel drivers just build. The kernel developers are constantly trying to fix ACPI bugs and quirks like Dell's, but you may have to wait a while until they fix those (if ever) :frown:

Re: an acpi menace to linux in some uefi-ed computers

Posted: Mon May 06, 2019 8:50 pm
by TJ Hoye
To whom it may concern, kernel experts, take heed:

I've just been examining some features of a new computer that surprised me and slightly disappoint me.
The new computer is a Dell 5570 laptop. It has USB3 I/O and effectively eight cpus which greatly enhance
my MX-18 performance over that of a failing 1545 laptop with USB2 and a mere 2 cpu capability.
Remasters take about 2.5 minutes; kernel upgrades time is mostly the time required reboot.

The disappointment is, for me mainly theoretical, not operational. The 5570 uses uefi and acpi while
in Win 10 mode to squeeze every last second out of a battery charge, or so I imagine, not using Win 10
myself. More to the point, I don't compute on battery power. My laptop is now my only go-to desktop.
In Linux mode with all the kernels I've tried there is miserable non-support of all the assumed built-in
battery-mode finesse. What my MX-Linux gets is about 30 lines of dmesg complaining about missed opportunities.

Other Linux users may very well cherish these missed opportunities and might like to get them back.
To that end, it might be nice if some MXperts and/or antiXperts might step in and at least enable
more diagnostic material through so some Linux acpi afficienados might work on this laptop problem.

I can volunteer acpitools as one diagnostic aid brought in with MX package installer.
Using it shows perhaps few kernel parameters that might also be tweaked for more inside info.


acpitool, see for example:
https://linux.die.net/man/1/acpitool

demo@mx1:~
$ acpitool -vt
Could not open directory : /proc/acpi/thermal_zone/
function Do_Thermal_Info() : make sure your kernel has /proc/acpi/thermal_zone support enabled.

demo@mx1:~
$ acpitool -c
CPU type : Intel(R) Core(TM) i5-8250U CPU @ 1.60GHz
Min/Max frequency : 400/3400 MHz
Current frequency : 700 MHz
Frequency governor : powersave
Freq. scaling driver : intel_pstate
Cache size : 700.173 KB
Bogomips : 3600.00
Bogomips : 3600.00
Bogomips : 3600.00
Bogomips : 3600.00
Bogomips : 3600.00
Bogomips : 3600.00
Bogomips : 3600.00
Bogomips : 3600.00
Function Show_CPU_Info : could not read directory /proc/acpi/processor/
Make sure your kernel has ACPI processor support enabled.

demo@mx1:~
$ acpitool -cooling
Sorry, but no Asus ACPI extensions were found on this system.
CPU type : Intel(R) Core(TM) i5-8250U CPU @ 1.60GHz
Min/Max frequency : 400/3400 MHz
Current frequency : 700 MHz
Frequency governor : powersave
Freq. scaling driver : intel_pstate
Cache size : 700.043 KB
Bogomips : 3600.00
Bogomips : 3600.00
Bogomips : 3600.00
Bogomips : 3600.00
Bogomips : 3600.00
Bogomips : 3600.00
Bogomips : 3600.00
Bogomips : 3600.00
Function Show_CPU_Info : could not read directory /proc/acpi/processor/
Make sure your kernel has ACPI processor support enabled.

TJH