KDE - Processor is always at full load

[sekhemty]

I retrieved the list from within a Parted Magic LiveCD.

[SteveRiley]

The output of the e2fsck is as follows, it seems pretty useless as it is:

root@PartedMagic:~# e2fsck -cfv /dev/sda

...

My mistake, apologies. e2fsck requires a partition, not just a device. The command should be:

e2fsck -cfv /dev/sda[B]6[/B]

While you're at it, you might as well run that against all other partitions, too.

Then I logged off, deleted the newly created .kde folder and restored the one from the USB key. Now I'm sure that the files don't necessarily reside on the same sectors on the hard drive, and the problem persists, so it must be some wrong configuration file.

It's entirely likely that one or more configuration files at least for some time had the misfortune to land on some bad sectors, meaning that the file(s) in question are now damaged in some way. My suggestion would be to abandon your efforts to parse existing configuration files and find the few broken ones, because this exercise is likely to take more time than to rebuild your system on a new hard drive.

[james147]

The main problem now is to identificate it. Like I said in a previous post, the directory contains hundreds of files, manually trying to rename or remove them one by one would takes a large amount of time.

I'm attaching a zipped text file listing all the content of my .kde folder. Bebause of its lenght I was unable to post as normal post text. [ATTACH]3309[/ATTACH]

Start by renaming ~/.kde/share/config/plasma*rc and ~/.kde/share/config/kwin*rc as they are normally the ones the mess up. If that fails try renaming the ~/.kde/share/config folder to confirm the problem is with the application configs. If it is then you can pick and choose which applications you want to reset, if not you I would try renaming the ~/.kde/share/apps folder... This will at least narrow down the files that could be causing the problem.

[sekhemty]

Here is the result from the e2fsck performed on both sda5 and sda6 partitions.

root@PartedMagic:~# e2fsck -cfv /dev/sda5
e2fsck 1.42 (29-Nov-2011)
Checking for bad blocks (read-only test):   0.00% done, 0:00 elapsed. (0/0/0 err
done                                                 
/dev/sda5: Updating bad block inode.
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information

/dev/sda5: ***** FILE SYSTEM WAS MODIFIED *****

  188814 inodes used (14.74%)
     127 non-contiguous files (0.1%)
     113 non-contiguous directories (0.1%)
         # of inodes with ind/dind/tind blocks: 0/0/0
         Extent depth histogram: 176732/32
 1640487 blocks used (32.04%)
       1 bad block
       1 large file

  156286 regular files
   19237 directories
      57 character device files
      25 block device files
       0 fifos
       3 links
   13199 symbolic links (11959 fast symbolic links)
       1 socket
--------
  188808 files
root@PartedMagic:~# e2fsck -cfv /dev/sda6
e2fsck 1.42 (29-Nov-2011)
Superblock last write time is in the future.
	(by less than a day, probably due to the hardware clock being incorrectly set).  Fix<y>? yes

Checking for bad blocks (read-only test):   0.00% done, 0:00 elapsed. (0/0/0 err
done                                                 
/dev/sda6: Updating bad block inode.
Pass 1: Checking inodes, blocks, and sizes

Running additional passes to resolve blocks claimed by more than one inode...
Pass 1B: Rescanning for multiply-claimed blocks
Multiply-claimed block(s) in inode 5112085: 43502
Pass 1C: Scanning directories for inodes with multiply-claimed blocks
Pass 1D: Reconciling multiply-claimed blocks
(There are 1 inodes containing multiply-claimed blocks.)

File /stefano/.local/share/akonadi/db_data/ibdata1 (inode #5112085, mod time Sat May 19 10:08:11 2012) 
  has 1 multiply-claimed block(s), shared with 1 file(s):
	<The bad blocks inode> (inode #1, mod time Wed May 23 20:57:02 2012)
Clone multiply-claimed blocks<y>? yes

Error reading block 43502 (Attempt to read block from filesystem resulted in short read).
Ignore error<y>? yes

Force rewrite<y>? yes

Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
Free blocks count wrong for group #0 (23513, counted=23512).
Fix<y>? yes

Free blocks count wrong for group #1 (6951, counted=6952).
Fix<y>? yes


/dev/sda6: ***** FILE SYSTEM WAS MODIFIED *****

   38996 inodes used (0.57%)
     579 non-contiguous files (1.5%)
      27 non-contiguous directories (0.1%)
         # of inodes with ind/dind/tind blocks: 0/0/0
         Extent depth histogram: 31172/73
12176476 blocks used (44.26%)
       1 bad block
       1 large file

   29189 regular files
    2027 directories
       0 character device files
       0 block device files
       0 fifos
       0 links
    7770 symbolic links (7742 fast symbolic links)
       1 socket
--------
   38987 files

From what I understand, the problem was a block claimed multiple times. The nice thing is that running that command also solved it, right now I'm writing from the formerly issued system, and everything is perfectly running.

Now, should I consider everything solved, or it is better to perform some other checks and/or fixes?

[SecretCode]

Consider it solved. But make sure you have good (verified) backups, on more than one separate external disk, because you should be doing that anyway!

And it would be a good idea to the smartctl tests I mentioned above (post #26) and the "long" tests in "selective" mode - ranges of LBAs:

sudo smartctl -t select,1-1000000 /dev/sda

takes about 10 seconds on my disk (so it would make sense to do a much larger range at a time; the whole "long" test would I think take up to 3 hours though, on my 500GB disk)

sudo smartctl -t select,next /dev/sda

does the next range, and so on through the drive. You can see the results with

sudo smartctl -l selftest /dev/sda

[sekhemty]

Ok, thanks, I'll perform these tests.

I had to reboot, and now every time I login I get an error window saying "Recovery error - Desktop Shell. Unknown error. Unable to fetch item from backend".

[SteveRiley]

Probably an unrelated bug. See, for example, https://bugs.kde.org/show_bug.cgi?id=292601

[sekhemty]

Ok, then I can mark as solved.

Thanks to everyone!