plaes.org | Be free!

During the previous week I was trying to master the regular expressions. And as a result I wrote a printf() format tokeniser. It also finds operators which have order arguments (gettext uses these). Here it is:

RegExp.lastIndex = 0;
var r = /%(\d+$)?([+-#])?(\d|\*)?(.(\d|\*))?((h+){0,2}|(l+){0,2})?[diufgGxXsc%]/g;
var s = [];
while ((x = r.exec(str)) != null)
s.push(x[0]);
return s;

It has some bugs and it isn’t perfect, but it’s still better than nothing

And of course.. last weekend was one of the best of my life…

So… I took an online test…

Those who haven’t had time to read The State of Linux Graphics article should first read it…

Today, while browsing the linux-kernel mailinglist found a nice RFC posting about creating a generic GPU layer in the kernel which both drm and fb drivers can use. Adding layers is considered adding extra complexity, but current situation seems to be even more complex - when both framebuffer and direct rendering both are used, the drivers try to mask eachother when switching modes… Talk about complexity here…

When everyone else is talking about AMD-ATI merger, the users of ATI graphics drivers are still suffering because there is no ATI X1(3,6,8,9)00 or r520 support, although Dave has written a driver (consisting of 600 lines of code) more than 4 months ago, but because he did it under NDA he has to get ATI’s comment. So far he hasn’t heard anything from them…

When there are companys who try to make things easier for open source users (Sun - Solaris, Java; Intel - graphics, wlan) then there are and always will be companys who don’t care about it’s minor but most loyal users until it is too late.

Good luck AMD-ATI and make me happy again

Jõhvikas hacking…
Photo by Priit Laes.

Spent a weekend in Estonia where old colleague Ruve threw his birthday party. Beautiful girls, nice drinks, fun-fun-fun and good weather
Spent Friday and Sunday nights on the couch in Ruve’s living room accompanied by random visits by Jõhvikas and Pätu (the cats) so it was quite challenging staying asleep.
Missed the 8.00 ship to Helsinki in the morning, fortunately succeeded to get on the 10.00 ship thanks to the lovely lady in the check-in. Arrived at office sometime at 12 o’clock…
Back in Estonia on Thursday evening…

If you start seeing things like this in your servers dmesg output:
swapper: page allocation failure. order:0, mode:0x20
[<c01364d2>] __alloc_pages+0x1fb/0x323
[<c0136612>] __get_free_pages+0x18/0x24
[<c0139713>] kmem_getpages+0x1a/0xba
[<c013a35b>] cache_grow+0xaf/0x164
[<c013a5eb>] cache_alloc_refill+0x1db/0x218
[<c013a809>] kmem_cache_alloc+0x46/0x48
[<c0289d85>] sk_alloc+0x2b/0xa0
..................SNIP..............................
[<c0290c79>] netif_receive_skb+0x13f/0x193
[<c024331b>] e100_poll+0x37e/0x627
[<c0290e4d>] net_rx_action+0x70/0xf2
[<c011e7c7>] __do_softirq+0x5f/0xca
[<c011e85f>] do_softirq+0x2d/0x2f
[<c0106895>] do_IRQ+0x11d/0x129
[<c01047b0>] common_interrupt+0x18/0x20
[<c0101f03>] mwait_idle+0x25/0x4a
[<c0101ebe>] cpu_idle+0x35/0x55
[<c03b683e>] start_kernel+0x15b/0x176
[<c03b6310>] unknown_bootoption+0x0/0x171

…then it’s probably getting too much traffic. Seems like e100 (network card) is gobbling up all the available lowmem memory for its buffers… The quick solution for this problem is to increase the number in /proc/sys/vm/min_free_kbytes. But the average network usage is ~6.4Mb/s and it would be probably even higher if the machine was faster…