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

Sat Apr 8 14:49:40 UTC 2006

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 at 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 at 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 at 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 at redhat.com
>>> https://www.redhat.com/mailman/listinfo/k12osn
>>> For more info see <http://www.k12os.org>
>>>
>>
>>
>> _______________________________________________
>> K12OSN mailing list
>> K12OSN at redhat.com
>> https://www.redhat.com/mailman/listinfo/k12osn
>> For more info see <http://www.k12os.org>
>>