Thin Clients freezing in Firefox

[Jim McQuillan]

Jim Kronebusch wrote:
>> As for more clues, I removed LDM_DIRECTX=True in /opt/ltsp/i386/etc/lts.conf,
>>  and now when the client freezes hard, I can still move the mouse around, but 
>> still have no input.  So before the client would freeze the mouse while 
>> spinning showing the page was loading, now with X over ssh the mouse stops 
>> spinning when the client freezes and still has the ability to move around the 
>> screen.  The only way to fix things is power down the client (either manually 
>> or with the script from Scott), kill the users processes, kill the left over 
>> nbd-server and nbdswap processes, then reboot and all is well until I hit a 
>> very graphic intense website.
> 
> Could I be running out of video memory?  If I switch from the DevonIT 6020p to a
> Diskless Workstations Term150 I can load a little more graphics.  The webpages I posted
> before to test have very large photos.  I can load the page with about 4MB of photos
> with the Term150, it crashes when it loads about half that with the 6020p.  Is there a
> setting in lts.conf I can use to increase how much memory is allocated to video?

That's not something that can be controlled via software.

IF it's possible to change the amount of video memory, it would be in 
the bios of the thin client.

But, I'd be pretty surprised if you are running out of video ram.  If 
anything, you've probably got too much video ram allocated.  If you 
could reduce it to something reasonable, like 4mb, that would leave more 
for the system.


When calculating the amount of video ram needed, as long as you aren't 
running any GL stuff.  The general formula is:

     horizontal resolution * vertical resolution * color-depth-in-bytes 
= ram-needed.

If you are running 16-bit color (2-bytes) and 1024x768 resolution, then 
it's:

    1024 * 768 * 2 = 1,572,864  (a bit more than 1.5mb).

with 4mb of video ram, you could easily do 1600x1200 with 16-bit color.

I'm not sure what the default color depth is for Ubuntu/LTSP.  If it's 
24-bits, try reducing it to 16-bits.  That might help.

Almost always, if you are browsing the web and the terminal locks up, 
it's because the firefox has asked the Xserver to allocate some memory 
to hold bitmaps or fonts, but the thin client doesn't have enough free 
memory to accommodate the request.  The Xserver then locks up and that's 
the end.

If the T150 lasts longer before locking up than the Devon, then it 
probably indicates that the T150 has more usable memory than the Devon.

Enabling swap *should* help.

Adding more physical ram should help even more.

Also, there's a cool program called 'xrestop'.  You can apt-get install 
that and run it.  It's an X app, so you can run it on the server and 
it'll monitor your Xserver on your client.

It is sort of like the 'top' utility, but rather than showing process 
status, it shows resource status within the Xserver.  Of particular 
interest is the column called 'Pxm mem'.  that's the amount of memory 
the Xserver has allocated for pixmaps per X client app.  The total 
pixmap memory is also displayed in the top section.

Try running that AND firefox at the same time, if you can see them both 
on the screen simultaneously, after you've been browsing for a bit and 
the terminal locks up, you should be able to see the last snapshot of 
the resources.  Might tell you exactly what's going on.

Jim McQuillan
jam at Ltsp.org