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

[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?

[(Anonymous)]

NO NO NO NO NO NO NO NO NO

The firmware should NEVER try to work around OS bugs! If there's a bug in the OS, it will be fixed, ESPECIALLY if the OS is Linux! If the firmware works around the bug, then the OS bugfix turns that firmware workaround into a firmware bug.

That's not how it works in the real world

[(Anonymous)]

FW vendors have to deal with OS bugs all the time. Let's say I'm a fW vendor and I have this super nice network card that doesn't work with RHEL or Windows or whatever, just because there's a bug in the OS. Well, Red Hat or Microsoft couldn't care less about it, it's MY problem and it's MY loss that I can't sell my shiny peripheral because the OS is broken, my company's going bankrupt and I'll loose my job. So in a world that FW vendors need to make things work, yeah, they pretty much need to implement workarounds over broken OS or broken HW (been here, done that).
And even if you say "but Linux is open-source!" and submit a patch (been there, done that) it takes quite a while from the moment you submit the patch to the moment the servers are upgraded with a newer kernel. A workaround fixes things *NOW* and makes that angry customer go away.

Re: That's not how it works in the real world

[(Anonymous)]

In what world do you control the BIOS firmware but have no ability to fix the OS? Good hardware vendors have Red Hat and SuSE on the phone and can tell them that there's a bug that needs fixing.

Also, go read the two observed instances Matthew pointed out; in both cases, the firmware randomly breaks things rather than fixing them.

It'd be lovely to see the changelogs where someone added those particular bits of insanity and what they thought they were doing.

Re: That's not how it works in the real world

[(Anonymous)]

So submit a patch to mainline and release a manual driver for people to use until it get's merged.