1 Aug 2008 mjg59   » (Master)

Coincidentally, I had the opportunity to poke at a machine that actually does deliberately treat Linux differently in its ACPI tables today. Jeremy was poking at an Acer Aspire One before installing Fedora on it, and Dave noticed that it printing a bootup message indicating that the firmware was testing for _OSI("Linux"). A bit of poking later, and we have the following:

            If (_OSI ("Linux"))
                Store (0x03E8, OSYS)
                Store (0x0A, \_SB.PCI0.LPC.S4TM)
                Store (0x43, \_SB.PCI0.EXP2.PXS2.LSMP)
                Store (One, \_SB.PCI0.EXP2.LL0S)
                Store (One, \_SB.PCI0.EXP2.LLL1)
                If (_OSI ("Windows 2006"))
                    Store (0x07D6, OSYS)
                    Store (0x06, \_SB.PCI0.LPC.S4TM)
                    Store (Zero, \_SB.PCI0.EXP2.PXS2.LSMP)
                    Store (Zero, \_SB.PCI0.EXP2.LL0S)
                    Store (Zero, \_SB.PCI0.EXP2.LLL1)
Other OSes get the same values as Linux, other than the OSYS field. Now, what do these writes do? They're all to PCI config space, so since the machine in question is a 945/ICH7 machine we have publically available docs. A bit of digging later and it shows that the firmware is disabling PCIE active state link control and programming more conservative timings for entry into the C4 processor idle power saving state. In other words, certain bits of power management functionality are compromised if it detects that it's running anything other than Vista. Weirdly, it also flags the HPET as present but invisible on Linux, but I suspect that's an oversight rather than anything deliberate.

Why would they do this? I've no idea. I suspect it's something to do with the degree of platform validation performed rather than a subtle attempt to degrade Linux's battery life on the hardware (frankly, we do a good enough job of that ourselves right now), but this is exactly the kind of reason we removed _OSI("Linux") support from the kernel. Vendors will do stupid things with it.

Syndicated 2008-08-01 18:47:15 from Matthew Garrett

Latest blog entries     Older blog entries

New Advogato Features

New HTML Parser: The long-awaited libxml2 based HTML parser code is live. It needs further work but already handles most markup better than the original parser.

Keep up with the latest Advogato features by reading the Advogato status blog.

If you're a C programmer with some spare time, take a look at the mod_virgule project page and help us with one of the tasks on the ToDo list!