[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [K12OSN] Crashing Firefox on terminal in new un-messed with install



Petre,

I think the problem you are running into with the S3 video chipset is caused by the Xserver. In previous versions of LTSP, we included both Xorg AND Xfree86 3.3.6. We kept the older XFree86 around because for some chipsets, including S3 and S3v, the support was better in XFree86 3.3.6 than it was in Xorg. With LTSP-4.2, we've dropped the XFree86 drivers which means you now have to use the Xorg drivers. In a test that I did with an S3, it worked fine with Xorg, but not all S3's were created equal.

Can you try each of the following settings, to see if they work?

  XSERVER = savage
  XSERVER = s3
  XSERVER = s3virge
  XSERVER = vesa

One of those should work for you.

If you get it working, let us know, and we can make modify the vidlist file to make sure that the correct driver automatically gets selected.

Jim McQuillan
jam Ltsp org



Petre Scheie wrote:
I wonder if this explains why one of my quite-reliable-on-4.2.1 clients, a Celeron with on-board S3 video consuming 32MB (out of 768MB total), for which Knoppix uses the XFree86(Savage) X server, breaks with 5.0.0. It boots, and X starts, but the login screen is a bit 'mangled' and the mouse doesn't work, and it's basically dead in the water. I'm not sure if it's a FC5 issue or LTSP.

Petre

Jim McQuillan wrote:
Jim,

LTSP-4.2 has some code in it that limits the amount of memory the X-server
is allowed to use.

Client applications, like firefox are constantly asking the Xserver to
allocate memory, to store things like pixbufs (images) and fonts.

In the past, the xserver would just happily go along and allocate as much
memory as it possibly could, until it uses up ALL memory, and the kernel
would come along and start killing things, to free up some space. Almost
always, the Xserver would get killed, causing you to lose your session.

Now, with the mechanism that we use to tell the Xserver how much memory
it's allowed to allocate, it will stop BEFORE the kernel kills it.

Unfortunately, client applications don't respond very well to the Xserver
refusing to allocate memory.

In LTSP-4.2, we default to allowing the Xserver to grab 90% of the free
memory.  You can tune it by setting 'XRAMPERC = xx', where 'xx' is the
percentage of free memory that you want to allow the Xserver to use.

To restore the old behaviour from pre-4.2, you can set XRAMPERC = 100
and it will allow the Xserver to grab ALL available memory.

THat additional 10% will probably help out quite a bit.

The other thing you can do is increase the amount of available ram, by
either adding more physical ram, OR, enabling swap over NBD.

I'm not sure if Eric is including ltspswapd. If he's not, i'll encourage
him to add it, and probably start it by default.

As for documentation on using swap over NBD, I know Scott Balneaves has
been working on writing something up, but I don't know if he's finished
that.

Hope that looooong explanation helps,

Jim McQuillan
jam Ltsp org

On Fri, April 7, 2006 6:57 pm, Jim Christiansen wrote:

I wish it wasn't Friday afternoon...  I'll miss all of you guys for the
weekend!

I've redone the install on my home test server of the new FC5 with Eric's
new ltsp packages to confirm my troubles.  What happens on a client is
that
when even called by root, Firefox on certain pages (many) will crash with
the following message in a console:

[root christiansens ~]# /opt/firefox/firefox
The program 'firefox-bin' received an X Window System error.
This probably reflects a bug in the program.
The error was 'BadAlloc (insufficient resources for operation)'.
 (Details: serial 42238 error_code 11 request_code 53 minor_code 0)
 (Note to programmers: normally, X errors are reported asynchronously;
  that is, you will receive the error a while after causing it.
  To debug your program, run it with the --sync command line
  option to change this behavior. You can then get a meaningful
  backtrace from your debugger if you break on the gdk_x_error()
function.)

On the server, the same webpage loads. This page is nothing compliated on
many of the crashing pages and this one is served off of my webserver.
The
example crashing page is a large image.  Other pages that crash die so
fast
I don't even know what is on them...

I should have checked on the server to see how how the crashing webpages behaved days ago... This is my third install and I figured I was messing
things up with plugins as all of the libraries may have been mixed up
between 32 and 64 bit versions- but I guess this isn't the case. Firefox dies even without any plugins installed. No Acroread, java or flash...no
audio, xine libs, mplayer plugins... nothing extra.

Any ideas appreciated!!  Fire away  :-)

Thanks,  Jim


_______________________________________________
K12OSN mailing list
K12OSN redhat com
https://www.redhat.com/mailman/listinfo/k12osn
For more info see <http://www.k12os.org>



_______________________________________________
K12OSN mailing list
K12OSN redhat com
https://www.redhat.com/mailman/listinfo/k12osn
For more info see <http://www.k12os.org>



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]