[RESPONDED] About acpi_osi kernel parameter

What does acpi_osi actually do? And how would it help to battery life?

I am currently on a 11th Gen Framework Laptop. Before adding acpi_osi="!Windows2020" to the kernel parameters, the best idle total power I could achieve was around 5W. After I added the kernel parameter while not changing everything else including TLP configuration, I saw a ~40% decrease in idle total power under the same condition (about 3.0W). I have auto brightness turned on, and the brightness was similar before and after the discovery.

Also, is there some acpi_osi or acpi_os_name parameter needed for 12th Gen Framework Laptop to get a good battery life?

CPU:i5-1135G7
OS: Arch Linux
Kernel Version: 6.1.10-arch1-1
BIOS: 3.17
Kernel parameters:rw quiet splash rd.luks.name=581ee789-0bd5-43f2-9246-69caae83d6af=lcroot root=/dev/mapper/lcroot rootflags=atgc resume=UUID=05af758b-605d-448a-a8d4-ddc50a1319ed resume_offset=1465344 mem_sleep_default=deep nvme.noacpi=1 rd.luks.options=tpm2-device=auto acpi_osi="!Windows2020"

Fedora 37 here, kernel 6.1.10-200.fc37.x86_64, 11 gen BIOS 3.17 as well.

The laptop is virtually always plugged into either the Framework AC adapter or a TB4 dock, so I don’t have any battery life/consumption numbers to report/compare.

However I do have acpi_osi="!Windows 2020" in the command line because without it s2idle sleep does not work. That’s completely independent of the TB dock and as far as I can tell was “always” (since I got the laptop and installed Fedora 35 on it in the Nov 2021 timeframe) needed to get s2idle to work. I’d be curious about your or others’ experience - does s2idle work for you with/without this argument?

On the semantics of that argument, if I’m reading the docs correctly it means that when Linux is asked by the BIOS whether it supports the Windows 2020 “BIOS API” it will say no.

Okay, that is weird as it should no such effect. I mean, it “can” allow stuff to function vs not function, but osi should only empower the BIOS to cooperate with specific firmware.

In years past, I’ve seen it help with VIA graphics and other odd situations where BIOS/firmware compatibility needed a push. But I cannot fathom how it would help with power.

Are you certain that Linux kernel or recently adding noacpi=1?

I tested again without the acpi kernel parameter and it does seems to have little or no effect. The result may come from different screen brightness.
By the way, at the time I bought the 11th gen framework laptop, on arch wiki there was a tip about acpi_osi kernel parameter. That tip said leaving it to blank may lead to CPU stalls and the possible preferred option was “Windows 2020”.
But now that tip is gone. Are there some issues that’s not present on 12th gen motherboards?

Interesting, but not surprising. Their wiki has a lot of great info, however, sometimes things can be mis-attributed. I’d have to test this further, however.

Here’s a quick reference from the source, Linux docs.


acpi_osi=	[HW,ACPI] Modify list of supported OS interface strings
			acpi_osi="string1"	# add string1
			acpi_osi="!string2"	# remove string2
			acpi_osi=!*		# remove all strings
			acpi_osi=!		# disable all built-in OS vendor
						  strings
			acpi_osi=!!		# enable all built-in OS vendor
						  strings
			acpi_osi=		# disable all strings