Free as in speech

Put down the crack pipe. Really. Wow.

Matthew: Thanks for the followup and the summary of the MacBook status wrt power consumption.

I’m running a 2.6.22 kernel with the hrt patchset and a set of patches including your patch to appletouch. Your patch works great and the trackpad’s behaviour is a bit better with it.

I know pretty well what the problems are on my machine, but your summary will probably be useful to a lot of people. I know some of the issues can be fixed or worked around and others cannot.

Also note that I can get something like 3h45 out of my battery under OS X with my standard workload, which is pretty good. If OS X can do that, there’s no reason Linux can’t, however bad Apple’s choices are wrt hardware.

And to make it clear once again, my previous post didn’t criticize the C-states or anything else, but the fact that I see PowerTOP being used more as a blame shifting tool than as a debugging/profiling tool. Though I maintain that UHCI suffers from a bad design, OHCI is a much, much better spec.

A couple of weeks ago, Intel has released the PowerTOP utility for Linux, a tool similar to the well known top(1) utility that can help you understand why your laptop battery runtime is as low as 1 hour. You need a tickless kernel (2.6.21 at least on i386, 2.6.22 + hrt patchset on amd64) for that to work, and timer statistics must be enabled.

This is an extremely bright marketing coup from Intel, for essentially two reasons:

• with PowerTOP, they’re now telling “hey look, the CPU is in C3 xx,x% of the time, it’s saving power!!!” and have some real hard data to back that up;
• with PowerTOP, they can also tell “hey look, the CPU cannot reach the C3 state for long enough periods because foobar is waking it up too often! That’s not the CPU’s fault!”, again with some real hard data to back that up.

In that, PowerTOP is an incredible PR spinning tool that can shift the blame away from the Intel CPU in your machine to about everything else in your machine - including software!

They’ve done extensive and intensive internal testing, which turned up some bugs and misbehaviours here and there, which is truly great.

They’re also announcing incredibly low “CPU wakeups per second” values, so low that there is no way you can reach such low values on any kind of real world setup. These numbers must be seen in the context of lab testing on otherwise idle machines.

On the “CPU wakeups per second” front, you’ll most probably see that the #1 offender is your UHCI USB controller. A UHCI USB controller produces a thousand interrupts per second, effectively waking up the CPU a thousand times per second even when nothing happens.

So, now it’s all the USB controller’s fault! Ah, wait, UHCI is an Intel spec! (UHCI is a joint effort by Intel and others, Intel being the lead) Fortunately, to be able to put the USB host controller to sleep, you need to put all the USB devices attached to it to sleep too. Here comes the (in)famous CONFIG_USB_SUSPEND kernel option introduced six or so months ago, the one that makes (made, I’ve worked around it in SANE last week-end) your scanner produce only “black scans” and prevents your printer from working properly. So now it’s all the USB devices’ fault.

Brilliant, isn’t it ?

To be honest and complete, once again, CONFIG_USB_SUSPEND exposed a lot of hardware bugs. The USB spec is probably one of the most violated spec these days (together with ACPI I’d say, though it looks like this one is improving lately).

Please don’t get me wrong: PowerTOP is a very useful tool that has its uses, the tickless kernel is of course a very important feature, and CONFIG_USB_SUSPEND would be the icing on the cake if USB devices weren’t so ignorant of the spec.

But the Intel marketing crap behind that really needs to stop. Produce better chips which consume less power, period. My PowerBook G4 could run 4h30 on battery (a machine designed 7 years ago). My Core2 Duo MacBook Pro, with a slightly bigger battery, can only run 1h40 with the same software and workload, with cpufreq enabled etc, etc. Granted, the ATI video card is a big sucker here too.

(I wrote this entry to share my thoughts on the matter, as a reaction to the many mails I’m getting about PowerTOP and the MacBooks, so as to have a reference to point people to, instead of rewriting the same things again and again.)

Quoting from the Release Notes for the firmware v1.54.2 for the Thomson ST2030 VoIP telephone, in the “Relevant known limitations” section:

3.1 The display doesn’t show the name of the incoming call when received display name starts with the letter “O” (uppercase).

This raised quite a few eyebrows here, and raised quite a few concerns too. I refuse to even imagine how this kind of bug can happen.

And for those who will have a hard time believing this, we did the test, and, indeed, the CallerID name doesn’t appear on the phone when it starts with an “O”. Shrug.

The server hosting this blog just suffered what can only be described as catastrophic hardware failure, thanks to the crap that are Maxtor hard drives, Dell CERC 1.5 RAID controllers and the Linux driver for those (aacraid).

So, the machine got shut down for a moment on thursday night, just the time to move the rack around in the datacenter, and one of the disks did not come back in one piece.

But it did come back online after a reboot, prompting an array rebuild by the controller which took 12.5 hours for 250 GB (RAID 1). And the drive failed again 10 minutes after the rebuild was completed, confusing both the controller and the driver. At that point I could still log into the machine, but any command would trigger nice I/O errors all over the place.

Fortunately, the FS got shut down by XFS automatically on I/O errors and I haven’t lost a single bit of data. The machine came back just fine with the faulty drive removed.

And you thought a RAID controller would help in this case. Obviously this one doesn’t. I need to mention that we’ve observed this behaviour on another machine before this incident, we have another machine suffering from a faulty drive in just the same way, so this isn’t an isolated case and it’s reproducible.

So, here it is, the hard drive in my mother’s laptop (HP nx9105, 10 months old) just broke down this week, with some important data on it (I do have backups, but it broke down in between 2 backups with some important changes to the data - accounting and payroll).

The laptop was running an AMD64 Sarge on an XFS filesystem. Fortunately, XFS shuts the filesystem down when the underlying block device fails, so the damages are quite limited. dd_rescue to the rescue, only 40 kB of the 40 GB partition couldn’t be recovered. An xfs_repair run later, the FS mounts with only 30 files in lost+found: 10 of them are device nodes, 10 are empty files, another 5 are sockets and the remaining 5 are mails from anacron.

I just love this filesystem. SGI, you guys rock. All of this just went as planned when I installed the machine in July last year; I chose XFS for its ability to not screw up the FS when the underlying block device crashes and for the powerful and reliable set of maintenance tools that goes with it.

Well, first off, thanks Lars Wirzenius (liw) for this really fine piece of software, it saved me from the mailman hell I was going to enter.

That being said, here’s the setup, with Postfix 2.0 and virtual domains on a Sarge system; the manpage of eoc is slightly outdated wrt to Postfix it seems, so I hope this will be helpful (with apologies to Planet readers for the length of this entry):

• Create an eoc or whatever user, who will receive the mails and hold the eoc configuration. I created a system user, with a disabled password and /bin/bash as its shell, member of the list group.
• su - eoc and create your mailing list, with something like
  
enemies-of-carlotta --name=testlist@lists.example.com --owner=foo@example.com --create

  Now, add yourself to the testlist:
  
enemies-of-carlotta --name=testlist@lists.example.com --subscribe your@email.address

  As eoc places its configuration data in ~/.enemies-of-carlotta, it’s important to run the enemies-of-carlotta command as the eoc user.
• Edit /etc/postfix/main.cf, and add the file /etc/postfix/virtual_eoc_aliases to the virtual_alias_map configuration item, e.g.
  
...
virtual_alias_maps = hash:/etc/postfix/virtual_aliases, pcre:/etc/postfix/virtual_eoc_aliases
...


  Now, create /etc/postfix/virtual_eoc_aliases:
  
#
# virtual aliases for EOC (mailing-lists)
#
 
/^(testlist|testlist-.*)@(lists.example.com)$/ eoc+lists.example.com_$1


  This way, a mail addressed to (testlist|testlist-.*)@lists.example.com will be redirected to eoc+lists.example.com_<whatgotmatched>.

  You’ll need the postfix-pcre package for this to work, and the recipient delimiter must be set to + (recipient_delimiter = + in /etc/postfix/main.cf). Restart postfix.

• Send a mail to your test list, it should end up in the mailbox of your eoc user. If it doesn’t, check the postfix logs and fix the problem ;-)
• Create the .forward file in the user’s homedir, here’s its content
  
"| procmail -p"

• Now, create the .procmailrc file for the eoc user. This is what I came up with:
  
PATH=$HOME/bin:/bin:/usr/bin
LOGFILE=$HOME/eoc-log
ARCHIVES=$HOME/archives
THISMONTH=`date "+%Y%m"`
 
# determine the full list name (list@domain)
:0
EOCLIST=| eoc-extract-list $EXTENSION
 
# set recipient to the full list name, ie list@domain
RECIPIENT=$EOCLIST
 
# feed the mail to EOC
:0
* ? enemies-of-carlotta --name=$EOCLIST --is-list
{
# send the mail to the list
:0 c
| enemies-of-carlotta --quiet --incoming
 
# archive it
UMASK=033
:0
$ARCHIVES/$EOCLIST/${THISMONTH}.mbox
}
 
# trap other mails ...
:0
trapped-mails


  The eoc-extract-list does nothing more than that, at the moment:
  
echo $1 | sed -e 's/\([^_]*\)[_]\(.*\)/\2@\1/’

  The trapped-mails mbox file will need to be emptied periodically; actually, I redirect those mails to another address, feel free to pass them on to Dave Null.
  As you can see, the mails get archived in an mbox by the procmail rule. I use mhonarc to generate a web archive from this mbox.

OK, here you are, your test mailing-list should now be functional. Send a mail, and see what happens.

To add a list, all you have to do is:

• Add the regexp into /etc/postfix/virtual_eoc_aliases
• Create the list in eoc

The procmailrc doesn’t need to be modified afterwards. It can probably be improved still, but I’m happy with it as it is now.

Now, if someone knows of a mailing-list archiver that doesn’t suck, I’d be glad to give it a try.

So, here we are, the European Parliament finally rejected the Software Patents. At last.

With 648 votes against the proposal out of 680 total votes, it’s quite a strong signal towards the European Commission. Hope they’ll learn something from that event.

Thanks to all the folks who worked for that day to happen, especially the FFII and Michel Rocard.

Now, let’s get back to Free Software. We’ve got a C++ transition to do.

I upgraded my gateway from Woody to Sarge right after the release, and all went fine on the Debian side. Switching to the 2.6 kernel, while I was at it, has been a bit painful as Linux 2.6 decided it wouldn’t order its network interfaces the same way Linux 2.4 did. I admit that I forgot about that before doing the upgrade.

This week-end, I finally found the time to upgrade my server, and this was a much feared upgrade, as I expected it would take me a whole day to be done with it. It all went rather fine, and I did the whole upgrade in half a day only.

The problems I anticipated were:

• Switching from Netsaint to Nagios: went fine, as I prepared the Nagios config on a test machine before the upgrade.
• INN: it just can’t survive an upgrade. Only a couple of minor fixes to inn.conf were needed to get it back up and running — good surprise.
• NUT: new major version, although I was running a backported version of NUT and no configuration changes were required. But nut-cgi failed to upgrade properly, I had to purge and reinstall it.
• Postfix/Courier-imap: this is my MX, so, if something goes wrong here, my mail doesn’t arrive anymore. And I absolutely HATE losing mail.

Once everything was back up and running, I switched from Apache to Apache2, then switched to Linux 2.6. The server is much faster now (even with Linux 2.4); especially, deleting mail from my IMAP folders now takes less than a second, where it could take as much as 20 seconds before. Happy I am.

In the end, Debian is still Debian, the upgrades are still painless compared to other distributions, and I love that. Now, if only services could get restarted faster during the upgrade, I’d be even more happy. For now, it’ll do ;-)

When I wrote the previous blog entry, I had a quick look at ebay, and didn’t find an offer that would suit my needs and price range.

A few days later, Eric Poehlman sent me a couple of ebay links in a kind email, and there I found what I was looking for: a C4137A-compatible part for 25 Euros, and it’s not even a used one. It got shipped by the seller the same day; I must say that I wasn’t too confident with buying on ebay, but it all went really well.

So my printer is now happy to print big images with its 18 MB of RAM. It’s faster for text too, it doesn’t pause for soooooooo long between pages anymore.

Thanks, Eric!