Older blog entries for mjg59 (starting at number 150)

The Linux Plumbers Call for Papers is open for another day or so. It's looking like we'll have an excellent spread of interesting power management topics, but if you've got anything interesting to say then throw it forward. We're looking for kernel issues that have an impact on userspace, userspace issues that need kernel support and anything else that involves the interesting interactions between the two.


Hats for everyone and cab it to the Gold Club


San Francisco has been somewhat hectic, but yesterday included a quick trip to the office to discuss community involvement in improving power management. Look forward to developments there. Independently, I now join Brian the guy who had been clean too long to get onto the drugs rehab program (hurrah voicemail) in being an ex-owner of my US phone number. Probably best to delete it if you have it.

In other news, Foxconn are sending me a board with the "controversial" AMI BIOS in order to figure out what's going on. Progress by this time next week, with luck.

Syndicated 2008-07-30 22:51:29 from Matthew Garrett

FOR THE LOVE OF CHRIST T-MOBILE WHY ARE YOU TRIGGERING VOICEMAIL NOTIFICATIONS AT THE RATE OF ONE EVERY FIVE MINUTES WHEN I AM UNABLE TO EVEN ACCESS MY VOICEMAIL I AM GOING TO BURN YOU TO THE GROUND

Syndicated 2008-07-27 21:29:47 from Matthew Garrett

The Farm Cafe - baked brie with fruit sauce followed by goat cheese ravioli, accompanied by an excellent range of beers. The assault on dessert was abandoned after the realisation that emergency dessert capacity had been pressed into service as backup cheese repository.

I'd forgotten that I liked Portland.

Syndicated 2008-07-27 07:09:39 from Matthew Garrett

Further Foxconn fun

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.

Syndicated 2008-07-27 02:47:39 from Matthew Garrett

As an update to this, it turns out that I can't read and talking about _OSI isn't very helpful when the DSDT in question is calling _OS, but it does leave me somewhat more confused - Linux has claimed to be Windows NT since approximately forever. Without the original DSDT I've got absolutely no clue what's going on, but comments like:

Find and replace all seven occurences of Acquire (MUTE, 0x03E8) and replace with Acquire (MUTE, 0xFFFF), it appears they're trying to crash the kernel by locking a region of memory that shouldn't be locked, but without access to their source code comments, I can only speculate, this tells it to lock a memory address that is always reserved instead. ;)

don't give me a lot of confidence in any of this being a correct diagnosis given that the second argument to Acquire is a timeout and not an address (0x03e8 gives a timeout of a second, while 0xffff is "Block on acquiring this mutex forever").

In any case, it's highly unlikely that this is any attempt by Foxconn to prevent Linux from working. The majority of checks for Linux in ACPI tables are copy and pasted from reference tables that Intel (and other manufacturers) have provided at various points - even the Intel Macs attempt to check for Linux! Most vendors will never attempt to boot Linux on their boards or validate them appropriately, so it's entirely conceivable that they'll end up screwing things up in such a way that the only tested paths are the ones that are run by Windows. This is why we now attempt to ensure that Linux reports itself as Windows. If we're running Linux-specific code in the DSDT, then that's a bug in Linux.

Anyway. Accusing companies of conspiring against us when the most likely explanation is simply that they don't care is a fucking ridiculous thing to do and does nothing to get rid of the impression that Linux users are a bunch of whining childish hatemongers. Next time, try talking to someone who actually understands this stuff first?

Syndicated 2008-07-26 18:06:32 from Matthew Garrett

Linux hasn't claimed to be Linux in response to OSI queries since 2.6.24, so this is an interesting sidenote but basically irrelevant.

Syndicated 2008-07-25 17:26:35 from Matthew Garrett

The fallacy of the completely inclusive community

Emma Jane Hogbin gave a presentation on the gender gap in free software at Lugradio Live this weekend. One of the central messages was that a great deal of how to avoid putting women off computing can be distilled down to "Don't be a dick". This ties in well with Mako's restatement of the Ubuntu code of conduct as "Be excellent to each other" (a wonderful phrasing which demonstrates that Bill and Ted's Excellent Adventure is the most philosophically worthwhile film that Keanu Reeves has ever appeared in, and certainly not The fucking Matrix) and led to my 5 minute rant on why I hate the Linux community slightly later in the day, but does leave a certain problem. What standards are used to define whether given behaviour is dickish or not? The comments here show that there's disagreement even within a single sub-community of the larger free software world. Ben suggests that the reaction to perceived inappropriate behaviour is perhaps even more discouraging than the original behaviour, suggesting that bitching about things that offend you is dickish behaviour in and of itself. How do we decide whether someone is being a dick or helping the community? Is lack of tolerance a form of exclusionary behaviour?

This topic is actually one of the issues discussed in the Geek Social Fallacies, but here's a nice easy example. Would tolerating planet posts encouraging the eradication of the Jewish population be inclusive or exclusive? I suspect that most people would agree that it wouldn't be acceptable behaviour, which leads us to the next question. Why? There's two obvious arguments here. The first is that at a community level we have some form of rough moral consensus that advocating genocide is Just Wrong, and so criticising Nazis is obviously the right thing to do. The second argument is more pragmatic than philosophical - alienating millions of people in order to avoid alienating hate groups could be considered to reduce our potential contributor base in an unfortunate way.

I'm a fan of the second argument. The example I gave is emotive and relatively recent history has resulted in people tending to be pretty uniform in considering genocide to be a bad thing, but many other cases aren't clear cut. What I consider to be objectification of women is seen by others as appreciation of natural beauty. What I think of as sexist jokes are perceived by others as acceptable humour. When I advocate intolerance of certain behaviour, people are going to see me not having enough tolerance. So we end up in a situation where people make the "We should all just get along and be tolerant of each other" argument, which sounds fine but is fundamentally flawed in one significant way.

Advocating tolerance excludes the intolerant.

The reason people fail to see this is that it doesn't sound like a flaw. If you ask people whether we need to support intolerance, the immediate answer is probably no. But by advocating exclusion of intolerance, you're excluding all those who have good reasons to be intolerant. You're excluding the women who don't want to feel that the community sees them as a pair of breasts attached to some legs. You're excluding the ethnic groups who would prefer to avoid racist slurs or ethnic stereotyping. Telling anti-fascism protestors that they're being intolerant isn't likely to endear you to them. Advocating tolerance is telling the intolerant that they're wrong and should just deal with whatever it is that makes them unhappy.

So, ironically, tolerating certain types of intolerance is probably required in order to avoid alienating many potential contributors. That means some way of deciding what kinds of behaviour are acceptable and which are unacceptable. In the absence of either pre-existing community consensus or some philosophical breakthrough that allows unambiguous determination of the "rightness" of a given action, I'm going to suggest that we look at it from a pragmatic viewpoint. How many potential contributors do we discourage by criticising a certain type of behaviour? How many do we discourage by tolerating it?

The fallacy of the completely inclusive community is the idea that it includes everyone. The reality is that a certain level of social exclusion is required in order to include a wider range of people. So don't criticise people purely for criticising someone else's behaviour - make an argument for why that behaviour benefits the community. And when you see behaviour that you think discourages others, call people on it. Even if nobody's behaviour changes as a result, you're sending a signal that not everyone in the community agrees. Sometimes all people want is to know that there'll be some people on their side.

But, above all, try not to be a dick.

Syndicated 2008-07-21 12:35:30 from Matthew Garrett

Plans for the month:

18th-20th: Wolverhampton for Lugradio Live where I'll be doing some sort of presentation on some sort of power management stuff.
22nd-27th: Portland for OSCON and the Oregon Brewers Festival (which I guess settles any arguments about how to spell plumbers)
28th-30th: San Francisco for a meeting that's been moved to the week before I'm there
31st-4th: Boston in order to meet some of the people that I actually work with

Things not planned for the month:

Genocide
Puritanism
upskirt photos
Telling women who fail to cover their legs that they're asking for it

Syndicated 2008-07-15 01:15:57 from Matthew Garrett

My trip to Istanbul by Matthew Garrett aged 28 and 4/365ths

Saturday

Arrive at Heathrow. Richard gets to be my special lounge buddy - we later discover Bastien sitting outside looking like a lost puppy. Flight is delayed by a mere hour, so we get to the hotel with little trouble and check in. Dinner with Luis and co on pillows on the street. This becomes a recurring theme. Drinking is involved. This also becomes a recurring theme. People complain about my shortcut finding skills.

Sunday

See beautiful things. Thankful to finally get to see buildings older than my old college. Dinner under some bridge with Red Hat folks where we discover the joys of the "special price". People once more complain about my shortcut finding skills. Suspect pillows are involved, but hazy recollections.

Monday

Arrive at the university by taxi. More to the point, arrive at the university by taxi without taking a 30km detour. Dinner with Canonical people, then a party in some overpriced bar on the top of a very big hill. Discover that taxi drivers in Istanbul either have no fucking clue where anything in the entire world is, or that driving tourists to bizarre locations is a national pastime. Avoid this fate and arrive home at something like 4AM.

Tuesday

Corporate whoring continues with dinner with Collabora people (delayed by two and a half hours because Christian values getting sweaty with other men over eating, or something), followed by more drinks on the pillows. Am vindicated when it turns out that my route back to the hotel would in fact be the shortest possible route back if people didn't keep insisting on making random left turns when we're almost there.

Wednesday

Fascinating (and increasingly drunken) discussion of the neurobiological aspects of colour spaces with Pippin precedes drinks on the roof of the university. Narrowly prevent Luis' attempt to leave the foundation open to flagrant copyright violation suits. More pillows.

Thursday

Wake up with a twisted ankle and a broken laptop. I had a good birthday, it seems. Collabora host a party on a boat. Miraculously, nobody falls off the boat. We head back to the pillows while others trudge up the hill to Taksim. Aaron wins the inaugural Aaron Bockover award for services to the GNOME community.

Friday

Dinner with Novell, demonstrating my even-handedness when it comes to accepting corporate favours. Miguel reveals his true nature as a Microsoft shill by admitting to owning an XBox. I advise him to raise his free software credentials by getting a Freerunner - as a bonus it'll crash whenever anyone tries to call him, preventing Microsoft from whispering more sweet nothings in his ear. A foolproof plan. Party paid for by Google. Ear bleedingly loud. Some drinking involved. Return to bizarro deviant pillows where we are treated to the spectacle of child labour. Spend some time wondering why Planet Fedora is discussing upskirt photos and decide that hating the entire human race is probably the best option.

Saturday

Turns out that while the Grand Bazaar is effectively just a shopping centre, it's a fucking giant shopping centre that sells nothing I can find any excuse to want. Wander over to Asia for dinner. Conversation with Lennart about using cgroups as a mechanism for providing application latency requirements and how the current lack of standardisation of mountpoints and exposure of irritating implementation details makes it almost impossible to use them for anything. Fascinating diversion into how to deal with getting a SIGBUS when your mmap()ed soundcard gets hotswapped, including deciding that the easiest way of getting a reliable indication of your current process maps is by, erm, parsing /proc/self/maps. Final pillows trip. Emotional farewells (by which I mean more drinking)

Sunday

Airport. Plane. Train. Home. Transfer hard drive into laptop with working screen. Discover that productivity not actually enhanced by having more than a 300x200 pixel area of functionality. Decide to write libelous article about previous week instead.

Syndicated 2008-07-13 23:06:46 from Matthew Garrett

141 older 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!