LTSP 5.2 + Debian Squeeze + Firefox crash

[^rooker]

After giving up on a mixed-up-messed-up LTSP4/5 co-existing installation on a Debian Lenny server (updated from Etch), I'm now quite happily installing LTSP 5.2.4-2 on Debian Squeeze (6.0.5).

Here's a good place to start from:
Ubuntu LTSP QuickInstall HowTo

Sound (using pulseaudio) and mounting LocalDevices works properly, but there are some issues, I'll write down about here.

The first one being:
1) Iceweasel crashes when loading site with very large images:

###!!! ABORT: X_CreatePixmap: BadAlloc (insufficient resources for operation); 195 requests ago: file /tmp/buildd/iceweasel-12.0/toolkit/xre/nsX11ErrorHandler.cpp, line 190

I somehow suspect that it might run out of local (=thin client) video RAM - and generally: the local X server isn't using the graphic card correctly.
According to "DRI Troubleshooting" on freedesktop.org, the following command is used to check if the "Direct Rendering Module" (DRM) is loaded in the kernel:

Code: Select all

dmesg | grep drm

In my case, there's a line which doesn't look too promising:

Code: Select all

[drm:r100_cp_init] *ERROR* Failed to load firmware!

Taking a look at the LTSP-client's Xorg.log, shows that direct rendering is off:

(WW) RADEON(0): Direct rendering disabled

Although, according to "lscpi", our Radeon is a "RV100 / 7000(VE)", which should be supported by the free "radeon" xorg driver, it looks like it's trying to load the "R100" firmware - which is provided by proprietary binary-blobs (available in Debian's "non-free" repositories).
So, following the instructions from the "ATI Howto" at the Debian Wiki I've added the "non-free" repositories to "/etc/apt/sources.list" and installed "firmware-linux-nonfree".
This brought the expected firmware in "/lib/firmware/radeon". After rebooting the LTSP client, the "failed to load firmware"-error in dmesg was gone, the R100 firmware loaded properly - and checking Xorg.log, indicates that finally, direct rendering is enabled:

Code: Select all

cat /var/log/Xorg.7.log | grep Direct

returns:

(II) RADEON(0): Direct rendering enabled

Unfortunately, this neither improved the graphics performance: window-dragging still sluggish, and glxgears returns the same FPS (~16) as before

Iceweasel continues to crash, but after some more reading, I'm now quite sure that it's related to Firefox/Iceweasel offloading pixmaps to X11, which exhausts all memory on the thin client and therefore causes the crash...
Some related links:
UbuntuLTSP Troubleshooting: Graphics problems
Thin clients freeze hard when out of RAM
Post by Jos. L on digipedia.org
MOZ_DISABLE_IMAGE_OPTIMIZE=1 environment variable (Firefox 3)

[^rooker]

More links about RAM handling and Firefox-tuning for LTSP:

• UbuntuLTSP/Firefox3Optimize
• UbuntuLTSP/ResolveRamIssues

Links about the problem in Firefox:

• Firefox caches pixmaps to X11, need feature to disable (launchpad.org)
• Firefox caches pixmaps to X11, need feature to disable (bugzilla.mozilla.org)
• Firefox memory management nightmare

[^rooker]

[CONCLUSION]
I've tried 3 different things in order to prevent Firefox (=Iceweasel on Debian) from crashing on sites with large images:

1) Setting the environment variable "MOZ_DISABLE_IMAGE_OPTIMIZE=1":
Copy the following text into "/etc/X11/Xsession.d/10x11-ltsp_environment" (on the LTSP server):

# This should prevent Firefox/Iceweasel from crashing when loading sites with
# large images (pixmap offloading pfui).
# Taken from "https://bugzilla.mozilla.org/show_bug.cgi?id=395260#c10"
export MOZ_DISABLE_IMAGE_OPTIMIZE=1

This will change Firefox' image handling behavior and make it crash less often.

2) Setting "X_RAMPERC":
According to *almost all* informations I've found about "LTSP+Firefox=crash", it's due to RAM being exhausted (physical and swap), because X11's RAM consumption is unlimited.
Setting "X_RAMPERC=80" in "lts.conf" is supposed to change this.
Unfortunately, it seems like this setting has absolutely *no* effect

Interesting though:
The file "/opt/ltsp/i386/usr/share/ltsp/screen-session.d/XS10-xramperc" contains the code to evaluate and handle the "X_RAMPERC" value for the client.
It's shell-script code, and in it there's a calculation for how much Bytes that setting would be in order to set "ulimit -m":

Code: Select all

XMEM=$((${XMEM} * ${X_RAMPERC} / 100))
ulimit -m ${XMEM}

So, I've verified that "X_RAMPERC" is loaded from lts.conf, by running the following command on the client:

Code: Select all

getltscfg -n <client_hostname> -a

and saw that "X_RAMPERC" was set to "80". Ok.
However, running "ulimit -m" returned "unlimited" - which, as I understand it, means that no memory limit was set

3) Enabling NBD swap:
I've enabled nbdswap for the thin clients with 1024 MB swap-space for each thin client. The swap space is allocated and used - but the crashes persist
Somehow it "feels" like it crashes more likely *with* swap enabled than without. But I can't confirm that completely...

All 3 options together produce some sort of improvement, but watching the memory on the thin-client displays interesting things:
Press "Ctrl+Alt+F1" on the thin client for a local console, and then run:

Code: Select all

watch -n 1 -d free

This will display the current memory consumption (physical + swap).
I've then clicked on a link to a problematic large-image site in Iceweasel, quickly changed back to the first terminal (Ctrl+Alt+F1) and watched the memory consumption behavior.

The client crashes as soon as the physical free memory dropped to about 2MB. Swap was used, but only up to about 3MB usage (!) maximum - still almost 1 GB free.

I'm giving up on this one for now, as it puzzles me - and available documentation seems to be misleading.