[ Home | Articles | Account | People | Projects | FAQ ] Not being from Oakland, Meth has a relatively small impact on my life. Until I get a cold, at which point I get to curse the lack of effective drugs. What's surprising is how phenylephrine does have a noticable effect. What's even more surprising is that it has this effect about thirty seconds after I've swallowed the capsules, indicating fairly strongly that it hasn't actually hit my bloodstream in any sensible way at that point (though I've had astonishing difficulty in finding figures on how long the plastic capsules take to dissolve in the stomach). So, even though I know it's got no measurable effect beyond that of a placebo, the placebo effect still works. Damn you, psychology.
HELLO I'M ON THE TRAIN
and, by the looks of it, may be for some time:
Yes, the track is underwater. Sigh.
Power management and graphics
It's the X Development Summit in Edinburgh this week, so I've been hanging out with the graphics crowd. There hasn't been a huge amount of work done in the field of power management in graphics so far - Intel have framebuffer compression and there's the lvds reclocking patch I wrote (I've cleaned this up somewhat since then, but it probably wants some refactoring to avoid increasing CPU usage based on its use of damage for update notifications). That still leaves us with some fun things to look at, though.
The most obvious issue is the gpu clock. Intel's chipset implements clock gating, where unused sections of chip automatically unclock themselves. This is pleasingly transparent to the OS, and we get power savings without any complexity we have to care about. However, there's no way to control the core clock of the GPU - it's part of the northbridge and fiddling with the clocking of that would be likely to upset things. Nvidia and Radeon hardware is more interesting in this respect, since we can control the gpu clock independently of anything else. The problem is trying to do so in a reasonable way.
In an ideal universe, we can change these clock frequencies quickly and without any visual artifacts. That way it's possible to leave it in the lowest state and clock it up as load develops. There's a couple of problems with this - non ideal hardware, and the software in the first place. Jerome's been testing a little on Radeon and discovered that changing the memory clock through Atom results in visual corruption. It's conceivable that this is due to some memory transaction cycles getting corrupted as the clock gets changed. If we could ensure that the reclock happens during the vertical blank interval, that's something that could potentially be avoided (of course, then we have the entertainment of working out when the vertical blank interval actually is when you have a dual head output...). The other problem is that 3D software tends to consume as many resources as are available. Games will produce as many frames per second as possible. Demand-based clocking will simply ramp the gpu to full speed in that situation, which isn't necessarily what you want in the battery case (as the number of frames per second goes up, so does the cpu usage - even more power draw) but is probably pretty reasonable in the powered case.
Handwavy testing suggests that this can save a pretty significant amount of power, so it's something that I'm planning on working on. Further optimisations include things like making sure that we're not running any PLLs that aren't being used at the time (oscillators chew power), not powering up output ports when you're not outputting to them and enabling any hardware-level features that we're currently ignoring. And, ideally, doing all of this without causing the machine to hang on a regular basis.
Jesus fuck, Dell, why do you have a WMI event interface that seems to do nothing but pass back things that look awfully like keyboard scancodes? I mean, E045? Come on, now.
Driver forthcoming for those who really want the little battery button on their Precision M6300s to work.
What amuses me about complaints about censorship is that they often seem to be associated with, uhm, censorship. Compare and contrast:
Bored now.
Things I have learned in the past 24 hours
Testing 2.6.27-rc2 with the current released (not development) BIOS on the Foxconn G33M reveals the following:
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)
}
Else
{
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.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!