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.

Comments

Add a parameter?

[bill_mcgonigle]

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?

Re:Front page news

[sumdumass]

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.

I've been through this myself.

[hey!]

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.

Re:I've been through this myself.

[King_TJ]

Now THAT would make me apt to return the computer for a refund and buy something different.... It's one thing for Linux to support a newer level of ACPI that many popular vendors/machines don't behave well with. (I get the idea of reporting a value of 2 instead of 5 to make things work in these cases. Why not? It's a one character solution to the OS misbehaving on those systems. Just make a note as to why it's done and allow users to edit a file to change it to 5 for full ACPI functionality in cases where it will work.

But to have a computer that willfully disables hardware because it thinks you're "trying to run something other than Windows"? That's done on purpose by Toshiba, if you ask me -- and was a ploy to ensure only Windows stays on the machine. (Maybe for tech support reasons, so they don't have to worry about fielding calls from users of Linux or other OS's who they have no support database built for?) I'd prefer not to use something designed like that.

Re:There is already a solution.

[silentcoder]

>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).