[gentoo-user] Plasma session saving

[Peter Humphrey]

Hello list,

Plasma and friends were upgraded this week, and since then my sessions are not
being saved. Even KMail's internal settings aren't saved unless I stop it
myself before logging out.

Is this a known problem?

[Mark Knecht]

Post by Peter Humphrey
Hello list,
Plasma and friends were upgraded this week, and since then my sessions

are

Post by Peter Humphrey
not being saved. Even KMail's internal settings aren't saved unless I

stop

Post by Peter Humphrey
it myself before logging out.
Is this a known problem?

...and I've just noticed that KMail's folder list is not in alphabetical
order. Just now I tried setting the order to 'Manul by drag and drop' and
restarting KMail. The order seemed better, but when I set the order back

to

alphabetical it switched the order to the one shown in the attachment.
Weird.
--
Regards,
Peter.

Frustrating I'm sure.

If this is the thing I've run into a few times over the years then the only
way out I've found is to delete my user config files and start over.

As a test, create a new user, log in using KDE and see if that user
saves state the way your account used to. If it does then Google
for the files you need to get rid of and treat your account like a new
user.

HTH,
Mark

[Peter Humphrey]

Post by Mark Knecht
If this is the thing I've run into a few times over the years then the only
way out I've found is to delete my user config files and start over.
As a test, create a new user, log in using KDE and see if that user
saves state the way your account used to. If it does then Google
for the files you need to get rid of and treat your account like a new
user.
HTH,

Well, I'm sure it would have (helped), but I'd just done that, as well as
installing a new system from stage-3. It's on the new system that this is
happening.

:-)

[Peter Humphrey]

Post by Peter Humphrey

Post by Mark Knecht
If this is the thing I've run into a few times over the years then the only
way out I've found is to delete my user config files and start over.
As a test, create a new user, log in using KDE and see if that user
saves state the way your account used to. If it does then Google
for the files you need to get rid of and treat your account like a new
user.
HTH,

Well, I'm sure it would have (helped), but I'd just done that, as well as
installing a new system from stage-3. It's on the new system that this is
happening.

Meanwhile, I got a hardware exception, apparently relating the the system RAM,
so I ran a recent version of memtest86 overnight and found nothing wrong. Time
to start again with a new installation and a new user.

Same problem as before, but now the three instances of gkrellm shimmer around
their edges unless I move them away from the screen corners. I suppose this is
an artefact of GTK2 and its ageing.

Moreover, the two latest versions of Firefox do not show as they should.
There's no upper frame, the min/max/stop buttons appearing in the tab bar
instead - in the wrong decoration style: I have the Plastik scheme set, but
the buttons are shown in something similar to the Breeze scheme. And middle-
click and right-click on the maximise button have no effect.

I can't find anything here to explain my problems, so I've raised https://
bugs.kde.org/show_bug.cgi?id=471977

[Michael]

Post by Peter Humphrey

Post by Peter Humphrey

Post by Mark Knecht
If this is the thing I've run into a few times over the years then the only
way out I've found is to delete my user config files and start over.
As a test, create a new user, log in using KDE and see if that user
saves state the way your account used to. If it does then Google
for the files you need to get rid of and treat your account like a new
user.
HTH,

Well, I'm sure it would have (helped), but I'd just done that, as well as
installing a new system from stage-3. It's on the new system that this is
happening.

Meanwhile, I got a hardware exception, apparently relating the the system
RAM, so I ran a recent version of memtest86 overnight and found nothing
wrong. Time to start again with a new installation and a new user.
Same problem as before, but now the three instances of gkrellm shimmer
around their edges unless I move them away from the screen corners. I
suppose this is an artefact of GTK2 and its ageing.

I noticed the same flicker with the GKrellms window border, when I run an app
which uses graphics hardware acceleration. Rolling over to another virtual
desktop and back stops this gkrellm window border flicker. I'm using Plasma
on Wayland, so I wasn't sure what the cause of this is: code rot in GKrellms,
buggy Wayland, or my ancient graphics hardware. :-/

Post by Peter Humphrey
Moreover, the two latest versions of Firefox do not show as they should.
There's no upper frame, the min/max/stop buttons appearing in the tab bar
instead - in the wrong decoration style: I have the Plastik scheme set, but
the buttons are shown in something similar to the Breeze scheme. And middle-
click and right-click on the maximise button have no effect.
I can't find anything here to explain my problems, so I've raised https://
bugs.kde.org/show_bug.cgi?id=471977

Did you try to reseat your graphics card and your RAM sticks, just in case
their electrical contacts got oxidised?

[Jack]

[snip....]

Post by Michael

Post by Peter Humphrey
Same problem as before, but now the three instances of gkrellm shimmer
around their edges unless I move them away from the screen corners. I
suppose this is an artefact of GTK2 and its ageing.

I noticed the same flicker with the GKrellms window border, when I run an app
which uses graphics hardware acceleration. Rolling over to another virtual
desktop and back stops this gkrellm window border flicker. I'm using Plasma
on Wayland, so I wasn't sure what the cause of this is: code rot in GKrellms,
buggy Wayland, or my ancient graphics hardware. :-/

I've also noticed this with gkrellm on Plasma, but only on Wayland, not
on xorg.  I haven't paid any specific attention to the circumstances.

[Peter Humphrey]

Post by Michael
Did you try to reseat your graphics card and your RAM sticks, just in case
their electrical contacts got oxidised?

Not yet. I was hoping to avoid that because of difficulty of access.

[Michael]

Post by Peter Humphrey

Post by Michael
Did you try to reseat your graphics card and your RAM sticks, just in case
their electrical contacts got oxidised?

Not yet. I was hoping to avoid that because of difficulty of access.

Hmm ... you won't like what I have to say now about bad RAM:

Servers and specialised workstations with large amounts of RAM use RDIMM ECC
to correct errors. With modern PCs having even more RAM than some servers, it
can take forever to test them thoroughly using memtest86+. Perhaps if you
remove all but one stick and test it overnight, then replace this with the
next stick and so on until all are tested, you may find the problematic stick
sooner. Or, carry on as you are and keep an eye out for errors. A heavy
round of emerge can be as likely to come across it sooner or later. The other
culprit to consider is a power supply problem, especially if this is not a
laptop or a PC fed off a UPS. A transient glitch could cause an one off error
and you wouldn't even notice it.

[Peter Humphrey]

:)

Post by Michael
Servers and specialised workstations with large amounts of RAM use RDIMM ECC
to correct errors. With modern PCs having even more RAM than some servers,
it can take forever to test them thoroughly using memtest86+. Perhaps if
you remove all but one stick and test it overnight, then replace this with
the next stick and so on until all are tested, you may find the problematic
stick sooner.

This version of memtest86 ran to completion after going through the whole
64GB, and stopped with a success message.

Post by Michael
Or, carry on as you are and keep an eye out for errors. A heavy round of
emerge can be as likely to come across it sooner or later.

Over the last...oh, many months, I've noticed an occasional package in a large
batch failing for no obvious reason, only to succeed on its own. I haven't
been able to diagnose this, but it's one factor behind my trying to find the
best settings of jobs and load average, on the suspicion that job control is
weaker at high loads.

Post by Michael
The other culprit to consider is a power supply problem, especially if this
is not a laptop or a PC fed off a UPS. A transient glitch could cause an
one off error and you wouldn't even notice it.

I do run a UPS. Just as well, too, as the village is fed over-ground and we
get one or two brief blackouts every year. They're odd, because they last
longer than delayed auto-reclose but shorter than I would expect manual
switching to take (I used to work in that industry). Maybe the operators are
quicker on their feet these days - it was a long time ago. ;-)

[Grant Edwards]

Post by Peter Humphrey
This version of memtest86 ran to completion after going through the whole
64GB, and stopped with a success message.

That's a pretty good sign, but I have seen memory that made it through
one complete test pass and failed on subsequent ones.

Post by Peter Humphrey
Over the last...oh, many months, I've noticed an occasional package in a large
batch failing for no obvious reason, only to succeed on its own.

What sort of failure? I've found that inconsistent/random gcc
internal errors or gcc segfaults have usually been due to failing
RAM. [Though in one case I remember, it was due to a failing SCSI disc
controller card -- back when that was a thing.]

It might also be due to a failing disk, but there are usually good
indications of that in dmesg output and in SMART logs before it starts
to affect other things.

--
Grant

[m***@tutanota.com]

It could also indicate a problem with the power supply failing.  I've seen this a number of times and it often manifest as memory errors when testing the ram.  

Any number of things in the computer can fail in ways that may not be so obvious.  Substitution trouble shooting may be needed, i.e. try a known good power supply with known good memory, or take half the ram out to see if the problem persist, then check the other half of the ram.

It'd also a good also worth pulling and reseating the ram and any cards in it.  I've got a big huger server that was having issues, it has a removable drawer for the cpu/memory, I pulled it out about 1/2 inch and reseated it and the errors stopped.  That was a couple of months ago.  Also probably a good idea to reseat the cpu as well.  Finally, you should also check the fans/dustiness of the computer in question, both of which can produce higher temps and random behavior.

And yes, it's a pain to properly test large amounts of ram, especially if you don't have a backup machine to work on while the other is testing.


--"Fascism begins the moment a ruling class, fearing the people may use their political democracy to gain economic democracy, begins to destroy political democracy in order to retain its power of exploitation and special privilege." Tommy Douglas

Post by Grant Edwards

Post by Peter Humphrey
This version of memtest86 ran to completion after going through the whole
64GB, and stopped with a success message.

That's a pretty good sign, but I have seen memory that made it through
one complete test pass and failed on subsequent ones.

Post by Peter Humphrey
Over the last...oh, many months, I've noticed an occasional package in a large
batch failing for no obvious reason, only to succeed on its own.

What sort of failure? I've found that inconsistent/random gcc
internal errors or gcc segfaults have usually been due to failing
RAM. [Though in one case I remember, it was due to a failing SCSI disc
controller card -- back when that was a thing.]
It might also be due to a failing disk, but there are usually good
indications of that in dmesg output and in SMART logs before it starts
to affect other things.
--
Grant

[Peter Humphrey]

On Wednesday, 5 July 2023 22:46:33 BST ***@tutanota.com
wrote:

...>8
I don't have that posting by Grant here.

Post by Grant Edwards

Post by Peter Humphrey
This version of memtest86 ran to completion after going through the whole
64GB, and stopped with a success message.

That's a pretty good sign, but I have seen memory that made it through
one complete test pass and failed on subsequent ones.

So I ran another test last night, with the same result.

In fact, I can't remember ever having a memory problem exposed by a memory
test.

Post by Grant Edwards

Post by Peter Humphrey
Over the last...oh, many months, I've noticed an occasional package in a
large batch failing for no obvious reason, only to succeed on its own.

What sort of failure? I've found that inconsistent/random gcc
internal errors or gcc segfaults have usually been due to failing
RAM. [Though in one case I remember, it was due to a failing SCSI disc
controller card -- back when that was a thing.]

Various minor things, such as some component not being found.

Post by Grant Edwards
It might also be due to a failing disk, but there are usually good
indications of that in dmesg output and in SMART logs before it starts
to affect other things.

Hm. I'll have a look around the various tools.

Thanks for the ideas.