Linux

Failed to submit batch buffer (Xorg)

Apr 25th

Posted by noisebleed in Gentoo

No comments

Another Xorg update…

After my last Xorg update I’ve lost the nice ability to log into my KDE. Well, this *sucks* because I spent a long time compiling kdelibs and friends so I really want to use it.

Symptoms

A blank screen on login. You can even see your mouse pointer but nothing else.

If you take a look at the Xorg log you’ll see X is mad about a “batch buffer thingie”.

Error in /var/log/Xorg.0.log:
(EE) intel(0): Failed to submit batch buffer, expect rendering corruption or even a frozen display: No such device

The Solution

Pretty ease to solve this one. Either upgrade your kernel to something like 2.6.36 or better (recommended) or block xf86-video-intel>2.14.

Permanent solution
Upgrade your kernel. I was running an old 2.6.32-tuxonice-r7. Upgraded to 2.6.36 and… Welcome back, KDE.

# emerge --sync && emerge --update gentoo-sources

Workaround (if you’re in a hurry)
Add this to /etc/portage/package.mask

>=x11-drivers/xf86-video-intel-2.14.0

and recompile.

# emerge --update x11-drivers/xf86-video-intel

Don't let updatedb take your Linux down

May 1st

Posted by noisebleed in Linux

2 comments

Coffee break everyone?

Everyday morning was the same: updatedb came and took my Gentoo away. The symptoms were clear, X/KDE applications starting to become slow and unresponsive, and then the two inevitable choices: go for a coffee and wait or pkill the bastard.

Asking updatedb to be nice (the wrong way)

To fix this came to my mind the nice command. This is well known to Gentoo users because of the PORTAGE_NICENESS feature include in make.conf. Nice is a program that adjusts the process scheduling (aka niceness) of the desired programs so setting a value of 19 (the maximum) would make updatedb to be “nicer” to other applications and therefore being less bossy. So I’ve edited /etc/cron.daily/slocate, placed “nice -n 19″ before the updatedb command and waited. But, once again, updatedb came and owned my computer.

Asking updatedb to be I/O-nice (the right way)

So. what’s wrong here? Updatedb is not a CPU-intensive application so nice won’t change a thing. The bottleneck is disk access so what we need here is a nice for I/O. The solution? Ionice.

Ionice is able to set the I/O scheduling class and priority for a given program. To give updatedb a low priority we pick the class 3, the idle one.

Again, let’s go to crontab and edit the slocate entry.

# vim /etc/cron.daily/slocate

Put ionice -c 3 before the updatedb command.

#! /bin/sh

if [ -x /usr/bin/updatedb ]
then
        if [ -f /etc/updatedb.conf ]
        then
                ionice -c 3 /usr/bin/updatedb
        else
                ionice -c 3 /usr/bin/updatedb -f proc
        fi
fi

And if you’re asking where (in Gentoo) is this ionice program, the solution is sys-apps/util-linux, which I’m pretty sure is already installed. If not: emerge -a sys-apps/util-linux.

This is all good but… what’s this updatedb thing?

Updatedb is a tool ran daily by cron to update the slocate database. And Slocate (Secure Locate) is a security enhanced version of the GNU Locate, which is used to index all the files of your system allowing a (very) quick search of them. In Gentoo Linux the slocate is available in Portage through sys-apps/slocate.

tar: file name is too long (max 99)

Feb 27th

Posted by noisebleed in Linux

1 comment

I was doing the usual make dist process to launch a tarball for one of my apps when tar died with the following message:

tar: file name is too long (max 99); not dumped
tar: Error exit delayed from previous errors

If you happen to see the same error message it is quite likely that you (and by you I mean Automake) are using the old V7 tar format.

Just want the solution? It’s here ;)

V7 and other tar formats

By default Automake is pulling the historical V7 format to generate the tarball with make dist. This tar format supports file names only up to 99 characters and that’s why tar is refusing to build the tarball.

Since automake 1.9, th tar format can be chosen with the options tar-v7, tar-ustar, and tar-pax.

This is what the Automake manual says about each option:

  • tar-v7

This is the historical default. This antiquated format is understood by all tar implementations and supports file names with up to 99 characters. When given longer file names some tar implementations will diagnose the problem while other will generate broken tarballs or use non-portable extensions. Furthermore, the V7 format cannot store empty directories.

  • tar-ustar

(…) format defined by POSIX 1003.1-1988. This format is believed to be old enough to be portable. It fully supports empty directories. It can store file names with up to 256 characters, provided that the file name can be split at directory separator in two parts, first of them being at most 155 bytes long. So, in most cases the maximum file name length will be shorter than 256 characters. However you may run against broken tar implementations that incorrectly handle file names longer than 99 characters.

  • tar-pax

(…) the new pax interchange format defined by POSIX 1003.1-2001. It does not limit the length of file names. However, this format is very young and should probably be restricted to packages that target only very modern platforms. There are moves to change the pax format in an upward-compatible way, so this option may refer to a more recent version in the future.

How to fix it?

The solution is to pick a newer and better tar implementation like tar-pax. Go to configure.ac or configure.in and change the AM_INIT_AUTOMAKE macro so it specifies the tar format and requires automake version to be 1.9 or better as tar-pax is only supported since 1.9.

configure.ac/configure.in:

AM_INIT_AUTOMAKE([1.9 tar-pax])

Now run `make dist` again and tar won’t bother you anymore (at least with this error :) ).

, , ,