[kde-linux] Re: help, kde 4.6 desktop very very slow

Sat May 7 21:20:39 UTC 2011

Wow, finally found the culprit!

It turned out I had this variable set in my ~/.bashrc

export __GL_FSAA_MODE=7

According to nvidia documentation it should be equivalent to:

nvidia-settings --assign FSAA=7

but it seems it isn't.

After commenting out the offending line my system runs completely smooth.

Thanks!

  Juan Pablo

El día 7 de mayo de 2011 14:41, Juan Pablo Romero Méndez
<jpablo.romero at gmail.com> escribió:
> Thanks for your response Duncan,
>
> The upgrade is not an issue anymore because in a moment of desperation
> I formated the root partition and reinstalled  opensuse.  The version
> of kde shipped with it is 4.6.0.
>
> Also I tried deleting the ~/.kde4 folder and nothing happened.
>
> Deleting ~/.local caused something interesting to occur:   the first
> few seconds after loading the desktop, the system was very responsive
> (I thought the issue was resolved), but after some more seconds the
> problem begun again.
>
> Examining a newly created ~/.local, the only interesting thing I see
> is akonadi's folder in ~/.local/share/akonadi.  Within it there are
> several files and folders that appears to belong to mysql.
>
> Regards,
>
>  Juan Pablo
>
>
> 2011/5/6 Duncan <1i5t5.duncan at cox.net>:
>> Juan Pablo Romero Méndez posted on Fri, 06 May 2011 21:17:43 -0500 as
>> excerpted:
>>
>>> Hello,
>>>
>>> I've just upgraded to opensuse 11.4, which came with kde 4.6
>>>
>>> The problem is that the keyboard input is so slow that renders the
>>> system virtually unusable.
>>>
>>> I've been monitoring the system with top but can't find something
>>> obvious.
>>>
>>> The weird thing is that on another account I made just to test, kde runs
>>> fine. It is something with my account that kde doesn't like.
>>> Perhaps its size (300G), perhaps some config file from another version.
>>>
>>> Also, the linux console works fine.
>>>
>>> What do you guys think?
>>
>> You include some good info, but there's some potentially critical info
>> missing, too.
>>
>> 1)  You say you just upgraded to OpenSuSE 11.4, which comes with KDE 4.6,
>> but you don't mention /which/ 4.6.  There's now 4.6.0, 4.6.1, 4.6.2, and
>> the /just/ released 4.6.3.
>>
>> 2)  What did you upgrade /from/, both distribution-wise and presuming you
>> ran kde on it, what version of kde?
>>
>> Just upgrading from an old kde-3.5.x installation could yield far
>> different results than just upgrading from, say 4.3 or 4.4, which could be
>> rather different than upgrading from 4.5.x, which is different again from
>> upgrading from last month's 4.6.2 to the just released 4.6.3 (the upgrade
>> I just did here, Gentoo, FWIW).
>>
>> 3) *VERY* good thinking trying a test user account, and putting the
>> results in your post! =:^)  That it doesn't occur there does indeed
>> indicate, as you suggested, that it's a user config issue.  The problem is
>> now finding out what/where.  That's where the above info may come in
>> handy, since upgrading from 3.5.x is really quite different indeed from
>> upgrading from 4.5.5, and if an upgrade between 4.6 versions is causing
>> issues, it's quite interesting as those should be bug-fix-only upgrades
>> (not that the 4.6 series has been as smooth as in theory bug-fix-only
>> upgrades should be, there's unfortunately been some notable regressions).
>>
>> Meanwhile, continuing from the new-user test, do you know what bisecting a
>> problem is?  Since we know it's in your user config, that's how I'd
>> approach it.
>>
>> Briefly, the idea behind bisecting is that once you have a known problem
>> space (in this case, your user config), one can iteratively narrow the
>> problem down to successively smaller parts of that problem space, at each
>> iteration figuring out which half of the remaining problem space it's in,
>> until one finds the problem.
>>
>> To shortcut the process by a couple iterations, nearly all kde's config is
>> found in $KDEHOME, normally ~/.kde, or possibly ~/.kde4, depending on
>> distribution.  So that's the config directory we'll assume it's in, and
>> the first step is confirming that.  Without kde running (so from a CLI
>> login or from gnome or whatever), rename your problem user's ~/.kde (or
>> kde4) directory to something like .kde.bak.
>>
>> Now start kde as your problem user.  Is the problem gone?  If so, we've
>> confirmed that the problem is in $KDEHOME.
>>
>> Assuming it is, the next step is to split that in half.  Again taking a
>> shortcut, nearly all kde settings are in the $KDEHOME/share, in one of two
>> subdirs, config or apps.  So again with kde not running, delete the stub
>> $KDEHOME our first test created and copy back all of the dir from the
>> backup BUT $KDEHOME/share/config.
>>
>> Rerun the test.  If the problem is still gone, we know the problem file is
>> one of those in config.  If the problem is there again, we can assume
>> config is fine and that the problem is in one of the apps subdirs, instead.
>> Delete the stub config dir created by the test.
>>
>> If the problem was in config (didn't appear in the test above), copy half
>> the files from the config dir in your backup to the operating location,
>> and retest.
>>
>> If the problem was NOT in config (it did appear in the test above), go
>> ahead and copy all your config files back from the backup, and delete the
>> apps subdir instead.  Retest to confirm that it's in apps.
>>
>> Repeat until you've isolated the problem file.  At this point, you have a
>> choice.  You can either stop, delete that file and reconfigure anything
>> that its settings controlled as necessary, OR switch to a text editor
>> instead of the file manager for testing, and continue, first with sections
>> within the file until you figure out which section it's in, then with
>> individual lines in that section.  FWIW, I like to figure out exactly what
>> has caused me all this hassle, so generally do continue down to the
>> individual line level.  But people with less patience or less
>> customization than I have may be fine stopping at the file level, or even
>> higher, if they decide the hassle of testing further is greater than the
>> hassle of reconfiguring the customizations remaining in whatever number of
>> files will be deleted.
>>
>> For the type of problem you've indicated, a bisect, while being somewhat
>> boring and requiring quite some patience, tends to be very effective,
>> resolving the problem nearly every time.  Unfortunately it doesn't work so
>> well on problems that aren't easily replicated, thus making testing each
>> bisect level far more difficult as you never know for sure whether you're
>> on the good half or if the problem simply hasn't triggered yet.
>> Similarly, if there's two separate causes for the problem, bisecting
>> doesn't work well if at all, because it's difficult to find both of them
>> at once.  So bisecting certainly does have its limits, but for easily
>> replicated problems in a known to be limited problem space and likely
>> having only one cause, as is your case, it tends to work pretty well... as
>> long as you have enough patience to carry thru with the repetitive testing.
>>
>> Good luck! =:^)
>>
>> --
>> Duncan - List replies preferred.   No HTML msgs.
>> "Every nonfree program has a lord, a master --
>> and if you use the program, he is your master."  Richard Stallman
>>
>> ___________________________________________________
>> This message is from the kde-linux mailing list.
>> Account management:  https://mail.kde.org/mailman/listinfo/kde-linux.
>> Archives: http://lists.kde.org/.
>> More info: http://www.kde.org/faq.html.
>