fidzu : OpenEZX

After having skipped FOSDEM in 2011, I wanted to go this year, especially because of the Golden Delicious stand where we had the OpenPhoenux GTA04 on show. A lot of people came around and were excited that someone picked up where Openmoko had left in 2009. The GTA04 is the true successor of the FreeRunner and I strongly invite all of you to support this movement by buying one. You will not get a more open mobile phone anywhere else.

I know that Brussels is always a bit colder than Frankfurt, so I tend to carry appropriate clothing… what I didn't expect though was that it was frickin' -20 on saturday. I have never been freezing more in my life. Lets cross fingers that I won't come back home with a cold. Especially due to the crazy public transportation situation. The Deutsche Bahn managed to accumulate a one hour delay on my way to Brussels - that's ok, however they managed to crash the engine in Aachen on my way back. So badly that we had to switch to a regional train and switch again in Cologne. Man… *sigh*

On to some good news… another thing I didn't expect was kind of an Openmoko family reunion. It was amazing to find Jan Lübbe, Stefan Schmidt, Daniel Willmann, Harald Welte, and even Rasterman hanging around at FOSDEM. That was just great. I also happened to share my hotelroom with Boudewijn which was unexpected but again very cool.

So despite the freezing, it was a great FOSDEM for me and I'm looking forward to go again next year, perhaps bringing Sabine and Lara Marie as well.

05 Feb 2012 6:08pm GMT

I was looking into compact/mini/pico/handheld projectors, and I obviously wanted something I could use under GNU/linux, there were basically two choices:

1. Pick up a projector with VGA/HDMI: Operating System independent.
2. Pick up a USB projector: shipped only with drivers for MS Windows (and sometimes for MacOSX too).

Since the first choice was more expensive and I verified that writing a driver for the second case wasn't too hard, I picked up an Acer C110, I paid it about 160 €, but you can find it even cheaper somewhere else, grr.

AM7X or AM7XXX

The C110 is based on an Actions Micro AM7212P IC and uses USB bulk transfers with a simple packet based protocol on top to exchange data and commands to and from a host system and the AM7XXX chip.

Other projectors using the same protocol are:

• Acer Series C pico projectors (C20 C110 C112 C120)
• Philips/SagemCom PicoPix projectors (PPX 1020, PPX 1230, PPX 1430, PPX 1630)
• CEL-TEC MP-01
• Other unbranded projectors

These projectors use the USB Vendor and Product IDs 1de1:1101 in mass storage mode and 1de1:c101 in display mode.

Some DPFs too (from Hannspree for instance) are known to use these chips but I don't know yet if they can be put in USB display mode.

I will refer to these devices as either AM7X or AM7XXX devices.

Open Source driver for AM7XXX devices

Reto Schneider and I are reverse engineering the USB protocol used by these devices, using USB dumps and disassembling the Windows device driver, and a basic but already usable library to communicate with those AM7x based projectors can be found in libam7xxx. Reto was the first to start working on that, in the form of acerc11xdrv.

So you can now get these projectors to work wherever libusb-1.0 works, that means you can use them with your phone if it can run GNU/Linux for instance, or even Android/Linux but I don't have an Android device to verify that.

For now all the communication about the development is happening on the #am7xxx IRC Channel on the Freenode Network, come find us, and let us know if you want to help: like hosting a mailing list for us, or sponsoring some hardware (USB projectors you want to use freely or devices you want to use these projectors with).

Side note: the user manuals of these devices sometimes refer to the functionality of displaying images over USB as Display over USB (or DoUSB), this definition is used on a lot of projectors but I don't know if it refers always to the same protocol/mechanism to send images over USB.

Linux running ON other projectors

Incidentally, when I was doing my pre-purchase market research, I ran into several projectors which -unsurprisingly- are running a Linux system themselves (linux kernel, busybox, etc.), here is a summary of what I found out:

• Samsung SP-H03 (not based on AM7X): the firmware image can be downloaded here, and Samsung is providing the source code for the Free Software used in it, you can find it on opensource.samsung.com (AFAIR Harald Welte gave them some directions about GPL compliance, right?).

  This could be an interesting device if you want to run your own code on a projector.

• Acer K330: based on a chip of the same am7x family as the C110.

  The firmware image is available for download and it does contain the Linux kernel and other Open Source software, but the source code is not available, neither Linux or the GPL are mentioned in the downloadable documentation; I am going to do more research on this later to see if Acer is in compliance with the GPL.

Open Projectors?

Having the ability of processing an image before projecting it -either on an external system, or on the projector itself- opens up to a lot of possibilities, and I can foresee an increase of AR applications using projectors; so, do you think there is enough interest for an Open Projectors project? A place where we can share the techniques (keystone correction, or some more sophisticate anamorphic transformations by the means of a Camera-Projector system) and the Open Source software implementing them, all in a single place.

Get in touch if you have any ideas about that.

18 Jan 2012 3:50pm GMT

Every time I read AOSP in the news I think something is not quite right. Here is a faint attempt to set things straight -with some humor, don't take it too seriously-: here is aosp.it.

And I don't even have an Android device... yet.

But seriously, if anyone is interested in the aosp.it domain for some Android/Linux, Open Source related community site (maybe the very Italian one?), just let me know, I may be willing to concede it, if I decide not to start one myself.

Portions of this page are reproduced from work created and shared by Google and used according to terms described in the Creative Commons 3.0 Attribution License

14 Jan 2012 11:27pm GMT

Information Technology has seen a really crazy year. Among all the smaller incidents, the big bangs involved Nokia partnering with Microsoft, abandoning Maemo, HP driving with WebOS against the wall, patent lawsuits everywhere.

What that means for FOSS-lovers is clear… you can't trust any company to continue working on anything. Business demands are what counts in the world of mass markets. If you want longterm support for a platform, your best bet is to build a community around it. But you will also want to work on hardware support otherwise you'll run into the next dead end.

To be honest, right now I don't see much of a future for any mobile Linux-inspired platform other than the mutation called Android. But that's not much of a problem per se. The smartphone market is crazy. To compete in that world, you have to give up on freedom. But is the mass market really what we want? Is it what mobile Linux needs?

I don't think so. There are still huge opportunities for using Linux-based mobile software platforms in niches such as machine2machine communication, home automation, research, teaching, and more. That's where a service-based middleware like FSO comes into the game: for special interests. However, even niche-adoption is hindered without a minimal set of applications. And that is where we still lack: Even special interest people want to use their smartphones to manage contacts, browse the web, send mails, play media, etc. We don't have an integrated software stack with a complete set of UI applications that would cover these needs. Openmoko worked on one, but failed. Nokia worked on multiple ones, but gave up (multiple times). What else do we have?

With HP's recent announcement about releasing WebOS as open source, the game may have changed. If we could use the WebOS application stack on top of the FSO middleware, we may have a real chance to get something great and usable - and complete - soon. I have always liked the WebOS UI. If it's a bit slower than other UIs, who cares as long as it is free?

13 Dec 2011 7:55am GMT

Tempus fugit. I can tell you. Even more so, if you have a baby. I must confess I somewhat underestimated the impact the baby would have on my spare time. In some weird mindset I really thought I could continue working as usual on my open source projects… as we know now I couldn't. I completely lost track and have to catch up with all changes that happened over the last 6 months.

The first bunch of weeks with the baby were really demanding. I mean, really. She screamed a lot and could only sleep in our arms. Boy, were we tired. We carried her around so much we have Schwarzenegger arms now. But it's great to see her developing, err… growing up, of course. With 6 months now she is a very interested baby, eager to learn new things and always trying to become more mobile.

Luckily both my wife and me are self-employed. It so much easier when you can skip some hours at the usual start of the workday and also at the usual end. Of course, the work needs to be done, so we have to compensate when she's in bed. But still, it's very satisfying being able to see her twice a day for a couple of hours - not all families have this luxury. Plus the existence of our two invaluable grandmas… it's great.

Company-wise, the Lauer & Teuber GbR had an amazing year with many interesting iOS (and some Android) projects. We have reached the maximum we can do with the two guys we are, so we decided to grow and hire our first regular employee who's going to start in 2012. We also rented another office and are already moving.

I'm slowly getting back into some of my beloved open source projects… it's great that work on e.g. FSO did not stall at all, but continued while I was "away". Last week, I attended the 3rd installment of the Open Hard- and Software Workshop in munich, where the latest development of the very promising GTA04 mobile phone was presented. I had a talk about Vala which was well received. By the way, my Vala-book plans are not dead yet… just in parking position

Next week I'm attending the FSOSHRCON, a joined conference with the people working on the freesmartphone.org middleware and the SHR software. It's going to be great seeing all the folks again, concentrating a full weekend to agree on some important issues laying the path forward for the next year. Can't wait to be there.

What's left is the feeling that an extremely busy year has passed by, spiced with incredibly intense emotions. I'm a happy man and I love my life. I'm given exciting opportunities, but also challenges - and I plan to accept everything

All the best to you guys!

09 Dec 2011 8:10am GMT

In Debian Unstable the transition to Gnome 3 is taking place; when Gnome 3.0 firstly came out some unnamed geeky users complained loudly about the design decisions of the development team to push strongly towards gnome-shell as a new default UI; gnome-shell was designed focusing on usability (usability is a metric relative to a certain target audience BTW) and simplicity, hiding a lot of details from the users. Obviously you can never make everyone happy so some of us simply happened to be "out of target": you know us computer people (*cough cough*), we like to be in charge and control The Machine... I must admit I still don't have a definitive opinion about the gnome-shell concept, for now I just know that it does not suit me; I am going to try it eventually, maybe I'll get used to it, but in the mean time I need my desktop back just like I shaped it through the years; can this be done without loosing all the good Gnome technologies (Empathy over all of them)?

To be completely fair I have to say that there is little to complain about with Gnome developers, we can still get our good old GNOME desktop fully back by using the fall-back mode based on gnome-panel and live happily ever after, let's take a look at how this can be accomplished.

NOTE: GNOME people state that the fall-back mode is meant for systems with older graphic cards which cannot run gnome-shell, however it can very well be seen as a good opportunity for those who do not want to run gnome-shell just yet.

Getting back to the topic: some minor touches are needed to make the panel look more like what we are used to, maybe some of these settings could even become default for fall-back mode, we'll see.

First, enable fall-back mode (on Debian there is a dedicated session you can choose from the Log-in Manager for that) and change some desktop settings, in a terminal type:

$ gsettings set org.gnome.desktop.session session-name 'gnome-fallback'
$ gsettings set org.gnome.desktop.interface 'menus-have-icons' true
$ gsettings set org.gnome.desktop.interface 'buttons-have-icons' true
$ gsettings set org.gnome.desktop.background 'show-desktop-icons' true

gnome-tweak-tool can be used for some of these settings like shown in the attached images.

Then rearrange the applets on the panel as you please (use Alt-RightClick to access the panel properties), and fix the theming using this patch to have a light panel again (against gnome-themes-standard=3.0.2-1):

$ mkdir $HOME/.themes
$ cd $HOME/.themes
$ cp -r /usr/share/themes/Adwaita Adwaita-fallback
$ cd Adwaita-fallback
$ patch -p1 < $HOME/adwaita-fallback-panel-theme.patch
$ gsettings set org.gnome.desktop.interface 'gtk-theme' 'Adwaita-fallback'

Some final touches for the Metacity window manager and to the clock applet, and we are all set:

$ gconftool-2 --type string --set /apps/metacity/general/focus_mode mouse
$ gconftool-2 --type boolean --set /apps/metacity/general/compositing_manager true
$ gconftool-2 --type string --set /apps/panel3-applets/clock/custom_format '<span color="#333">%a %d %b</span> <b>%H:%M</b>'
$ gconftool-2 --type string --set /apps/panel3-applets/clock/format custom

Ah, in the new gnome-panel based on Gtk3 there are still some details to take care of, I hope issues like that will be addressed and that the panel will be supported for quite some time.

19 Oct 2011 9:37pm GMT

After letting us wait for a bit longer than scheduled (13 days), the hospital initiated the contractions. For the first couple of hours, everything went just perfect, but then the little one got stuck on the way and we had to resort to a cesarean section. Lara Marie Lauer was born 8th of June at 04:41 (AM) with 3460 gramms and 49 cm.

Mummy was still on intensive care and so they gave her to me. I can't express the feelings I had in this very moment. I'm still kind of overwhelmed every time I see her. Thanks for all of you who waited anxiously with me and those who prayed for us. The most important tasks for the near future is getting Mummy to recover and Lara Marie to become accustomed to us and the rest of the outside world.

Please bear with me if in the next time I'm not as responsive as usually

09 Jun 2011 4:06pm GMT

And now for something completely different… while we are all waiting for my baby to arrive (who was scheduled for 25th of May), she just received her first greeting card - together with a personalized bib and a towel (with integrated hood - pretty fancy!) from my good friends at #openmoko-cdevel.

Guys, seeing this card was very heartwarming - it means a lot to me that you share my anticipation, thanks a lot! And I'm 100% sure she will appreciate her gifts… now let's cross fingers it won't take much longer… waiting is the hardest part of it

Yours,

Mickey.

30 May 2011 8:54am GMT

I had been experiencing errors when cloning the OpenEZX kernel with git and I was finally able to solve the issue on the server, I am putting some notes here to save some time to someone else. Here's how the story started:

ao2@jcn:~$ git clone git://git.openezx.org/openezx.git
Cloning into openezx...
remote: Counting objects: 1954118, done.
remote: fatal: unable to create thread: Resource temporarily unavailable
remote: aborting due to possible repository corruption on the remote side.
fatal: early EOF
fatal: index-pack failed

Looking at the server statistics with htop confirmed this was happening because git was running out of memory on the server; it is worth noticing that the issue was not present when cloning other projects from the same server (Linux kernel projects as well, hence with a comparable size in principle).

With the following points in mind:

• The server hosting the remote repository has about 1.6 GiB of RAM, but no swap space;
• In OpenEZX we are using TopGit to track topic branches, which generates tons of merge commits and makes the git repository heavier;

my thoughts went like:

1. during a clone operation some compression of git objects occurs;
2. because of the lack of swap space the compression operation must fit in memory;
3. because of TopGit the compression operation on this repository was more onerous than on the other projects, causing the memory outage.

So some optimization on the repository about objects compression was needed.

The first thing that came to mind was git-gc but that was failing as well:

openezx:~# cd /home/git/repositories/openezx.git
openezx:/home/git/repositories/openezx.git# git gc --aggressive
Counting objects: 1954118, done.
Delta compression using up to 2 threads.
warning: suboptimal pack - out of memory02)   
fatal: Out of memory, malloc failed (tried to allocate 602234 bytes)
error: failed to run repack

The repack operation is performed by git-pack-objects, so after Reading The Fine Manual I was able to make git-gc run successfully using these steps:

openezx:/home/git/repositories/openezx.git# git config pack.thread 1
openezx:/home/git/repositories/openezx.git# git gc --aggressive
Counting objects: 1954118, done.
Compressing objects: 100% (1936802/1936802), done.
Writing objects: 100% (1954118/1954118), done.
Total 1954118 (delta 1618716), reused 0 (delta 0)

note that using only one thread makes the process quite slow.

In some other cases it could be useful to change also the pack.windowMemory config option, but a relation involving the address space, the available memory and the number of threads has to be found, so since just using one thread worked fine for me, I took that as the minimal fix for my problem.

Bottom line: cloning the repository is now back working:

ao2@jcn:~$ git clone git://git.openezx.org/openezx.git
Cloning into openezx...
remote: Counting objects: 1954118, done.
remote: Compressing objects: 100% (318086/318086), done.
remote: Total 1954118 (delta 1618716), reused 1954118 (delta 1618716)
Receiving objects: 100% (1954118/1954118), 377.38 MiB | 738 KiB/s, done.
Resolving deltas: 100% (1618716/1618716), done.

Side note: the more attentive reader would have noticed a cosmetic defect in the output when git-gc fails (more precisely from git-pack-objects: warning: suboptimal pack - out of memory02)), well don't loose any sleep over it :) it has been reported and there is a workaround for that already.

06 May 2011 10:41am GMT

It looks like Santa came early this year.

KernelLabs sponsored me for a Kinect sensor device unit so I can experiment writing a Linux kernel driver for it.

So in the next weeks I'll be working on a gspca driver for this device. For now the code is going to be hosted in the gspca_kinect repository, as an out of kernel module, this will ease compile/test cycle; if it comes out that changes are needed to gspca itself, then I'll decide whether hosting these changes as patches, or switching to a kernel clone repository; suggestions will be welcome. The driver is working already, but currently you can just use the sensor as a normal WebCam.

About the Kinect

The Kinect sensor is a device used by Microsoft for its Kinect project, which is a system for controller-less Human-Computer interaction firstly targeted for Xbox 360, but rumors say MS could be integrating this technology into its future operating systems; the hardware is only part of the system of course, the software does most of the interpretation work figuring out how many users there are and assigning a meaning to their actions.

Great part of the Kinect communication protocol has been already figured out, thanks to the adafruit people who dumped the communication stream with the Xbox using an usb bus analyzer, and to Héctor Martín Cantero (marcan) who started analyzing the trace for the libfreenect driver. Marcan is also the guy who won the adafruit bounty for a kinect opensource driver, and the one behind AsbestOS. All these efforts have flowed into the OpenKinect project, wisely guided by Joshua Blake.

For an overview about the hardware you can see the IFixit teardown, the part I am interested in for now is the integration of the video capturing sub-device which provides what is usually called RGBD data (Red, Green, Blue, Depth), the Depth component gives spatial information about the captured scene, easing out the process of image segmentation. Just to give an idea, background subtraction is one step of the segmentation process, and can be achieved quite robustly with techniques like Depth keying (the spatial version of Chroma keying). But I am really not an expert in this area.

In the Kinect device, RGBD data is captured from two distinct sensors: a regular RGB sensor and a monochrome sensor which, with the aid of a IR structured light, captures what is finally exposed as a depth map; so what we have is basically a Structured-light 3D scanner.

Kernel driver development

I don't know yet if the gspca driver is going to define two video devices, one for each sensor, or if a combined format would be preferred, I am asking for advice from others more expert in this field.

This is the plan:

• Stabilize the first version of the driver which does device registration/initialization and allows capturing the RGB data with fixed resolution and fixed framerate using a video device node. The RGB data comes as a raw Bayer pattern, precisely in the V4L2_PIX_FMT_SGRBG8 pixelformat.
• Add support for capturing the Depth map data somehow. Each depth value has 11-bit precision, and the data is transferred as a packed array, I still don't know how such format should be presented to userspace.

Follow the discussion on the OpenKinect mailing list or on linux-media.

Thinking outside the (X)box

Ah, don't forget to check out all the fancy stuff people are doing with this toy.

06 Dec 2010 9:12pm GMT

Lately I've been fixing some defects in the hidraw interface in the Linux kernel (commits d20d5ff and e42dee9), simple issues like these NULL pointer dereference are a good example to show how to analyze a Linux bug trace in order to spot the defective code. So let's take a look. The steps to fix any defect are basically:

1. reproduce the problem (a quick introduction to the concept of "Observability" of software faults is in: Dissecting The Bug)
2. find the offending code/policy
3. elaborate a solution
4. implement and test the solution is working

Reproducing the problem

If the problem is in some userspace/kernelspace interface then writing a test program which triggers the bug may be the quickest way to reproduce it. The test program should be as simple as possible, doing the minimum required to expose the defect, as it will be used also as a proof that the bug has been solved in the right way; just like when proving a theorem we don't want to have more hypotheses than are necessary. The test program for one of the issues above looks like this:

#include <stdio.h>
#include <stdlib.h>
#include <sys/types.h>
#include <sys/stat.h>
#include <fcntl.h>
#include <unistd.h>

#include <linux/hidraw.h>

int main(int argc, char *argv[])
{
        int fd = -1;
        unsigned char report[2] = {0x01, 0x00};
        int ret;

        if (argc != 2) {
                fprintf(stderr, "usage: %s </dev/hidrawX>\n", argv[0]);
                exit(1);
        }

        fd = open(argv[1], O_RDWR);
        if (fd < 0) {
                perror("hidraw open");
                exit(1);
        }

        while (1) {
                ret = write(fd, report, sizeof(report));
                printf("ret: %d\n", ret);
        }

        close(fd);
        exit(0);
}

That gives me the occasion for an observation about one aspect of testing procedures: as you can see the test program above uses deliberately some bad practice, namely it does not check the return value of the write() call in order to exit the while loop; we know this is generally bad from a programming point of view, however it turns out to be good from another point of view: bad programs can spot cases we didn't think of in our code paths; it goes without saying that this is no excuse for "uncontrolled" bad practices, nor for the bug we had in the first place :).

Anyhow, the code above exposes the defect on kernels up to 2.6.35, just run the program and unplug the (USB) device (a Sony Sixaxis in my case):

BUG: unable to handle kernel NULL pointer dereference at 0000000000000028
IP: [<ffffffffa0f0a625>] hidraw_write+0x3b/0x116 [hid]
PGD 37082067 PUD 3701f067 PMD 0 
Oops: 0000 [#1] SMP 
last sysfs file: /sys/devices/pci0000:00/0000:00:04.0/usb4/idVendor
CPU 0 
Modules linked in: hid_sony usbhid hid kvm_amd kvm powernow_k8 mperf cpufreq_powersave cpufreq_conservative cpufreq_stats cpufreq_userspace ipt_MASQUERADE lirc_serial(C) lirc_dev bridge stp ppdev lp sco bnep rfcomm l2cap crc16 tun sit tunnel4 binfmt_misc uinput fuse ip6table_raw ip6table_mangle ip6t_REJECT ip6t_LOG nf_conntrack_ipv6 ip6table_filter ip6_tables xt_tcpudp ipt_REJECT ipt_ULOG xt_limit xt_state xt_multiport iptable_filter iptable_nat nf_nat nf_conntrack_ipv4 nf_conntrack nf_defrag_ipv4 iptable_mangle iptable_raw ip_tables x_tables nfsd exportfs nfs lockd fscache nfs_acl auth_rpcgss sunrpc hwmon_vid loop snd_hda_codec_nvhdmi snd_hda_codec_via snd_hda_intel snd_hda_codec snd_hwdep snd_pcm_oss snd_mixer_oss snd_pcm snd_seq_midi snd_rawmidi nvidia(P) snd_seq_midi_event snd_seq snd_timer snd_seq_device btusb bluetooth joydev snd edac_core shpchp video tpm_tis tpm evdev rfkill parport_pc parport tpm_bios pcspkr asus_atk0110 processor output edac_mce_amd soundcore snd_page_alloc i2c_nforce2 pci_hotplug k8temp wmi i2c_core button ext3 jbd mbcache dm_mod sg sd_mod sr_mod cdrom crc_t10dif ata_generic usb_storage ahci libahci pata_amd ohci_hcd libata ehci_hcd scsi_mod usbcore forcedeth floppy nls_base thermal thermal_sys [last unloaded: hid]

Pid: 4818, comm: test_hidraw_wri Tainted: P         C  2.6.35-ao2 #2 M3N78-VM/System Product Name
RIP: 0010:[<ffffffffa0f0a625>]  [<ffffffffa0f0a625>] hidraw_write+0x3b/0x116 [hid]
RSP: 0018:ffff880037081ee8  EFLAGS: 00010202
RAX: 0000000000000000 RBX: 0000000000000002 RCX: ffff880037081f58
RDX: 0000000100000000 RSI: 0000000000000008 RDI: ffffffffa0f128b0
RBP: 0000000000000001 R08: ffffffffa0f0a5ea R09: 000000000040087a
R10: 0000000000000000 R11: ffffffff81150c83 R12: ffff880037081f58
R13: 00007fff1b34cab0 R14: 00000000ffffffed R15: 0000000000000000
FS:  00007fa946870700(0000) GS:ffff880001a00000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000000000028 CR3: 000000005ad24000 CR4: 00000000000006f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Process test_hidraw_wri (pid: 4818, threadinfo ffff880037080000, task ffff88006003e630)
Stack:
 ffff88005ad95000 00007fff1b34cab0 ffff880037081f58 00007fff1b34cba0
<0> 0000000000000000 ffffffff810ea46f 0000000000000003 0000000000000008
<0> ffff88005ad95000 00007fff1b34cab0 00000000004005c0 ffffffff810ea57e
Call Trace:
 [<ffffffff810ea46f>] ? vfs_write+0xa4/0x100
 [<ffffffff810ea57e>] ? sys_write+0x45/0x6b
 [<ffffffff81008a02>] ? system_call_fastpath+0x16/0x1b
Code: 53 48 8b 47 18 48 c7 c7 b0 28 f1 a0 48 89 d3 48 8b 40 10 8b 68 58 e8 07 9a 3f e0 81 e5 ff ff 0f 00 89 ed 48 8b 04 ed c0 2b f1 a0 <4c> 8b 60 28 49 83 bc 24 50 1c 00 00 00 0f 84 af 00 00 00 48 81 
RIP  [<ffffffffa0f0a625>] hidraw_write+0x3b/0x116 [hid]
 RSP <ffff880037081ee8>
CR2: 0000000000000028
---[ end trace 06cb2d01ded47cc4 ]---

The most important info in this message is highlighted above in line two, that is:

IP: [<ffffffffa0f0a625>] hidraw_write+0x3b/0x116 [hid]

This tells us the last instruction executed, the one triggering the bug; the format is symbol_name+offset/symbol_size [module_name] as can be seen in mm/slab.c.

Finding the offending code

To find where the offending instruction is, we can disassemble the object code with objdump, here's the interesting function:

00000000000008e5 <hidraw_write>:
 8e5:   41 56                   push   %r14
 8e7:   41 be ed ff ff ff       mov    $0xffffffed,%r14d
 8ed:   41 55                   push   %r13
 8ef:   49 89 f5                mov    %rsi,%r13
 8f2:   41 54                   push   %r12
 8f4:   55                      push   %rbp
 8f5:   53                      push   %rbx
 8f6:   48 8b 47 18             mov    0x18(%rdi),%rax
 8fa:   48 c7 c7 00 00 00 00    mov    $0x0,%rdi
 901:   48 89 d3                mov    %rdx,%rbx
 904:   48 8b 40 10             mov    0x10(%rax),%rax
 908:   8b 68 58                mov    0x58(%rax),%ebp
 90b:   e8 00 00 00 00          callq  910 <hidraw_write+0x2b>
 910:   81 e5 ff ff 0f 00       and    $0xfffff,%ebp
 916:   89 ed                   mov    %ebp,%ebp
 918:   48 8b 04 ed 00 00 00    mov    0x0(,%rbp,8),%rax
 91f:   00 
 920:   4c 8b 60 28             mov    0x28(%rax),%r12
 924:   49 83 bc 24 30 1c 00    cmpq   $0x0,0x1c30(%r12)
 92b:   00 00 
 92d:   0f 84 af 00 00 00       je     9e2 <hidraw_write+0xfd>
 933:   48 81 fb 00 10 00 00    cmp    $0x1000,%rbx
 93a:   76 25                   jbe    961 <hidraw_write+0x7c>
 93c:   65 48 8b 04 25 00 00    mov    %gs:0x0,%rax
 943:   00 00 
 945:   8b b0 c8 01 00 00       mov    0x1c8(%rax),%esi
 94b:   48 c7 c7 00 00 00 00    mov    $0x0,%rdi
 952:   31 c0                   xor    %eax,%eax
 954:   41 b6 ea                mov    $0xea,%r14b
 957:   e8 00 00 00 00          callq  95c <hidraw_write+0x77>
 95c:   e9 81 00 00 00          jmpq   9e2 <hidraw_write+0xfd>
 961:   48 83 fb 01             cmp    $0x1,%rbx
 965:   77 25                   ja     98c <hidraw_write+0xa7>
 967:   65 48 8b 04 25 00 00    mov    %gs:0x0,%rax
 96e:   00 00 
 970:   8b b0 c8 01 00 00       mov    0x1c8(%rax),%esi
 976:   48 c7 c7 00 00 00 00    mov    $0x0,%rdi
 97d:   31 c0                   xor    %eax,%eax
 97f:   41 be ea ff ff ff       mov    $0xffffffea,%r14d
 985:   e8 00 00 00 00          callq  98a <hidraw_write+0xa5>
 98a:   eb 56                   jmp    9e2 <hidraw_write+0xfd>
 98c:   be d0 00 00 00          mov    $0xd0,%esi
 991:   48 89 df                mov    %rbx,%rdi
 994:   41 be f4 ff ff ff       mov    $0xfffffff4,%r14d
 99a:   e8 00 00 00 00          callq  99f <hidraw_write+0xba>
 99f:   48 85 c0                test   %rax,%rax
 9a2:   48 89 c5                mov    %rax,%rbp
 9a5:   74 3b                   je     9e2 <hidraw_write+0xfd>
 9a7:   e8 00 00 00 00          callq  9ac <hidraw_write+0xc7>
 9ac:   89 da                   mov    %ebx,%edx
 9ae:   4c 89 ee                mov    %r13,%rsi
 9b1:   48 89 ef                mov    %rbp,%rdi
 9b4:   e8 00 00 00 00          callq  9b9 <hidraw_write+0xd4>
 9b9:   48 85 c0                test   %rax,%rax
 9bc:   41 b6 f2                mov    $0xf2,%r14b
 9bf:   75 19                   jne    9da <hidraw_write+0xf5>
 9c1:   b9 01 00 00 00          mov    $0x1,%ecx
 9c6:   48 89 da                mov    %rbx,%rdx
 9c9:   48 89 ee                mov    %rbp,%rsi
 9cc:   4c 89 e7                mov    %r12,%rdi
 9cf:   41 ff 94 24 30 1c 00    callq  *0x1c30(%r12)
 9d6:   00 
 9d7:   41 89 c6                mov    %eax,%r14d
 9da:   48 89 ef                mov    %rbp,%rdi
 9dd:   e8 00 00 00 00          callq  9e2 <hidraw_write+0xfd>
 9e2:   48 c7 c7 00 00 00 00    mov    $0x0,%rdi
 9e9:   e8 00 00 00 00          callq  9ee <hidraw_write+0x109>
 9ee:   5b                      pop    %rbx
 9ef:   5d                      pop    %rbp
 9f0:   41 5c                   pop    %r12
 9f2:   41 5d                   pop    %r13
 9f4:   49 63 c6                movslq %r14d,%rax
 9f7:   41 5e                   pop    %r14
 9f9:   c3                      retq

The instruction we are interested in is at hidraw_write+0x3b which is at address 0x8e5+0x3b that is 0x920:

 918:   48 8b 04 ed 00 00 00    mov    0x0(,%rbp,8),%rax
 91f:   00
 920:   4c 8b 60 28             mov    0x28(%rax),%r12
 924:   49 83 bc 24 30 1c 00    cmpq   $0x0,0x1c30(%r12)
 92b:   

Now, how do we find the correspondent instruction in the source code? If we don't want to do that the hard way we can use the -S option of objdump like mentioned also in Documentation/BUG-HUNTING in the kernel tree, which interleaves source code with the disassembled listing, here's the excerpt we need:

        dev = hidraw_table[minor]->hid;
 916:   89 ed                   mov    %ebp,%ebp
 918:   48 8b 04 ed 00 00 00    mov    0x0(,%rbp,8),%rax
 91f:   00 
 920:   4c 8b 60 28             mov    0x28(%rax),%r12

So in this case the problem is that the code is trying to dereference hidraw_table[minor], but this entry could be NULL if we disconnect the device while performing the write() in a loop without checking return values.

Finding out the exact line could be a little harder when macros and inlined functions are used, but once we know how to deal with a simple scenario like the one proposed the complicated cases become someway doable too.

Elaborating a solution

The fix is trivial is this case: check the pointer is not NULL before dereferencing it, bail out otherwise.

Implementing and testing the solution

This is the actual patch which solves the issue:

diff --git a/drivers/hid/hidraw.c b/drivers/hid/hidraw.c
index 9eaf6ae..a3866b5 100644
--- a/drivers/hid/hidraw.c
+++ b/drivers/hid/hidraw.c
@@ -109,6 +109,12 @@ static ssize_t hidraw_write(struct file *file, const char __user *buffer, size_t
        int ret = 0;
 
        mutex_lock(&minors_lock);
+
+       if (!hidraw_table[minor]) {
+               ret = -ENODEV;
+               goto out;
+       }
+
        dev = hidraw_table[minor]->hid;
 
        if (!dev->hid_output_raw_report) {

Now, using the fixed hid module, if we run the test program again and disconnect the device we won't hurt the kernel anymore.

02 Nov 2010 9:18pm GMT

Howdy, dear reader!

It's been a while on this blog, mainly due to the fact that many short status updates are better twittered than blogged. Then again, as promised / threatened in last year's installment of this column, I had to spend most of the time this year with iOS development, rather than with FOSS - and it doesn't look like this will change much (you know, food and things…). Still I do care a lot about projects like OpenEmbedded, Vala, freesmartphone.org, and the like, so here's what has been going on this year:

OpenEmbedded (www.openembedded.org)

OE moved along quite well this year. I did not have much time for it - other than taking care about a couple of Vala and FSO recipes - but I'm especially pleased that the community finally embraced major clean up. Thanks to Frans, Richard, and all others involved, OE is improving heavily - although it wasn't easy: Over the last couple of years, the OE core contributors developed a resistance against any changes affecting more than a handfull of recipes, however in order to make OE handle even more contributors and various use cases, we had to do some substantial cleanups. This will reduce maintenance and improve the overall quality of recipes in OE, which is the #1 complaint I hear.

Vala (www.vala-project.org)

During the first half of the year, Vala went through some extremely tiring phases of non-activity, which improved vastly when its main developers opened up a bit, i.e. giving more developers access to the tree, adding branches, etc. There have been many changes in the Dova profile, but also the GLib profile has seen an incredible amount of work, bugfixes, some new features, and more.

The pace of changes that affect basic things had also impact on my vala-book plans; apart from a severe lack of time on my side, I think it's better to wait until Vala is closer to 1.0. Otherwise I risk describing a moving target, which - considering the time I have to work on that project - would effectively kill it. That said, it's great to see that Vala is getting better every day and gains more and more popularity from all kinds of developers.

FSO (freesmartphone.org)

The progress on freesmartphone.org is two-fold; on one hand, we have seen quite a nice amount of work to support more devices. On the other hand though, in contrast to all the work I did in 2009, there has been a severe lack of development of the core in 2010. This I plan to change as soon as possible. For 2011, I see myself continuing to develop FSO in the following three dimensions; internal, external, and integration.

1. Internal | FSO is a heavy DBus consumer. I think by now we are one of the largest projects using DBus, at least considering the amount of API and running processes that communicate with each other via DBus. We always had our share of problems with DBus, especially some concurrency problems and race conditions are still haunting us. Both libdbus and dbus-glib exhibit their own share of problems, obviously this is not much of an issue on the desktop, but it turns out to be a major PITA on embedded systems, such as a phone. That's why I have been excited since I heard that the glib team planned to write their own DBus backend and put it right into the glib. This work has now been released as of glib 2.26. Over the next weeks, I will port FSO to using gdbus in a branch.
2. External | DBus-signals have some problems. That's why some big projects (BlueZ and ConnMan, to name two of them) adopted an agent-style of API, where the clients have to implement a server API which is being called by the actual servers. While this means some more work for client developers, it has major benefits. I'm going to change some of our APIs to adopt this style.
3. Integration | To deliver an integrated solution for today's mobile phones, FSO needs to add more glue to work with existing services, such as BlueZ (bluetooth connectivity), Connman (ethernet and wifi connectivity), and some VoIP services. While these services work fine on their own, FSO lacks an API that uses these individual services in combination to achieve higher level tasks.

All this means that I will not be working much on the actual ports, but rather use my - very limited, did I say that yet? - time to drive the core forwards. I still believe that we will have full FOSS phones - other than the Openmoko devices - soon. Please help to make this dream a reality. (And no, please don't talk to me about Android…)

Cheers,

:M:

16 Oct 2010 4:34pm GMT

Recently both OSnews and Slashdot pointed out some experiments about context-aware UIs done by Christian Giordano at Canonical (the company behind Ubuntu GNU/Linux), and the first results are somewhat interesting. As you can see in the good video demo from the original article the effects are nothing mind blowing, but they serve greatly to illustrate the concept, and by building on that something more useful would come out eventually.

That reminds me of another (never realized) old idea of mine from when I was attending the Operating System course at the university, I wanted to bind system responsiveness -at a lower level- to user presence, by tuning scheduler parameters according to the user being at his/her computer or not. Imagine a desktop computer which is encoding a video in background, when the user is interacting with the system then the interactive tasks must be more important, but when he/she leaves, then the system could assign to the background job all the resources it needs to run "at its best".

The parameters to change system responsiveness could be, just for instance, process niceness, swappiness (some report that less swapping results in more responsiveness, but I don't have numbers either to agree or disagree on that), or the whole scheduler could be changed on the fly if there is any system allowing that.

The mechanisms to detect user presence could be the usual: proximity sensors, video from a webcam or audio form a mic (humor alert), some measure of mouse and keyboard activity, a pillow/button on the seat (that would tell butt-on / butt-off... ehm).

In my original thoughts I wanted to detect when the monitor was manually switched off, that's because I usually switch it off when I leave the computer in order to save some power; on a laptop we have the lid button which could be abused, but I couldn't find a way to detect when an external monitor is turned off, anyone?

21 Sep 2010 8:01pm GMT

We all know linux is cool, don't we? However these people at SuperFreddo make it supercool (freddo is the Italian word for cool/cold).

SuperFreddo is a frozen food chain here in Naples Italy, and the penguin in their logo has an interesting resemblance to Tux, the linux kernel mascot: the contour is not exact and it is wearing a hat and a scarf, but you just look at the feet -at their inclination- and you have no more doubts.

I am not on Facebook, so maybe some of you could point out to them where the designer of their logo could have taken inspiration from.
Could there be also a legal case here? I don't know.

I attach a couple of pictures of their shopping bags, just for the records, and to remind people that from 2011 plastic bags are banned in Italy.

20 Jul 2010 9:42am GMT

Since late May 2010 I've been given write access to the OpenEmbedded repository.

Thanks to the OE devs who supported me.

04 Jun 2010 3:02pm GMT

No matter how much careful we are when writing code, whatever changes we are making to a piece of software we must test them before production, even Donald Knuth once said: Beware of bugs in the above code; I have only proved it correct, not tried it. :).

Moreover, if the software we are working on is targeting an embedded system and needs cross-compilation and depends on other software, then testing can be more tedious: we have to prepare patches/archives and instruct the target SDK to pick our latest code, or we could code directly in the SDK working tree, but that would not be very clean. If you use git and OpenEmbedded there is a very neat way to build directly from our own working directory on the filesystem. By developing with git from the start, your changes are ready to be sent upstream as soon as they are proven to be OK.

Git cloning from filesystem

I am not going to repeat how nice, sleek and whatnot git is, just let me show you again how flexible it is: you can easily "re-clone" from a git clone on the filesystem, no need to have any servers around:

$ cd /tmp
$ git clone file:///home/ao2/Proj/EZX/OE/framework

See? By only using the file:// URI scheme we fetch from a git (working) directory: a git directory is a valid git repository, there's some beauty in this regularity.

Fetching the latest code from our git working dir with OpenEmbedded

OpenEmbedded uses the bitbake task executor, .bb files (called recipes) are used to describe bitbake tasks, they are generally used to define packages for distributing some software, and the source code of the software can be fetched in many different ways; in this case we are editing a recipe which uses the git fetcher, let's take a look at the original recipes/freesmartphone/frameworkd_git.bb:

DESCRIPTION = "The reference implementation of the freesmartphone.org framework APIs"
HOMEPAGE = "http://www.freesmartphone.org"
AUTHOR = "FreeSmartphone.Org Development Team"
SECTION = "console/network"
DEPENDS = "python-cython-native python-pyrex-native"
LICENSE = "GPL"
SRCREV = "93673aa09cafc8fb5cfc3cb4055a73e25e595b70"
PV = "0.9.5.9+gitr${SRCPV}"
PR = "r3"
PE = "1"

inherit distutils update-rc.d python-dir

INITSCRIPT_NAME = "frameworkd"
INITSCRIPT_PARAMS = "defaults 29"

SRC_URI = "${FREESMARTPHONE_GIT}/framework.git;protocol=git;branch=master \
           file://frameworkd \
           file://frameworkd.conf \
           "
SRC_URI_append_shr = "file://oeventsd-use-opimd-signals.patch;patch=1"

S = "${WORKDIR}/git"
...
...

we can change the path in SRC_URI to a directory on the filesystem, and change the protocol to file so that git uses our working copy to fetch the code for the package, we can also specify our development branch here. Note that we still have to use the git:// scheme, because that's what tells bitbake which fetcher to use.

diff --git a/recipes/freesmartphone/frameworkd_git.bb b/recipes/freesmartphone/frameworkd_git.bb
index dac7fe9..ddae81d 100644
--- a/recipes/freesmartphone/frameworkd_git.bb
+++ b/recipes/freesmartphone/frameworkd_git.bb
@@ -4,9 +4,9 @@ AUTHOR = "FreeSmartphone.Org Development Team"
 SECTION = "console/network"
 DEPENDS = "python-cython-native python-pyrex-native"
 LICENSE = "GPL"
-SRCREV = "93673aa09cafc8fb5cfc3cb4055a73e25e595b70"
+SRCREV = "${AUTOREV}"
 PV = "0.9.5.9+gitr${SRCPV}"
-PR = "r3"
+PR = "r4"
 PE = "1"

 inherit distutils update-rc.d python-dir
@@ -14,7 +14,7 @@ inherit distutils update-rc.d python-dir
 INITSCRIPT_NAME = "frameworkd"
 INITSCRIPT_PARAMS = "defaults 29"

-SRC_URI = "${FREESMARTPHONE_GIT}/framework.git;protocol=git;branch=master \
+SRC_URI = "git:///home/ao2/Proj/EZX/OE/framework;protocol=file;branch=freescale_neptune \
            file://frameworkd \
            file://frameworkd.conf \
           "          

Now we are set, we can build packages as usual and test our local changes on the target system:

$ bitbake -c clean recipes/freesmartphone/frameworkd_git.bb
$ bitbake recipes/freesmartphone/frameworkd_git.bb

27 May 2010 8:46am GMT