Vendors continue to break things

[mjg59]

Getting on for seven years ago, I wrote an article on why the Linux kernel responds "False" to _OSI("Linux"). This week I discovered that vendors were making use of another behavioural difference between Linux and Windows to change the behaviour of their firmware and breaking things in the process.

The ACPI spec defines the _REV object as evaluating "to the revision of the ACPI Specification that the specified \_OS implements as a DWORD. Larger values are newer revisions of the ACPI specification", ie you reference _REV and you get back the version of the spec that the OS implements. Linux returns 5 for this, because Linux (broadly) implements ACPI 5.0, and Windows returns 2 because fuck you that's why[1].

(An aside: To be fair, Windows maybe has kind of an argument here because the spec explicitly says "The revision of the ACPI Specification that the specified \_OS implements" and all modern versions of Windows still claim to be Windows NT in \_OS and eh you can kind of make an argument that NT in the form of 2000 implemented ACPI 2.0 so handwave)

This would all be fine except firmware vendors appear to earnestly believe that they should ensure that their platforms work correctly with RHEL 5 even though there aren't any drivers for anything in their hardware and so are looking for ways to identify that they're on Linux so they can just randomly break various bits of functionality. I've now found two systems (an HP and a Dell) that check the value of _REV. The HP checks whether it's 3 or 5 and, if so, behaves like an old version of Windows and reports fewer backlight values and so on. The Dell checks whether it's 5 and, if so, leaves the sound hardware in a strange partially configured state.

And so, as a result, I've posted this patch which sets _REV to 2 on X86 systems because every single more subtle alternative leaves things in a state where vendors can just find another way to break things.

[1] Verified by hacking qemu's DSDT to make _REV calls at various points and dump the output to the debug console - I haven't found a single scenario where modern Windows returns something other than "2"

Comments

Grrrr

[(Anonymous)]

Thanks for your diagnosis (and your patch).
Makes me angry just reading it, I can just imagine how it would make you feel.

[m50d.wordpress.com]

Are there any good use cases for this kind of thing? Hardware that works around known OS bugs, say? Were we all just much more naive the spec was written?

Windows 10

[(Anonymous)]

Have you checked that Windows 10 still returns _REV of 2? Making a change like this, you should definitely future proof yourself in some sense.

[(Anonymous)]

If it's any consolation, Microsoft had all the same kind of problems trying to get Win98-era firmware to work with Windows 2000 and XP.
-John

On working with Microsoft and Linux systems at the same time

[(Anonymous)]

fart fart fart fart fart fart fart

[(Anonymous)]

Linux really needs a way to get along with firmware designers. This hard stance just makes both all sides hate each other.

Take a step back and look from their perspective. Modern laptops will need to support both Windows 8.1, Windows 7 and if the vendor supports it, Linux. Some vendors like HP and Dell both seem to be trying very hard to find an equilibrium to support all these OS's from one piece of firmware.

I2C & SMBus touchpads can't work in Windows 7. Windows 7 can't support Connected Standby. Windows 7 doesn't work with modern audio solutions. Windows 8.1 supports all of this. The only way a firmware designer can support Windows 7 and Windows 8 on the same box is with a way to differentiate OS's via _OSI. That's their first priority.

You throw Linux into the mix and what happens when the audio vendor is only willing to support their audio solution in a Windows 7 type mode? Or what if you offer connected standby (thus not offering S3) in Windows 8.1. Is it actually appropriate to claim to support everything Windows 8.1 supports when you have a a realistic scenario like that? The answer isn't every component vendor needs to support every piece of hardware in the mode the latest version of Windows operates as in Linux. Sure that's a fine sounding idea in theory. Component vendors don't work that way though.

By the time someone gets something resembling Connected Standby working in Linux there will probably be something to replace it and the laptops that support connected standby when booted in Windows 8.1 will be due for replacement too, exacerbating this problem.

It may be counter intuitive but requiring the ideal steady state scenario you dream of is likely going to cause less laptops to fully function under Linux.

xps 13 2015?

[(Anonymous)]

hey,
if you are writing about the 2015 edition of the xps 13, are you aware of these bug-reports?

https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1413446
https://bugzilla.redhat.com/show_bug.cgi?id=1188741
https://bugzilla.kernel.org/show_bug.cgi?id=93361

if you haven't seen it, there's a nice write-up about what's wrong with the device: https://major.io/2015/02/03/linux-support-dell-xps-13-9343-2015-model/

Is there a boot parameter to tweak the value?

[(Anonymous)]

First of all: thanks for your work. You're making our lives better.

Then -- I think the only way to go about this is having boot parameters. Choose sane defaults (and in this case, version 2 most probably is), but giving users easy ways to experiment and change things is (I think) always the best choice.

Of course, it'll always be possible to recompile the kernel, but why hang this hoop so high?1

How do less technical users repeat your exploration

[(Anonymous)]

If I want to find out if I have laptops/servers behaving like this what do I need to do? Is there a mechanical mostly naive way that disassembled ACPI can be inspected for things like this?

What is Drawing expecting?

[(Anonymous)]

We should check what Apple hardware and Darwin expect before changing this value or else we will break macbooks and the like.

Wrong tree

[(Anonymous)]

If the firmware is disabling and breaking things, shouldn’t the appropriate solution be to fix the firmware, instead of implementing yet another opaque workaround?

Might need to add ThinkPad t540p to the list

[(Anonymous)]

So I have been fighting a weird sound problem in the Lenovo Thinkpad t540p with newer kernels where the sound is in a weird startup state which sounded exactly like the problem descibed here

00:03.0 Audio device: Intel Corporation Xeon E3-1200 v3/4th Gen Core Processor HD Audio Controller (rev 06)
Subsystem: Lenovo Device 2210
Flags: bus master, fast devsel, latency 0, IRQ 33
Memory at e1630000 (64-bit, non-prefetchable) [size=16K]
Capabilities: [50] Power Management version 2
Capabilities: [60] MSI: Enable+ Count=1/1 Maskable- 64bit-
Capabilities: [70] Express Root Complex Integrated Endpoint, MSI 00
Kernel driver in use: snd_hda_intel

The head-phones will sometimes go into mode and the only way to fix is drop the system reboot twice and it works again until the next reboot when it goes into mode again. Of course it could just be a bad hardware :) [though going to a 3.10 level kernel didn't seem to cause it.]