Mailing List Archive

On Saturday, 1 July 2023 14:06:05 BST Peter Humphrey wrote:
> 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?

...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.

On Sat, Jul 1, 2023 at 6:44?AM Peter Humphrey <peter@prh.myzen.co.uk> wrote:
>
> On Saturday, 1 July 2023 14:06:05 BST Peter Humphrey wrote:
> > 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?
>
> ...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

On Saturday, 1 July 2023 15:02:16 BST Mark Knecht wrote:

> 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.

:-)

--
Regards,
Peter.

On Saturday, 1 July 2023 17:36:59 BST Peter Humphrey wrote:
> On Saturday, 1 July 2023 15:02:16 BST Mark Knecht wrote:
> > 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

--
Regards,
Peter.

On Wednesday, 5 July 2023 14:07:36 BST Peter Humphrey wrote:
> On Saturday, 1 July 2023 17:36:59 BST Peter Humphrey wrote:
> > On Saturday, 1 July 2023 15:02:16 BST Mark Knecht wrote:
> > > 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. :-/


> 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?

On 7/5/23 10:05, Michael wrote:
> On Wednesday, 5 July 2023 14:07:36 BST Peter Humphrey wrote:
>> On Saturday, 1 July 2023 17:36:59 BST Peter Humphrey wrote:
>>> On Saturday, 1 July 2023 15:02:16 BST Mark Knecht wrote:
[snip....]
>> 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.

On Wednesday, 5 July 2023 15:05:28 BST Michael wrote:

> 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.

--
Regards,
Peter.

On Wednesday, 5 July 2023 16:23:01 BST Peter Humphrey wrote:
> On Wednesday, 5 July 2023 15:05:28 BST Michael wrote:
> > 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.

On Wednesday, 5 July 2023 16:38:35 BST Michael wrote:

> 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.

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

> 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.

> 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. ;-)

--
Regards,
Peter.

On 2023-07-05, Peter Humphrey <peter@prh.myzen.co.uk> wrote:

> 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.

> 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

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




Jul 5, 2023, 11:50 by grant.b.edwards@gmail.com:

> On 2023-07-05, Peter Humphrey <peter@prh.myzen.co.uk> wrote:
>
>> 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.
>
>> 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
>

On Wednesday, 5 July 2023 22:46:33 BST mad.scientist.at.large@tutanota.com
wrote:

...>8

> Jul 5, 2023, 11:50 by grant.b.edwards@gmail.com:

I don't have that posting by Grant here.

> > On 2023-07-05, Peter Humphrey <peter@prh.myzen.co.uk> wrote:
> >> 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.

> >> 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.

> > 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.

--
Regards,
Peter.