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.
MS had a large portion of the market so big players trying to launch products on a tight schedule or low budget will quickly ignore specs they don't believe will be required for the launch. In this case Windows forces a lower spec. The problem with that is you'll rarely see companies go back and address the issue until there's a fire burning under their behind.
2 might be the right default, but shouldn't we at least allow acpi_version= on the kernel cmdline for people who want to take advantage of the feature spread between 2 and 5?
Not everybody has broken Dell crap, right?
My God, it's Full of Source!
OUTSIDE_IP=$(dig +short my.ip @outsideip.net)
How about reporting yes to Linux and keeping the correct 5 as a response.
Then return all that dont deliver a working computer as broken.
Because whats the use of having those questions if everybody delivers the same answer ?
Just saying it like it are.
This isn't really at the driver level yet. It's at the bios level where the OS can configure the devices to some degrees. The ACPI (Advanced Configuration and Power Interface ) level dictates the revision to be used in allowing the kernel to change settings and the level of control. It's basically why you do not have to go into the bios and change settings to resolve IRQ or DMA conflicts or worse, crap open the case and flip jumpers anymore.
If the spec level is implemented properly, the bios will default to a non-conflicting configuration and all most drivers will need to do is query that configuration and use it. In some cases, such as workarounds for sound cards, the IRQ and DMA will need to be changed and the APCI level will dictate how and what can be changed. As stated by the article, in Dell machines the sound hardware is left in a misconfiguration state which would require the driver to explicitly use the APCI spec to make it useful to the user under linux.
But it's way more useful then that. The brightness of a monitor for instance is controlled via the ACPI interface so you don't have to set it in the bios. In the article, the author claims that HP machines report fewer brightness levels for the back light of the LCD screen.
However, the author thinks this is by design and intended to sabotage the linux installs. I'm thinking it may be more likely that they just do not put enough effort into the levels that are not commonly used and allow bugs to persist. Of course it could be a malicious firmware author who is upset over having to make this stuff for linux and sabotaging it. It's hard to tell at this point.
What's the point of following the spec if no hardware does? The goal of an operating system is to run.
I had a Toshiba laptop where none of the built-in devices like sound or network worked if you booted with ACPI on. It turned out the fix was to fool the bios into thinking it was running Windows by editing the DSDT code. The firmware on this machine actually shut off all the peripherals if it thought it was running some version of Linux.
I've always been mystified as to why Toshiba's engineers did this. And even having that capability in ACPI seems architecturally suspect. I can't see any legitimate reason for the machine's firmware to second guess what to do based on which OS is running on it.
Post may contain irony: discontinue use if experiencing mood swings, nausea or elevated blood pressure.
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.
>essentially ignoring the standard altogether.
Let me regale you my favorite version of this. It must have been 12 or 13 years ago now, I was maintaining an educational linux distribution called OpenLab (we did some awesome stuff - look it up) when one of our big customers bought a large consignment of P3 machines to use as thin-client class-room servers.
The things just wouldn't work... they would start booting the live CD and halfway through the bootup just reboot again, over and over and over.
So they sent us one to figure out what was going wrong. I spent ages trying to figure out what on earth could be causing it, eventually resorting to disabling drivers one by one until it booted up to track down the issue.
It turns out it was a watchdog card driver causing the problem. Which is odd because the machines did not HAVE watchdog cards. Now having a starting point I dug further. It turns out the cheap motherboard manufacturers had added an onboard sound card, but hadn't bothered to get a unique PCI-ID for it, they just used one from an intel watchdog card assuming nobody would install one. Running windows this would not be a major issue since nobody would load the driver for one.
On Linux though the plugnplay layer picked up the device ID and loaded the watchdog card driver thinking there is one. The driver fires up, waits for the scheduled watchdog ping - and when it didn't get one (because the card wasn't really there) after 60 seconds (Back then booting up in 90seconds got us lots of praise, below one minute was unheard of) it would reboot the machine -exactly as it's supposed to.
Never underestimate the level of stupid that hardware companies can come up with. I had to build a hotpatch version of the distribution which would disable the watchdog card driver if it detected that motherboard (which by the way is not that simple to do in very early-boot init scripts that have to run before drivers start loading).
Unicode killed the ASCII-art *