Thin Clients freezing in Firefox
jam at McQuil.com
Sat Sep 1 04:39:34 BST 2007
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
If you are running 16-bit color (2-bytes) and 1024x768 resolution, then
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
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.
jam at Ltsp.org
More information about the edubuntu-users