Slashdot Mirror
Linux Might Need To Claim Only ACPI 2.0 Support For BIOS
jones_supa writes Some of us remember the story of why Linux kernel responds "False" when ACPI BIOS asks if the operating system is Linux. We have found yet another case where mimicking the Windows behavior instead of writing to the spec is the right choice if you just want your machine to work properly. The ACPI spec defines the _REV object as evaluating to the revision of the ACPI specification that the OS implements. Linux returns 5 for this, because Linux actually tries to implement ACPI 5.0, but Windows returns 2 (ACPI 2.0), possibly due to legacy reasons. Linux kernel expert Matthew Garrett discovered that still a fair amount of brokenness appears when 5 is returned as the revision, including a Dell machine which left the sound hardware in a misconfigured state. He is proposing a kernel patch which simply reports _REV as 2 on all x86 hardware.
It's been widely known for more than a decade now that almost all ACPI implementations from almost all manufactures are bad, if not completely broken.
Microsoft doesn't even bother humoring them. They roll their own power management code and maintain an internal database/whitelist/blacklist of machines and fixes/cludges.
The above probably leads hardware makers to be complacent. They'll jiggle their implementation enough until the machine boots windows, then they ship it.
Yes, they ship stuff that doesn't meet the standards but this is the state of the industry. Razor thin margins and high volume. They don't care about things they shipped last month, let alone years ago.
Linux will probably go the MS route, since it's been proven that leaving something so important to hardware makers is a fool's idea.
From: Bill Gates
Sent: Sunday, January 24, 1999 8:41 AM
To: Jeff Westorinen; Ben Fathi
Cc: Carl Stork (Exchange); Nathan Myhrvold; Eric Rudder
Subject: ACPI extensions
"One thing I find myself wondering about is whether we shouldn't try and make the "ACPI" extensions somehow Windows specific.
It seems unfortunate if we do this work and get our partners to do the work and the results is that Linux works great without having to do the work.
Maybe there is no way to avoid this problem but it does bother me.
Maybe we could define the APIs so that they work well with NT and not the others even if they are open.
Or maybe we could patent something related to this."
-------
A possible bug in Foxconn boards BIOS affects Linux ACPI
Foxconn Does Hate Linux Support
I propose a new rule similar to Godwin's rule about the first to mention the word "Nazi" loses the argument.
Uh, there's no such thing. Godwin's Law just says that, in any discussion that goes on long enough, someone will call another poster a Nazi.
Your supposed 'Godwin's Law' would be absurd:
'I think we should murder all the Jews'
'Hitler, you're a Naz!'
'Ha-ha! Godwin's Law! You lose!'
Hi, I'm a UEFI BIOS/Firmware engineer that is very well plugged in to the heart of the PC industry and I can tell you that the reasons behind this are not malicious at all. I am fortunate because I am one of the engineers that write code that is broadly applicable to many different motherboard designs. Me and my colleagues have reasonable release schedules similar to other software projects of similar complexity. We have the time and the dedicated QA engineers to really polish our code, eliminate bugs, and test it under a wide variety of OS and platform configurations.
Most UEFI BIOS engineers don't do the work that I do. They take the code from my group and make motherboard specific customizations. My group does all our testing and development on reference boards. The typical BIOS engineer working for a large OEM/ODM/IBV is generally given about 2 weeks to develop and test the customizations for a new motherboard design, and is generally expected to do so without any help from his/her peers. The reason for this is most large OEMs release about 50-100 new designs every 6 months, so per board development time needs to be as minimal as possible. With so many boards to support the OEM's engineering BIOS department ends up being a bunch of individuals all working on separate boards in parallel with little cross communication.
With only 2 weeks to develop and test the BIOS, pretty much the only thing that ends up getting tested is whatever version of Windows the OEM is planning on shipping with that system. So you end up with this mixed bag of well written code from me and my colleagues combined with rushed, poorly tested motherboard specific customizations. Net result is bugs like what this kernel developer noticed happen.
There are exceptions to this rule. Anything with an Apple logo, or anything that the OEM considers to be a "flagship product" that's going to get a lot of media attention is going to get a ton of development resources thrown on it. Products like the Surface, XPS 13, Yoga 3 Pro, Thinkpad T & X series, etc.
With regard to the kernel dev's observation about _REV, he is spot on. Microsoft has done a great job making it absolutely worthless. We pretty much exclusively rely on _OSI checks for certain Windows versions. Its unfortunate but MS has pretty much forced us in to doing it this way since the ACPI requirements for Win7/8/8.1/10 are vastly different and the only way to make all of them boot on the same system without blue screens (and have connected standby work) is a ton of _OSI checks.