[sldev] Clients newer than 1.18.0.6 unusable on x86_64
Callum Lerwick
seg at haxxed.com
Mon Sep 3 11:18:58 PDT 2007
Okay, wasted all day yesterday trying to figure this out. 1.18.1.2 and
1.18.3.2 are both completely unusable on my wife's x86_64 laptop (512mb
RAM, Fedora 7, Mobile Radeon 9600, open source r300 DRI). Within minutes
it rapidly eats up all RAM causing severe swap, making SL, and the
entire system for that matter, unusable. Am I the only one seeing this?
I do not see this on i386, neither my laptop (512mb, F7, Intel 830M) or
a similar i386 box (768mb, F7, Radeon 9800SE, open source r300). It
handles what has been my primary test (Walk from Furnation Vista to
Gamma sandboxes, through Alpha) just fine, while only ever using half
its RAM, never touching swap! The x86_64 machine running 1.18.0.6
handles it just fine as well.
Unfortunately, running with massif in an attempt to find where all this
RAM is being used, seems to kill texture decode dead and also seems to
make the r300 driver crash so I don't think I'm getting a valid test run
out of it.
My Fedora package will stay at 1.18.0.6 until this is fixed. Not that
its in the repo yet. ;P Which brings up a related question, what's the
cleanest way to disable the optional update nagbox? I tried to patch it
out, but the startup code is a nightmare and I quickly gave up as it was
taking more work than I wanted to put in to it at the time. A while back
there was some mention of "update channels". I just want the update
checking disabled entirely, we have our own update system. (RPM,
yum-updatesd) Though "this client is not compatible with this grid"
alerts would have to remain.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070903/63e33aa4/attachment.pgp
More information about the SLDev
mailing list