Slashdot Mirror

What exactly was stupid about my post? Take it you have never heard of ACPI Source Language or the Embedded Controller?

Seriously where should you more worried about NSA exploits1) a de-compilable and OS visible byte code that controls thermal and power management or 2) An invisible micro controller firmware that converts signals from your scan matrix laptop keyboard into P/S 2 signaling?

Seriously dude, I write firmware for a living... I know a thing or two about what it does and the state of Linux's ACPI stack.

First, Microsoft doesn't "do it". Without specific drivers provided by the OEM, the power-save functionality doesn't work well on Win either. The fact that all OEMs provide these is simply a matter of scale, Windows is 90% of the market, after all.

Yes, Linux not being as power efficient as other OSes doesn't have anything to do with Linus Torvalds thinking things like ACPI are "a complete design disaster in every way."

The ACPI specification is available to anyone.

When you shopped for the computer did you take as a parameter the fact that the manufactured was openenough to provide details on how to do suspend to ram to anyone apart from MS?

It turns out that there is an industry standard for power managment on a PC originally developed by Intel known as the Advanced Configuration and Power Interface (ACPI). The vast majority of hardware vendors comply with the specification these days because they must do so to get a Windows logo. Partially as a result of Microsoft's enforcement of system power management testing to get a Windows logo, bugs in system ACPI tables are fairly rare anymore.

It also turns out that perhaps the most complicated part of entering system power states is coordinating the action amongst all the devices on the system. This requires power management handling implemented by all device drivers. It is no coincidence that "power management" is the biggest area of complaints surfaced by new Windows driver developers: correct handling of power management states is difficult to synchronize correctly and typically consumes a large portion of tricky code.

Microsoft has devoted a huge amount of time and money towards improving driver power management handling across the board. The Windows Driver Kit includes much improved documentation assisting driver developers in handling power IRPs correctly, and also includes a wide assortment of test tools designed to highlight power management bugs in real drivers and devices. Recently Microsoft acknowledged the difficulty of writing a power-aware WDM driver correctly and released a new driver framework which largely supercedes WDM to make power management easier for developers to get right. Finally, a significant portion of the Windows Logo testing kit validates that devices and drivers support power states properly. All of this work has paid off, as the OP indicated. Vista is one of the most power-aware operating systems in history, although much of the power savings are offset by extra resources consumed by other Vista features such as the Search Indexer. In any case, getting the PC industry to support device power management properly took lots of time and persistence Microsoft's part to achieve.

Frankly, the OSS community just hasn't put the same amount of work into handling power management, and the results speak for themselves. Linux is behind in power management because there aren't enough kernel-level developers knowledgeable about the subject and willing ot tackle the widespread problems in various drivers. Resuming from ACPI states S3 and S4 are very complicated operations to get right depending on what may have happened while the PC was asleep. Handling all of these edge cases in the driver code is tough, and unfortunately only an elite few know how to do it properly. Not to mention advanced bus support like USB's "selective suspend" whereby individual devices are suspended (e.g., state D2) to save power when not in use.

Advanced device support is still a major area where commercial software can still beat OSS today.

Your right, the BIOS doesn't specifically look at the hard drives and say X is installed on the computer. What it does is reports that ACPI is enabled and if the OS is able to, it can use it. When the OS attempts to use it (which all moder OS's do) it presents the BIOS with an Identification string then the BIOS reterns any specific values it has for that OS if it has used the DSDT portion of the APCI 2.0 spec. In the case of Foxxcon, it didn't return anything or returned errors because it didn't know how to handle linux. Some main boards don't even use that so it would be a default return regardless.

They did not "write some program into the bios" that checked is Linux was installed and then purposely screw it up. What they did was fail to handle linux properly on the return. They could have sent a default windows back or they could specifically write for linux but instead, they did nothing. The ACPI part of the BIOS is "an abstraction layer between the OS and platform firmware and hardware. This abstraction allows the OS and the platform to evolve independently. Not only should a new OS be able to handle old hardware, but an old OS should be able to handle new hardware." When Foxxcon decided to implement the Differentiated System Description Table (DSDT) for their boards, they didn't provide a default fall back or Linux specific information which caused the faults.

Now it is entirely possible that it was some other part that failed to return properly as the spec is quite large. But this problem wasn't the result of malice.

I've been looking at the ACPI web site. Foxconn is not among the list of "adopters". BTW, to become an ACPI adopter, you have to mail to Microsoft, as they are the secretary of the ACPI SIG.

Grep for "mutes", if you want to. Tell me, why the fuck would a machine need its serial ports (IO port range from 0x3f8, about the oldest hardware on a PC, present from before the IBM XT) disabled on Linux and not on Windows?

TFA is wrong about this. Re-read TFA. See my post here. Verify by reading the ACPI spec if you wish.

It's 3e8, not 3f8. It's the second parameter to Acquire() which is a timeout. 3e8 = 1000 = 1 second. There's nothing inherently wrong with that statement in an ASL. The fact that it crashes if you don't change it is likely an artifact of some more complex synchronization problem and subtle differences between ACPI implementations.

Furthermore, the Windows side of the ACPI code checks repeatedly that it is indeed running on Windows. And not from any information provided by the ACPI interpreter, oh no: they poke the hardware as a sort of a secret handshake. This is clearly written with intent to prevent Linux from impersonating Windows to the ACPI code.

Evidence?

All I see on the matter is an assertion posted by the original author of the thread. The only code excerpts he provides shows a match against _OS. Hardly a secret handshake. Given that he doesn't seem to understand what Acquire() does (one of the more basic ASL operators), I don't have much confidence in his knowledge of ACPI or his ability to analyze the dump.

He also adds an _OSI("Linux") section in his revised code, which will never be evaluated since Linux lies and doesn't identify itself in _OSI. Might as well just remove the whole section.

Just in case a casual reader passes by here and thinks you are not a misinformed troll.

Phoenix were not involved in the 1.0 specifications.

Microsoft were very much involved in attempting to create a windows specific specification.

You have no idea what you're talking about. If the manufacturers made PROPER DSDT tables they would work just fine with Microsoft's compiler. Microsoft tweaked their compiler to deal with all the broken DSDT tables they were getting from the manufacturers (particularly the the Taiwanese manufacturers), NOT THE OTHER WAY AROUND. That's a FACT.

This shows a complete ignorance on what a compiler does.

Compilers are supposed to throw out messages when they detect an error. Microsoft's compiler only threw out errors if it was part of the specification that Microsoft's OS needed.

Microsoft were not getting "broken DSDT tables" from manufacturers. Microsoft were shipping software that generated broken DSDT tables.

I run Linux, but one of the things I'm least happy about is the horrible support for power management. None of the sleep, hibernate, etc., options work on my machine at all.

I once had a problem with this, and decided to investigate.

So I went through the forums and found that the problem was that the manufacturer of the laptop supplies a dsdt table that does not follow the published standards for dsdt tables.

So I found a corrected table for my laptop and suspend/resume now works. But I was interested as to why a manufacturer would supply a DSDT that didnt follow the specs. And heres what I found:

1. The ACPI standard is rather complicated, almost as if it was disigned to be hard to implement. Checking to find who the major players in defining the specification, I find my fist clue: "Conceived by Intel, Microsoft and Toshiba"
2. So why would they create such a complicated specification? My next clue was that Microsoft was the developer of one of two major 3DSDT compilers.
3. It appears that the DSDT compiler Microsoft created is very forgiving of errors that other compilers (such as from Intel) would flag.
4. I don't believe it is coincidence that the parts of the ACPI specification parsed strictly by the Microsoft compiler are those needed by Microsoft operating systems.

So Microsoft create a complicated specification, probably taking care to leave out important implementation details. Then they ship a compiler for the specification that only checks parts of the specification used by their own software. And thats why Linux has issues with suspend/resume on some hardware.

Does any of this sound familiar?

I'm vociferously anti-MS; but in this case, I believe they deserve a small pardon. Go read the ACPI specifications sometime. You will cry and beg for mercy. ACPI is horrible. Considering the small number of requirements the real world has for such an interface, the specification is vast beyond imagining. Linux has also had long standing problems producing a proper ACPI layer, for this very reason: ACPI is a pig.

Now it is worth noting that MS themselves contributed to the development of this specification. The cynical side of me believes that confounding the competition by way of impenetrable specifications is simply Microsoft's modis operandi. Look at Microsoft's OpenXML specification for example: while in theory it meets the European requirement for documenting file formats and protocols, in practice it's ~6,000 pages will certainly confound all but the most determined attempts at interoperability. But here's the rub: Microsoft has to eat their own dog food, and they are suffering the consequences. Microsoft's operating system and applications are becoming so piggish that even Microsoft can't manage them.

The Advanced Configuration & Power Interface already handles power usage issues. Does anyone know if this is available in Linux yet?

My post was modded "informative" because I actually play with BIOS's.

Good for you. I've played with them too.

Because you've hand-waved away the BIOS level reporting into "ACPI does that for you"

I didn't say that, I said: "The PC BIOS most important function, [other than IPL], is to properly describe the hardware (IOW ACPI).". With emphasis on describe. And it's really funny you should pick on ACPI, because the raison d'etre of ACPI was precisely to runtime remove involvement of BIOS in hardware management, and make BIOS just hand-off the needed descriptive data at boot to the OS to allow the OS to do the runtime management, via the OS's own ACPI interpreter.

The ACPI data is to an extent a mostly static blob of data in the BIOS ROM. The BIOSes job wrt ACPI is to adjust/tweak this template at *boot* and then hand it to the OS, whose own interpreter will be doing the heavy lifting during runtime - no BIOS involed.

(such as setting boot-on-power-failure behavior, setting boot device orders, enabling serial console, hard-coding IRQ's and other stuff I do at least once a month)

Playing with the setup menu is something you consider low level stuff? And you feel qualified to tell slashdot how important the BIOS is and, more to the point, why? ;)

You're simply describing settings in the CMOS data affecting initial setup and bootstrap - irrelevant after OS is booted. You can even manipulate these settings from within your OS quite easily (if you know which bits in the CMOS do what, you can figure that out reasonably easily enough if you want.).

A lot of ACPI functionality is deduced guesswork:

ROFL. ACPI is a published, documented specification by Intel. (It's a rather huge set of specs, but it's documented none the less. The Linux ACPI interpreter is actually written and maintained by Intel staffers.). BIOS vendors often manage to screw up the ACPI data, however the beauty (relatively seen, at least, in context of PC firmware) of ACPI is you can decompile that, fix it and override it if you want. See the Linux ACPI site.

open source BIOS would remove a huge amount of the guesswork and make the code controllable and reparable.

I agree. Though, not because of ACPI (for which open source interpreters *already* exist. ACPI data is machine dependent and requires proper specs for hardware, slightly orthogonal to open source BIOS).

My post was modded "informative" because I actually play with BIOS's.

Good for you. I've played with them too.

Because you've hand-waved away the BIOS level reporting into "ACPI does that for you"

I didn't say that, I said: "The PC BIOS most important function, [other than IPL], is to properly describe the hardware (IOW ACPI).". With emphasis on describe. And it's really funny you should pick on ACPI, because the raison d'etre of ACPI was precisely to runtime remove involvement of BIOS in hardware management, and make BIOS just hand-off the needed descriptive data at boot to the OS to allow the OS to do the runtime management, via the OS's own ACPI interpreter.

The ACPI data is to an extent a mostly static blob of data in the BIOS ROM. The BIOSes job wrt ACPI is to adjust/tweak this template at *boot* and then hand it to the OS, whose own interpreter will be doing the heavy lifting during runtime - no BIOS involed.

(such as setting boot-on-power-failure behavior, setting boot device orders, enabling serial console, hard-coding IRQ's and other stuff I do at least once a month)

Playing with the setup menu is something you consider low level stuff? And you feel qualified to tell slashdot how important the BIOS is and, more to the point, why? ;)

You're simply describing settings in the CMOS data affecting initial setup and bootstrap - irrelevant after OS is booted. You can even manipulate these settings from within your OS quite easily (if you know which bits in the CMOS do what, you can figure that out reasonably easily enough if you want.).

A lot of ACPI functionality is deduced guesswork:

ROFL. ACPI is a published, documented specification by Intel. (It's a rather huge set of specs, but it's documented none the less. The Linux ACPI interpreter is actually written and maintained by Intel staffers.). BIOS vendors often manage to screw up the ACPI data, however the beauty (relatively seen, at least, in context of PC firmware) of ACPI is you can decompile that, fix it and override it if you want. See the Linux ACPI site.

open source BIOS would remove a huge amount of the guesswork and make the code controllable and reparable.

I agree. Though, not because of ACPI (for which open source interpreters *already* exist. ACPI data is machine dependent and requires proper specs for hardware, slightly orthogonal to open source BIOS).

Sony laptops use ACPI instead of APM. This makes lif very difficult for loading non MS OS's. Though there is some great work being done for linux it is still not at a usable and stable level. This may change come the 2.6 kernel but I doubt it.

Since all of us "power users" don't like those performance-detracting ACPI/APM functions, we always disable them.

Actually, it's enough to have the seti@home (or united devices/ distributed net/ whatever) client running to stop the computer from getting into standby/suspend.

It's called ACPI - gone are the times you had to press shift from time to time... :)

Learn the basics of ACPI, and some more, at acpi.info, webopedia, and Microsoft