Ryan kindly sent me a copy of the ACPI tables for his motherboard, so I've had the opportunity to look at them in a little more detail. There's nothing especially surprising. The first method of interest is OSFL, which I've annotated below:
Method (OSFL, 0, NotSerialized)
If (LNotEqual (OSVR, Ones))
Return (OSVR)
This block simply skips the checks if they've already been evaluated and returns the cached value
If (LEqual (PICM, Zero))
Store (0xAC, DBG8)
If the programmable interrupt controller has been set up in PIC mode rather than APIC mode, 0xAC is written to i/o port 0x80. This would then show up on a plug-in card if one were attached. Simply debug code
Store (One, OSVR)
Set OSVR to 1, which in this case clearly means "Unknown OS"
If (CondRefOf (_OSI, Local1))
This checks whether the OS supports the _OSI method. If it does, the following block is executed. If not, the older _OS method is used to detect the OS
If (_OSI ("Windows 2000"))
Store (0x04, OSVR)
Newer versions of Windows will also claim to support the interfaces defined in older versions, so this set of checks is done in release order
If (_OSI ("Windows 2001"))
Store (Zero, OSVR)
If (_OSI ("Windows 2001 SP1"))
Store (Zero, OSVR)
If (_OSI ("Windows 2001 SP2"))
Store (Zero, OSVR)
If (_OSI ("Windows 2001.1"))
Store (Zero, OSVR)
If (_OSI ("Windows 2001.1 SP1"))
Store (Zero, OSVR)
If (_OSI ("Windows 2006"))
Store (Zero, OSVR)
If we've got this far, OSVR is now set to 0. Linux will claim to support all of these interfaces, and so OSVR should be 0 on Linux systems. Note that there is no _OSI check for Linux - the 2.6.24 change to remove Linux from the set of claimed interfaces is therefore irrelevant
Else
Linux supports _OSI, so we should never be here. But if we somehow are...
If (MCTH (_OS, "Microsoft Windows NT"))
Store (0x04, OSVR)
Linux has responded to _OS with "Microsoft Windows NT" since 2.6.9. MCTH is simply a string matching routine defined elsewhere in the DSDT. So, worst case here is that OSVR is 4
Else
If (MCTH (_OS, "Microsoft WindowsME: Millennium Edition"))
Store (0x02, OSVR)
If (MCTH (_OS, "Linux"))
Store (0x03, OSVR)
..because this could never be true unless you're running 2.6.8.1 or earlier. But even so, getting here would still indicate failure - we've supported _OSI since before then, and so should never come anywhere near this code block.
Return (OSVR)
In summary, we end up with the following values:
| Value | OS |
| 0 | Windows XP, 2003 or Vista. Linux (assuming absence of bugs) |
| 1 | Unknown OS |
| 2 | Windows ME |
| 3 | A version of Linux that doesn't implement _OSI and is from before 2.6.9 |
| 4 | Windows NT 4 and 2000. A version of Linux that doesn't implement _OSI and is 2.6.9 or later (I don't believe any such version exists |
Now, where is this used? The majority of the OSFL checks only check whether the return value is 1 or 2, which will only be true for an OS that (a) doesn't claim to be Windows or (b) is Windows ME. Linux doesn't fall into either of these categories, so we can ignore them. The first interesting hit we have is in the HPET code, where _STA will return 0xf (device present and working) if OSFL is 0 and 0xb (device present and working, but should not be shown in the UI) otherwise. This is just to keep the HPET from showing up in versions of Windows that don't know what it is. The only other interesting hit is the following code from the PCI bus initialisation pathway:
If (LEqual (OSFL (), Zero))
Store (0x59, SMIC)
Else
If (LEqual (OSFL (), 0x04))
Store (0x5A, SMIC)
Else
Store (0x58, SMIC)
This writes different values to SMIC (which turns out to be i/o port 0xb2) depending on the OS. 0xb2 is the standard(ish) way to trigger a system management interrupt, which causes the CPU to execute some code from a memory region that can't be accessed by the OS. This isn't that unusual, but it's a little weird. In any case, note that there's no check for whether OSFL is 3 here (which would be true if the _OS call returned Linux), and so Linux is being treated identically to Windows ME and any unknown OS. In reality, Linux will be treated identically to either Vista or 2000. This block provides no evidence of conspiracy. Finally, the OS version flag is written to a region of memory before suspend and read back afterwards. Nothing appears to be done with this information - it's conceivable that the low-level resume code in the BIOS has conditionals based on this, but I suspect that it's just boilerplate code that's ignored.
To summarise:
- There is no code in this DSDT that could determine that the system is running any Linux kernel of 2.6.9 or later. This may even be true of earlier versions - I'm not sure when _OSI support was added
- Even if the code did manage to determine that the system was running Linux, there are no codepaths that are Linux specific. Every piece of code is run on at least one version of Windows
What's the problem, then? I've no idea. The only "significant" issue is that the OEMB table provided by the BIOS has an incorrect checksum. Given that the OEMB table is
never used by Linux (it's a vendor extension of some kind, with the best hint I've been able to find being that it can be used to pass information from the BIOS to the OS - kind of like the rest of ACPI, then...), this is pretty unimportant. And given that the OEMB table isn't part of the ACPI spec, it's certainly entirely irrelevant when it comes to determining whether the system is ACPI compliant or not.
Are there ACPI issues with Ryan's system? It sounds like it. The "Error attaching device data" complaints indicate some kind of failure on the part of the kernel to work out how the devices correspond to the ACPI namespace, but I strongly suspect that this is a Linux bug. Failure to reboot after suspend? Could be anything (I'd need direct access to the hardware to figure it out properly), but again it's almost certainly a Linux bug. The standard way Linux reboots systems is to bang the keyboard controller, and it's conceivable that something we're doing on resume is leaving the keyboard controller in a slightly confused state. We're clearly doing
something wrong there, given that my Dell comes up without a keyboard about one resume in twenty - I just haven't had time to look into it yet.
The only remaining thing is the mutex handwaving. I've got no clue what's going on there. Ryan's suggested change (from Acquire (MUTE, 0x03E8) to Acquire (MUTE, 0xFFFF)) simply means that the OS will wait forever until it acquires the mutex - in the past it would only wait a second. The reason the compiler generates a warning here is that the firmware never checks whether it acquired the mutex or not! Bumping the timeout to infinity obviously fixes this warning (there's no need to check the return code if you're happy to wait forever rather than failing), but the original code is merely stupid as opposed to a spec violation.
Take home messages? There's no evidence whatsoever that the BIOS is deliberately targeting Linux. There's also no obvious spec violations, but some further investigation would be required to determine for sure whether the runtime errors are due to a Linux bug or a firmware bug. Ryan's modifications should result in precisely no reasonable functional change to the firmware (if it's ever hitting the mutex timeout, something has already gone horribly wrong), and if they do then it's because Linux isn't working as it's intended to. I can't find any way in which the code Foxconn are shipping is worse than any other typical vendor. This entire controversy is entirely unjustified.
On the 
Today, I uploaded a new version of my firewall configuration tool,
I recently bought a new MSI laptop and I am really pleased with my choice so far.
After upgrading to 2.6.26 I could not associate with my AP anymore. After searching I noticed that the amount of channels reported by iwlist wlan0 channel had changed. And the channel that my AP was using (13) just disappeared. 
Running the Galician debconf template translation as an one-man show has an obvious problem: translations don’t get reviewed. Being only one, I would only catch typos, and the odd thinko, which is not very useful. The real use of reviews is to see if the grammar is sound, see if the translation sounds natural or forced, etc., and it has to be someone else who does it. If I review my own translations, of course they’ll be perfect.
When someone else picks those translations up after I stop doing them, it would be useful to make a full review. Fortunately, I’ve been keeping a compendium of (almost) all debconf template translations, so doing the review is as simple as downloading that single file and reading it.
I’d recommend that one single person read the full document and makes notes of grammatical/orthographic mistakes, common patterns, vocabulary choices, etc., and then those notes should be used to go through the compendium again and fix and update everything. The result would be useful for two things:
First, it is a very big collection of examples you can point people to when they don’t know what style to use to translate. So, when someone asks in the mailing list about the best way to translate Couldn’t create temporary file , you can search for similar sentences, see how they were translated and suggest the same solution.
Second, you can use that compendium to apply the results of the review to all translated packages very quickly. The idea is to regenerate the .PO file from the compendium. You can do it actively (see what packages have had their debconf templates translated into Galician, download .POT files, apply compendium, upload .PO files) or reactively (when you have to update a .PO file, download the .POT instead and apply the compendium, then update the resulting .PO file).
I am following closely this 
I've made a new release of my 
Regular readers may remember that 
Another point release for Etch has been done; now it's the time for the CD
team to roll out new images after the next mirror pulse. The official
announcements (prepared by Alexander Reichle-Schmehl, thanks!) will follow
shortly afterwards. FTP master of the day was Joerg Jaspert, who
did his first point release since Woody, as he told us on IRC. We
appreciate your work and you spending your time that shortly before
going to Argentina.
This point release includes the etchnhalf update introducing a new kernel
image (based on 2.6.24) and some driver updates. Additionally the
infamous openssl hole will be fixed for good, even for new installs.
Again I want to present you a list of people who contributed to this
release. It cannot be complete as I got the information out of the