Archive for July, 2006

After quite some work on packaging it, Firefox 2.0b1 is finally being uploaded to experimental.

It is linked to the system libmyspell instead of the bundled one, and can use system dictionaries like Thunderbird already does. I'm also working on using the system libsqlite3, but it first requires some build changes in the debian sqlite3 package and some more work to see if it's really feasible... you see, they like to take external libraries and modify them so much as adding symbols, changing some internals... and these changes only exist in the mozilla codebase... (the 2 main examples of that being expat and sqlite3)

It also includes a working DOM Inspector which upstream didn't include in their release because they are in the process of moving the component in the core.

I also had to fix some more the build system so that some things would be installed by make install (they tend to forget it), others would just be installed (mistakenly removed rules...) or make clean would do its work: cleaning (they tend to forget to flag files for removal when they create it in a Makefile). All that makes me wonder what their review/super-review thing is worth.

Anyways, please give it a try, especially if you reported a bug on earlier versions, it would be helpful if you closed bugs that are fixed by this release (don't forget the 'Version:' in the closing message so that the BTS version tracking would do its work).

Update: Upstream Firefox 2.0b1 has a working DOM Inspector. It only appears it just doesn't build correctly the way we build Firefox... might be some missing changes to the Makefiles. Again. *sigh*

Update 2: It was trickier: missing something to make the inspector symbols public instead of having a hidden visibility...

Update 3: It was actually my fault. /me goes hiding under a rock. And I managed to remove a comment to this post when removing spam... *sigh*. I think I need to take a break.

Then, help spread Firefox and get creditted in Firefox 2. Now, what I think is really amazing is how much effort they spend to credit those helping to spread Firefox, but not those helping to fix it.
Don't get me wrong, I don't care about being creditted myself for the several patches I sent and more, but I'm pretty sure a lot of people who sent patches like me are not creditted either.
It's already a PITA to get patches applied (some patches are still waiting to be reviewed or applied)...

Update: At least, they credit in the CVS logs.

I'm a specialist when it comes to delete files I didn't intend to. 3 years ago, I did an rm -rf that cost me most of my ${HOME}, and I wrote some software (which i really should work on, BTW) which helped recover most of it (it's tricky to get files back from ext3 once they are removed from the filesystem, since ext3 clears the block pointers from the inodes then).

Today, I somehow managed to remove log files. Fortunately the log files were still in use by a process, so they were still in the filesystem. Unfortunately they were still in use by a process, filling and filling and filling... and in no way i wanted to lose all this data.

Let's consider, for the needs of the demonstration, the following case:
mh@namakemono:/mnt/test$ while true; do date; sleep 1; done > log

That fills a 'log' file every second with the current date.
mh@namakemono:/mnt/test$ tail -2 log
2006年 7月 4日 火曜日 20:48:02 CEST
2006年 7月 4日 火曜日 20:48:03 CEST

The file keeps growing and growing. Now, let's remove it.
mh@namakemono:/mnt/test$ rm log

The file is not in the directory any more, but remains in the filesystem. It is actually readable through /proc:
mh@namakemono:/mnt/test$ ls -l /proc/10724/fd
合計 5
lrwx------ 1 mh users 64 2006-07-04 20:52 0 -> /dev/pts/1
l-wx------ 1 mh users 64 2006-07-04 20:52 1 -> /mnt/test/log (deleted)
lrwx------ 1 mh users 64 2006-07-04 20:52 10 -> /dev/pts/1
lrwx------ 1 mh users 64 2006-07-04 20:45 2 -> /dev/pts/1
lrwx------ 1 mh users 64 2006-07-04 20:52 255 -> /dev/pts/1
mh@namakemono:/mnt/test$ tail -2 /proc/10724/fd/1
2006年 7月 4日 火曜日 20:52:45 CEST
2006年 7月 4日 火曜日 20:52:46 CEST

As you can see, it kept filling while deleted. The usual technique to recover such a file is to copy it from /proc. I happen to have done so some times before, it works pretty well for static files. But that doesn't in our case: we'll get a new copy of the file, frozen at some point in time. Here, we'd want to 're-link' the file.

Basically, that can be done with debugfs. The problem is that I didn't find a clean way to get the inode number from the /proc/10724/fd/1 file. But that can be worked around. You need root access (what a surprise), and hope your filesystem was mostly clean before removing the file.

namakemono:/mnt/test# e2fsck -n /dev/namakemono/tmp
e2fsck 1.39 (29-May-2006)
Warning! /dev/namakemono/tmp is mounted.
Warning: skipping journal recovery because doing a read-only filesystem check.
/dev/namakemono/tmp contains a file system with errors, check forced.
Pass 1: Checking inodes, blocks, and sizes
Deleted inode 113570 has zero dtime. Fix? no
(...)

Don't worry, the -n option will make the filesystem opened read-only, so there's no risk for your data.
The interesting part of the output is obvious: the number of the deleted inode. You now only need to link the inode:
namakemono:/mnt/test# debugfs -w /dev/namakemono/tmp
debugfs 1.39 (29-May-2006)
debugfs: cd test
debugfs: ln <113570> log
debugfs: q

And see how it worked:
namakemono:/mnt/test# tail -2 log
2006年 7月 4日 火曜日 20:58:40 CEST
2006年 7月 4日 火曜日 20:58:41 CEST

You can tail again, it will show you the file is being appended to.

I guess you can do something along these lines to restore a file from ext2. I don't know for other filesystems.

If someone knows how to get the inode number without e2fsck, comments are opened :)

Update: Well, it didn't take long for me to actually find a better way:
namakemono:/mnt/test$ lsof -p 10724 -a -d 1
COMMAND PID USER FD TYPE DEVICE SIZE NODE NAME
bash 10724 mh 1w REG 254,3 13552 113570 /mnt/test/toto (deleted)
Basically, when the file can be found in /proc/$pid/fd/$fd, run lsof -p $pid -a -d $fd.

After playing around with gnome-power-manager so that it can support spicctrl (which is to be done in hal, actually) to be able to adjust LCD brightness according to whether the AC adapter is plugged or not, I wanted to go a bit further in my quest for battery life. To be honest, I was already adjusting the LCD brightness with a custom acpid event script, but it's still nicer to have it out of the box.

Anyway, the main issue I remembered for battery life, apart from LCD backlight and Wi-Fi, is CPU power states.

When on battery, the CPU in my laptop can handle 4 such states. From C1 to C4 (According to the acpi docs there's actually a C0 state, so that'd make 5). But when on battery, the CPU never goes past level C2. I did some basic check a long time ago, by removing modules, and after removing Firewire, PCMCIA, and USB support, the CPU would go in C3 and C4 states. Though this definitely saves battery because it turns off parts of the computer, I wanted to know exactly what was sucking the CPU, and to keep at least USB, that I use more than the rest.

After selectively removing the modules, it turns out the uhci_hcd support (USB1) is somehow responsible. Which is sad, because my USB mouse is USB1. But it also turns out there's always a peripheral connected to the USB1 hub on my laptop. Indeed, the internal bluetooth support, which is activated at the same time as Wi-Fi, is connected internally through USB1. If I turn off Wi-Fi, it disconects the BT USB device. It appears that in this configuration, having uhci_hcd loaded doesn't have an influence on the CPU. It still reaches C3 and C4 levels. Problem is I don't want to turn off Wi-Fi.

So, with the help of my friend google, I found out that it's possible to unbind drivers from devices, and successfully unbound the USB port the BT device is connected to, without deactivating all the other (external) ports. The sad thing is that when doing such, it also automagically disables the Wi-Fi device (an ipw2200) IRQ, but modprobing ipw2200 again enables it without enabling the BT device.

Next step was to find a way to have this set-up applied automatically at boot-time. I tried to add the following to my udev rules:
ACTION=="add", SUBSYSTEM=="pci", ID=="0000:00:1d.2", ENV{UDEV_START}==1, OPTIONS="ignore_device"
which i'd have expected to do what i want, but it doesn't. I also tried:
ACTION=="add", DRIVER=="uhci_hcd", RUN+="/bin/echo -n 0000:00:1d.2 > /sys/bus/pci/drivers/uhci_hcd/unbind"
which doesn't work either. But:
ACTION=="add", DRIVER=="uhci_hcd", RUN+="/some/script/containing/the/previous/echo"
does. Well, it does work when you restart udev, but not when you reboot. Unfortunately, the initramfs (built with the initramfs-tools) loads a lot of modules, including USB. Meaning that udev doesn't load these and doesn't apply the rules then. Unless I write my own list of modules to load at boot time, initramfs-tools won't produce a useful initramfs for my case. Yaird, on the other hand, did what I wanted it to do, except that it still lacks support for resuming from suspend-to-disk.

In the end, I put a script in /etc/rcS.d. This script unbinds the uhci_hcd driver from the BT device port and re-modprobes ipw2200.

I got a bad surprise, though. After a fresh startup, the CPU would be stuck on C2 state again. Remember how the OpenGL performance would drop if I switch to console and back to X ? It also turns out that it also makes the CPU able to reach C3 and C4 states. There seems to be something odd with the radeon driver...

And hooting like crazy until late at night when France somehow beats Brasil is not going to change my mind. Dumbass.