This problem has just appeared over the last few days. After a while, the KDE desktop will simply lock up and refuse to respond to input. The applications visible will still run and, if you happen to have focus, you can still do things up to (sometimes) pressing buttons, right-clicking or using menus. After a while these actions seem to lock up as well You can still drag windows about via the title bar. However, the toolbar stops reponding and the close button stops working. After about 30-40 seconds, either everything goes back to normal or just locks up even more, eventually requiring me to hard-cycle the power and reboot.
Coupled to this is that ksysguard shows one processor permanently on 100%, despite showing no actual process that is running at anything like that.
Removing the task manager from the toolbar improves things somewhat, as does switching the launcher from the classic menu style to the new sytle.
Things I’ve done:
Switched between the radeon and fglrx drivers (currently using fglrx)
Completely reinstalled 13.2, to remove any weird crud that has built up
Cleared out my .kde4, .kde and .config directories to ensure that I’m not loading something odd
I’m using KDE 4.11.17 and kernel 3.16.7. Basically, I’m as up to date as I can be on a 64 bit system
Posting quickly before the system locks up again …
>
> This problem has just appeared over the last few days. After a while,
> the KDE desktop will simply lock up and refuse to respond to input. The
> applications visible will still run and, if you happen to have focus,
> you can still do things up to (sometimes) pressing buttons,
> right-clicking or using menus. After a while these actions seem to lock
> up as well You can still drag windows about via the title bar. However,
> the toolbar stops reponding and the close button stops working. After
> about 30-40 seconds, either everything goes back to normal or just locks
> up even more, eventually requiring me to hard-cycle the power and
> reboot.
>
> Coupled to this is that ksysguard shows one processor permanently on
> 100%, despite showing no actual process that is running at anything like
> that.
>
> Removing the task manager from the toolbar improves things somewhat, as
> does switching the launcher from the classic menu style to the new
> sytle.
>
> Things I’ve done:
>
> Switched between the radeon and fglrx drivers (currently using fglrx)
> Completely reinstalled 13.2, to remove any weird crud that has built up
> Cleared out my .kde4, .kde and .config directories to ensure that I’m
> not loading something odd
>
> I’m using KDE 4.11.17 and kernel 3.16.7. Basically, I’m as up to date as
> I can be on a 64 bit system
>
> Posting quickly before the system locks up again …
Does it take a long time to boot?
I will bet anything your root is full of snapshots from snapper.
Had this myself, have a look in Yast>snapper and remove some of the older
snapshots.
You can limit how many snapper makes I think I just un-installed the thing
On my machine there was nearly 15 gigs out of 40 in snaps so removed them
all and hey presto machine runs like a dream again.
However I would not recommend getting rid of the last couple just in case
you need to restore the machine.
I do not mind here as it is only a play machine and am going to re-install
later with a better partition scheme and no snapper or btrfs.
HTH
>
>
Mark
Nullus in verba
Caveat emptor
Nil illigitimi carborundum
Some further information. I tried used IceWM. However, it kept on going into sleep mode all the time. (The KDE desktop, once it’s got itself into a knot will also enter sleep mode, as well, sometimes, but not with the enthusiasm of IceWM).
I’ve installed the GNOME desktop and that seems to be working fine and doesn’t have a CPU maxing out.
The CPU temperature is about 55C under KDE and 45C under GNOME.
The system is a Dell M4800 with an AMD FirePro M5100 Mobility Pro graphics card (according to Dell) or a Advanced Micro Devices, Inc. [AMD/ATI] Venus XT [Radeon HD 8870M / R9 M270X] according to lspci
Output from zypper lr -d
| Alias | Name | Enabled | Refresh | Priority | Type | URI | Service
Thanks for the suggestion, but it doesn’t take a long time to boot and, since I did a complete re-install to try and fix things, it’s not very cluttered up by snapper.
>
> baskitcaise;2711148 Wrote:
>> charvolant donned his tin foil hat and penned:
>>
>>
>> Does it take a long time to boot?
>>
>> I will bet anything your root is full of snapshots from snapper.
>>
>>
>
> Thanks for the suggestion, but it doesn’t take a long time to boot and,
> since I did a complete re-install to try and fix things, it’s not very
> cluttered up by snapper.
>
>
Ah well, good job I don’t do the horses
cheers.
–
Mark
Nullus in verba
Caveat emptor
Nil illigitimi carborundum
Well, that’s interesting. I created a new test user, logged in as that user under KDE and everything was just fine. The CPU was normal and everything was reacting with a gazelle-like sprightliness.
This does, however, leave me with a bit of a problem. I reset KDE (or so I thought) before asking for help by removing .kde4, .kde and .config. It looks as if I haven’t properly cleared things out and there’s something else gumming up the works. I don’t particularly want to blow away gigbytes of work and the databases of contact and connection information that I have in firefox and thunderbird for … reasons. So I’m a bit uncomfortable with just zapping everything and starting again.
So my question is, what do I need to do to completely reset KDE without mucking anything else up? Or, is there a tool that will allow me to elegantly migrate to a new user, without leaving a lot of useful information behind?
Create the new test user, make certain it is working as you report, do not bother making any configuration changes.
dd (or use a file backup method of your own preference) the new user’s ~/ directory for backup purposes (you will see why lower down).
Now copy one of the larger directory trees (such as .kde4) from your original user overtop of the same directory in the new user’s location.
Does the problem return? If not, do the same with another ~/ directory (say, .kde).
BUT:
If the problem does come back with one of these copy-overs:
Copy the clean directory from the unadulterated backup you made (this is my “see below”, as I mentioned).
Make sure that fixes the problem. If so, that means you have found the tree containing the problem.
Now (let us use the .kde4 directory as an example) copy one of the .kde4 subdirectories from your original user over top of the corresponding directory in your test user.
Use the same test as above.
Doing this, you can most likely narrow it down to one thing, and you can then work on a solution.
Note also you have to not be running KDE to successfully delete the ~/.kde4 directory since there may be files in use there. ie you can’t change a tire while driving down the road
>
> gogalthorp;2711331 Wrote:
>> Note also you have to not be running KDE to successfully delete the
>> ~/.kde4 directory since there may be files in use there. ie you can’t
>> change a tire while driving down the road
>
> heh, heh.
>
> One should not always assume that someone will instinctively know this
> until they try to remove the first lug nut!rotfl!
>
>
sorry but I will give that a big Yelp also.
These da*n computers are supposed to see/do anything you want ( ha ha ah )
but they still need us nerds to find the bad bits…
All the best.
–
Mark
Nullus in verba
Caveat emptor
Nil illigitimi carborundum
Thanks for all the suggestions. (Yes, I did know to move things around from the console, although the system has a distressing tendency to go into sleep mode if not running an X session.)
Rather than try and debug any further, I’ve just shifted all my data to a new login and then built up the configuration essentials. (Since I’ve got something like 20 years worth of files lying about the place, some tracing back to old solaris systems, trying to work out what’s what was a bit daunting. Just configuring what I need right now is a bit easier) Everything seems to be happy now and I’m letting sleeping dogs lie.
