I thought I had solved my problem with Gnome desktop freezes, rcs0 hang,
and such but it came back though much diminished when using a test user account.

Not wanting to move all my configured functionality in $HOME to tester, I tried logging in as tester, loading the desktop, and then from a
terminal window using
su - mylogin and then launching the program I wanted to use,
to try for limited functionality. My idea was to enable a gradual
conversion to the new user when I had time and eventually changing the
user name to restore things to my accustomed setup.

The su - approach worked so well I thought about reporting my kludge on Mageia's bugzilla, as the rcs0 and GPU problem seem to exist for others,
and found a bug 25930 that seems to be my problem.

I posted a few paragraphs on my experience and current status.

The root problem appears to be the intel i915 driver, from the 5.3.13
kernel onward, with some fixes included in later kernel updates but
problems still remaining.

Cheers!

jim b.

--
UNIX is not user-unfriendly, it merely
expects users to be computer-friendly.

--- MBSE BBS v1.0.7.13 (GNU/Linux-x86_64)
* Origin: A noiseless patient Spider (2:250/0@fidonet)

On 1/20/20 10:41 AM, Jim Beard wrote:

I thought I had solved my problem with Gnome desktop freezes, rcs0 hang,
and such but it came back though much diminished when using a test user account.

Not wanting to move all my configured functionality in $HOME to tester, I tried logging in as tester, loading the desktop, and then from a
terminal window using
su - mylogin and then launching the program I wanted to use,
to try for limited functionality. My idea was to enable a gradual
conversion to the new user when I had time and eventually changing the
user name to restore things to my accustomed setup.

The su - approach worked so well I thought about reporting my kludge on Mageia's bugzilla, as the rcs0 and GPU problem seem to exist for others,
and found a bug 25930 that seems to be my problem.

I posted a few paragraphs on my experience and current status.

The root problem appears to be the intel i915 driver, from the 5.3.13
kernel onward, with some fixes included in later kernel updates but
problems still remaining.

Cheers!

jim b.

There's been a discussion about this on the QA mailing list in the last
few days. Apparently, it doesn't affect all hardware that uses the i915 driver. For example, I have three systems under my care that use that
driver, with varying hardware, and none have shown any symptoms - yet.

And, of course, that makes it all the more difficult to find a fix.

TJ

--- MBSE BBS v1.0.7.13 (GNU/Linux-x86_64)
* Origin: A noiseless patient Spider (2:250/0@fidonet)

On 2020-02-06, TJ <TJ@noneofyour.business> wrote:

On 1/20/20 10:41 AM, Jim Beard wrote:

I thought I had solved my problem with Gnome desktop freezes, rcs0 hang,
and such but it came back though much diminished when using a test user
account.

Not wanting to move all my configured functionality in $HOME to tester, I
tried logging in as tester, loading the desktop, and then from a
terminal window using
su - mylogin and then launching the program I wanted to use,
to try for limited functionality. My idea was to enable a gradual
conversion to the new user when I had time and eventually changing the
user name to restore things to my accustomed setup.

The su - approach worked so well I thought about reporting my kludge on
Mageia's bugzilla, as the rcs0 and GPU problem seem to exist for others,
and found a bug 25930 that seems to be my problem.

I posted a few paragraphs on my experience and current status.

The root problem appears to be the intel i915 driver, from the 5.3.13
kernel onward, with some fixes included in later kernel updates but
problems still remaining.

Cheers!

jim b.

There's been a discussion about this on the QA mailing list in the last
few days. Apparently, it doesn't affect all hardware that uses the i915 driver. For example, I have three systems under my care that use that driver, with varying hardware, and none have shown any symptoms - yet.

And, of course, that makes it all the more difficult to find a fix.

Hmm. I have also been having weird hangs and
partial hangs ( ie it revied after a while) on my Mga7 systems (and yes
they do use the Intel drivers). The screen will suddenly freeze, with
neither screen nor keyboard responding. Have not spent sufficient time
to try to track the problem down-- usualy have things to do and a reboot
will bring it back up.

TJ

--- MBSE BBS v1.0.7.13 (GNU/Linux-x86_64)
* Origin: A noiseless patient Spider (2:250/0@fidonet)

On Thu, 06 Feb 2020 17:59:45 +0000, William Unruh wrote:

On 2020-02-06, TJ <TJ@noneofyour.business> wrote:

On 1/20/20 10:41 AM, Jim Beard wrote:

I thought I had solved my problem with Gnome desktop freezes, rcs0
hang, and such but it came back though much diminished when using a
test user account.

Not wanting to move all my configured functionality in $HOME to
tester, I tried logging in as tester, loading the desktop, and then
from a terminal window using su - mylogin and then launching the
program I wanted to use,
to try for limited functionality. My idea was to enable a gradual
conversion to the new user when I had time and eventually changing the
user name to restore things to my accustomed setup.

The su - approach worked so well I thought about reporting my kludge
on Mageia's bugzilla, as the rcs0 and GPU problem seem to exist for
others, and found a bug 25930 that seems to be my problem.

I posted a few paragraphs on my experience and current status.

The root problem appears to be the intel i915 driver, from the 5.3.13
kernel onward, with some fixes included in later kernel updates but
problems still remaining.

Cheers!

jim b.

There's been a discussion about this on the QA mailing list in the last
few days. Apparently, it doesn't affect all hardware that uses the i915
driver. For example, I have three systems under my care that use that
driver, with varying hardware, and none have shown any symptoms - yet.

And, of course, that makes it all the more difficult to find a fix.

Hmm. I have also been having weird hangs and partial hangs ( ie it
revied after a while) on my Mga7 systems (and yes they do use the Intel drivers). The screen will suddenly freeze, with neither screen nor
keyboard responding. Have not spent sufficient time to try to track the problem down-- usualy have things to do and a reboot will bring it back
up.

The problems seem to be multiple. The rcs0 problem is my major
affliction, but there was a chromium channel or some such that failed as
well. Problems usually arise when I have more than one browser in use
(for me, frequently) but using only one browser at a time does not keep problems from arising. I have not seen the failing channel since the
5.4.17 kernel was installed.

Not only the computer system itself but the keyboard and mouse used seem
to differ in frequency and severety of the problem. A Logitech plain-
vanilla keyboard seems to work most reliably, with a Logitech Internet
350 and optical wheel mouse generally ok. My Unicomp Model M with a
built-in trackball is prone to troubles. My main machine frequently
crashes when I use it, though a less capable system rarely has a problem.

The rcs0 hang will now time out usually after a minute or so, but knock-
on problems may or may not allow recovery by killing browsers in use,
logging out, or using cntl-alt-backspace to kill the Gnome desktop. In
some cases, only a reboot will clear the problem, and in a subset of
those cases multiple reboots are necessary to enable me to change to
another kernel or actually get a working system again. When trying to
reboot, the old cntl-prtscrn-e will sometimes kill the desktop, which may
or may not allow getting to tty2 or shutdown. Rarely, even ctl-prtscn- [rseiub] sequence will not work and a warm reboot may not allow choosing
which kernel to boot into, with the resulting kernel refusing to allow me
to log in. Power-off reboot two times in a row has always worked, to
date.

Using ssh from a remote machine and killing processes on the bolloxed
machine has proved useful for a least one user with a system afflicted
with the problem.

The usb port or controller may be involved, and likewise maybe the video controller or monitor, or perhaps they simply increase the frequency or intensity of any problems.

Changing settings for the keyboard and the mouse (or trackball) seem to
affect frequency of problems, and disconnecting and reconnecting the usb connection will sometimes clear a problem and allow killing the desktop, logging out, or getting to tty2 to kill processes.

With the recent 5.4.17, my main machine seem to work with few problems
when it has the Logitech keyboard and mouse, but is basically unusable if
I remove those and plug in the Model M and trackball. My backup machine
seems to be work with few problems using the Model M and trackball.

The 5.3.11 kernel works reliably no matter which machine or which
keyboard and mouse or trackball is attached.

Cheers!

jim b.

--
UNIX is not user-unfriendly, it merely expects users to be computer-
friendly.





--
UNIX is not user-unfriendly, it merely expects users to be computer-
friendly.





--
UNIX is not user-unfriendly, it merely expects users to be computer-
friendly.

--- MBSE BBS v1.0.7.13 (GNU/Linux-x86_64)
* Origin: A noiseless patient Spider (2:250/0@fidonet)

On 2020-02-07, Jim Beard <jim.beard@verizon.net> wrote:

On Thu, 06 Feb 2020 17:59:45 +0000, William Unruh wrote:

On 2020-02-06, TJ <TJ@noneofyour.business> wrote:

On 1/20/20 10:41 AM, Jim Beard wrote:

I thought I had solved my problem with Gnome desktop freezes, rcs0
hang, and such but it came back though much diminished when using a
test user account.

Not wanting to move all my configured functionality in $HOME to
tester, I tried logging in as tester, loading the desktop, and then
from a terminal window using su - mylogin and then launching the
program I wanted to use,
to try for limited functionality. My idea was to enable a gradual
conversion to the new user when I had time and eventually changing the >>>> user name to restore things to my accustomed setup.

The su - approach worked so well I thought about reporting my kludge
on Mageia's bugzilla, as the rcs0 and GPU problem seem to exist for
others, and found a bug 25930 that seems to be my problem.

I posted a few paragraphs on my experience and current status.

The root problem appears to be the intel i915 driver, from the 5.3.13
kernel onward, with some fixes included in later kernel updates but
problems still remaining.

Cheers!

jim b.

There's been a discussion about this on the QA mailing list in the last
few days. Apparently, it doesn't affect all hardware that uses the i915
driver. For example, I have three systems under my care that use that
driver, with varying hardware, and none have shown any symptoms - yet.

And, of course, that makes it all the more difficult to find a fix.

Hmm. I have also been having weird hangs and partial hangs ( ie it
revied after a while) on my Mga7 systems (and yes they do use the Intel
drivers). The screen will suddenly freeze, with neither screen nor
keyboard responding. Have not spent sufficient time to try to track the
problem down-- usualy have things to do and a reboot will bring it back
up.

The problems seem to be multiple. The rcs0 problem is my major

Not sure what "rsc0 problem" means. HOw does on determing that it is
that problem?

affliction, but there was a chromium channel or some such that failed as well. Problems usually arise when I have more than one browser in use
(for me, frequently) but using only one browser at a time does not keep

For me have gotten freezes running Chrome, or running libreoffice and a
browser open as well, and other situations which I cannot remember what
the situation was. It did seem to correlate with browsers/office work I
was doing.

problems from arising. I have not seen the failing channel since the
5.4.17 kernel was installed.

It is rare enough that I do not have any idea of what the correlation
with kernel was.

Not only the computer system itself but the keyboard and mouse used seem
to differ in frequency and severety of the problem. A Logitech plain- vanilla keyboard seems to work most reliably, with a Logitech Internet
350 and optical wheel mouse generally ok. My Unicomp Model M with a built-in trackball is prone to troubles. My main machine frequently
crashes when I use it, though a less capable system rarely has a problem.

The rcs0 hang will now time out usually after a minute or so, but knock-
on problems may or may not allow recovery by killing browsers in use, logging out, or using cntl-alt-backspace to kill the Gnome desktop. In
some cases, only a reboot will clear the problem, and in a subset of
those cases multiple reboots are necessary to enable me to change to
another kernel or actually get a working system again. When trying to reboot, the old cntl-prtscrn-e will sometimes kill the desktop, which may
or may not allow getting to tty2 or shutdown. Rarely, even ctl-prtscn- [rseiub] sequence will not work and a warm reboot may not allow choosing which kernel to boot into, with the resulting kernel refusing to allow me
to log in. Power-off reboot two times in a row has always worked, to
date.

Using ssh from a remote machine and killing processes on the bolloxed machine has proved useful for a least one user with a system afflicted
with the problem.

The usb port or controller may be involved, and likewise maybe the video controller or monitor, or perhaps they simply increase the frequency or intensity of any problems.

Changing settings for the keyboard and the mouse (or trackball) seem to affect frequency of problems, and disconnecting and reconnecting the usb connection will sometimes clear a problem and allow killing the desktop, logging out, or getting to tty2 to kill processes.

With the recent 5.4.17, my main machine seem to work with few problems
when it has the Logitech keyboard and mouse, but is basically unusable if
I remove those and plug in the Model M and trackball. My backup machine seems to be work with few problems using the Model M and trackball.

The 5.3.11 kernel works reliably no matter which machine or which
keyboard and mouse or trackball is attached.

My current kernel on one occasionally problematic machine was 5.1.4
and on my laptop, 5.4.6

Cheers!

jim b.

--
UNIX is not user-unfriendly, it merely expects users to be computer- friendly.

--
UNIX is not user-unfriendly, it merely expects users to be computer- friendly.

--- MBSE BBS v1.0.7.13 (GNU/Linux-x86_64)
* Origin: A noiseless patient Spider (2:250/0@fidonet)

On Mon, 20 Jan 2020 15:41:55 -0000 (UTC), Jim Beard wrote:

I thought I had solved my problem with Gnome desktop freezes, rcs0 hang,
and such but it came back though much diminished when using a test user account.

You might want to consider enabling core dumps, just to verify something
is not crashing.

Do keep in mind that a normal shutdown or reboot may cause a DM core dump.

Here is a quick untested kludge of a write up. If it does not work, start
a new thread about enabling core dumps, and let's see where it goes wrong.

#*********** start of enable_coredump.txt ****************************
# following are instructions for enabling core dumps.
#
# "ulimit -c unlimited" has to executed during login either by
# each user in $HOME/.bash_profile or $HOME/.bashrc or globally
# for everyone. The following is globally.

# As root, paste the following in a root terminal:

echo '#!/bin/bash
# Enable core dump for each user
ulimit -c unlimited
#***** end of /etc/profile.d/xx_enable_coredump.sh
' > /etc/profile.d/xx_enable_coredump.sh

chmod +x /etc/profile.d/xx_enable_coredump.sh

#****************************************************************
# you need to make sysctl changes, as root, paste the following: #****************************************************************

mkdir --parents /etc/sysctl.d/

echo '#**** start of /etc/sysctl.d/xx_enable_coredump.conf
# enable System Request debugging functionality of the kernel
kernel.sysrq = 1

# Enabling suid dump PID appending and set core location and name

kernel.core_uses_pid = 1
kernel.core_pattern = /var/tmp/%e_%p_%s.core
fs.suid_dumpable = 2

#********* end of /etc/sysctl.d/xx_enable_coredump.conf *********
' > /etc/sysctl.d/xx_enable_coredump.conf

#***********************************************
# reload all sysctl changes with the following: #***********************************************

sysctl -a

#**************************************************
# add any/all users to the systemd-coredump group #**************************************************

usermod --append --groups systemd-coredump each_user_id_here

#********************************************************
# users have to log out/in to pick up the new group.
# verify user can create a core dump, in a user terminal #********************************************************

firefox &
pkill --signal SIGSEGV --full firefox
ls -Al /var/tmp/

#*******************************************************************
# When a user launches a terminal, $HOME/.bashrc is normally executed.
# I can recommend adding a command to check for core files. I also have
# a hourly cron job to warn about core files. #*******************************************************************

------8<------8<------8<--cut below this line ----8<------8<
#!/bin/bash
#********************* start ck_4_core *******************************

for _d in $HOME /tmp /var/tmp /var/lib/systemd/coredump ; do
_cnt=$(ls $_d/*core* 2> /dev/null | wc -l)
if [ $_cnt -gt 0 ] ; then
echo " "
ls -la $_d/*core*
echo "
# from $(hostname --short) ck_4_core
# There is a $_d/*core file. To remove it, run
rm --force $_d/*core*
"
fi
done

#*************** end ck_4_core **************************************** ------8<------8<------8<--cut above this line ----8<------8<

Do remember to set execute bit on ck_4_core.
chmod +x ck_4_core



#*********** end of enable_coredump.txt ******************************

--- MBSE BBS v1.0.7.13 (GNU/Linux-x86_64)
* Origin: A noiseless patient Spider (2:250/0@fidonet)

On Fri, 07 Feb 2020 04:58:36 -0600, Bit Twister wrote:

On Mon, 20 Jan 2020 15:41:55 -0000 (UTC), Jim Beard wrote:

I thought I had solved my problem with Gnome desktop freezes, rcs0
hang,
and such but it came back though much diminished when using a test user
account.

You might want to consider enabling core dumps, just to verify something
is not crashing.

Do keep in mind that a normal shutdown or reboot may cause a DM core
dump.

Core dumps enabled, using your scripts except the check for cores. I
will do that manually for the moment.

The test using firefox does indeed dump a core into /var/tmp. I have
rebooted for a fresh clean start.

I am currently using my main machine with the Model M keyboard+trackball,
and obviously (to me) it has not yet frozen.

My speculation is that enabling core dumps will change the timing on
whatever is causing the desktop to freeze, just as enabling debuggery
will change race conditions so they are not a problem.

Be that as it may, I will report back, sooner if freezes continue and
later if they do not.

Cheers!

jim b.

--
UNIX is not user-unfriendly, it merely expects users to be computer-
friendly.

--- MBSE BBS v1.0.7.13 (GNU/Linux-x86_64)
* Origin: A noiseless patient Spider (2:250/0@fidonet)

On Fri, 07 Feb 2020 17:47:37 +0000, Jim Beard wrote:

On Fri, 07 Feb 2020 04:58:36 -0600, Bit Twister wrote:

On Mon, 20 Jan 2020 15:41:55 -0000 (UTC), Jim Beard wrote:

I thought I had solved my problem with Gnome desktop freezes, rcs0
hang,
and such but it came back though much diminished when using a test
user account.

You might want to consider enabling core dumps, just to verify
something is not crashing.

Do keep in mind that a normal shutdown or reboot may cause a DM core
dump.

Core dumps enabled, using your scripts except the check for cores. I
will do that manually for the moment.

The test using firefox does indeed dump a core into /var/tmp. I have rebooted for a fresh clean start.

I am currently using my main machine with the Model M
keyboard+trackball,
and obviously (to me) it has not yet frozen.

My speculation is that enabling core dumps will change the timing on
whatever is causing the desktop to freeze, just as enabling debuggery
will change race conditions so they are not a problem.

Be that as it may, I will report back, sooner if freezes continue and
later if they do not.

Logged out, logged in, started Gnome desktop, and fired up Opera.
Went to the wall street journal journal website, chose the section I
wanted to go to, and attempted to log in.

Crashed to a blank screen.

Tried cntl-alt-f12, and found multiples of Receiver for unknown channel- associated interface: chrome.mojom.Bouncer and of i915 Resetting rcs0 for
hang on rcs0.

The test core from firefox an hour ago is in place, in /var/tmp, along
with ThreadPoolSingl_6881_4.core.

Alt-prtscrn-e worked (sometimes it does nothing) and I have been able to
log out and log back in again, restart Gnome desktop, and write up and
send this.

Cheers!

jim.beard

--
UNIX is not user-unfriendly, it merely expects users to be computer-
friendly.

--- MBSE BBS v1.0.7.13 (GNU/Linux-x86_64)
* Origin: A noiseless patient Spider (2:250/0@fidonet)

On 2/7/20 1:36 PM, Jim Beard wrote:

On Fri, 07 Feb 2020 17:47:37 +0000, Jim Beard wrote:

On Fri, 07 Feb 2020 04:58:36 -0600, Bit Twister wrote:

On Mon, 20 Jan 2020 15:41:55 -0000 (UTC), Jim Beard wrote:

I thought I had solved my problem with Gnome desktop freezes, rcs0
hang,
and such but it came back though much diminished when using a test
user account.

You might want to consider enabling core dumps, just to verify
something is not crashing.

Do keep in mind that a normal shutdown or reboot may cause a DM core
dump.

Core dumps enabled, using your scripts except the check for cores. I
will do that manually for the moment.

The test using firefox does indeed dump a core into /var/tmp. I have
rebooted for a fresh clean start.

I am currently using my main machine with the Model M
keyboard+trackball,
and obviously (to me) it has not yet frozen.

My speculation is that enabling core dumps will change the timing on
whatever is causing the desktop to freeze, just as enabling debuggery
will change race conditions so they are not a problem.

Be that as it may, I will report back, sooner if freezes continue and
later if they do not.

Logged out, logged in, started Gnome desktop, and fired up Opera.
Went to the wall street journal journal website, chose the section I
wanted to go to, and attempted to log in.

Crashed to a blank screen.

Tried cntl-alt-f12, and found multiples of Receiver for unknown channel- associated interface: chrome.mojom.Bouncer and of i915 Resetting rcs0 for hang on rcs0.

The test core from firefox an hour ago is in place, in /var/tmp, along
with ThreadPoolSingl_6881_4.core.

Alt-prtscrn-e worked (sometimes it does nothing) and I have been able to
log out and log back in again, restart Gnome desktop, and write up and
send this.

Cheers!

jim.beard

If you come up with any information you think may be helpful, please do
add to the comments at https://bugs.mageia.org/show_bug.cgi?id=25930.

The more information available to those working on the problem, the more likely they are to find something in common among those affected.

TJ

--- MBSE BBS v1.0.7.13 (GNU/Linux-x86_64)
* Origin: A noiseless patient Spider (2:250/0@fidonet)

On Fri, 7 Feb 2020 18:36:00 -0000 (UTC), Jim Beard wrote:

Logged out, logged in, started Gnome desktop, and fired up Opera.
Went to the wall street journal journal website, chose the section I
wanted to go to, and attempted to log in.

Crashed to a blank screen.

Tried cntl-alt-f12, and found multiples of Receiver for unknown channel- associated interface: chrome.mojom.Bouncer and of i915 Resetting rcs0 for hang on rcs0.

The test core from firefox an hour ago is in place, in /var/tmp,

That is normal because /var/tmp remains across boots.
You should remove the firefox core so as to not mislead anyone.

along with ThreadPoolSingl_6881_4.core.

ThreadPoolSingl is the app that crashed an caused .core creation.


--- MBSE BBS v1.0.7.13 (GNU/Linux-x86_64)
* Origin: A noiseless patient Spider (2:250/0@fidonet)

On Sat, 08 Feb 2020 10:01:18 -0600, Bit Twister wrote:

On Fri, 7 Feb 2020 18:36:00 -0000 (UTC), Jim Beard wrote:

Logged out, logged in, started Gnome desktop, and fired up Opera.
Went to the wall street journal journal website, chose the section I
wanted to go to, and attempted to log in.

Crashed to a blank screen.

Tried cntl-alt-f12, and found multiples of Receiver for unknown
channel- associated interface: chrome.mojom.Bouncer and of i915
Resetting rcs0 for hang on rcs0.

The test core from firefox an hour ago is in place, in /var/tmp,

That is normal because /var/tmp remains across boots.
You should remove the firefox core so as to not mislead anyone.

along with ThreadPoolSingl_6881_4.core.

ThreadPoolSingl is the app that crashed an caused .core creation.

The firefox core has been removed. There is a
BatteryStatusNo_22387_4.core from yesterday, and a
gnome-shell_2082_11.core from this morning.

Are these worth keeping?

Separately,for TJ, is the sort of information in my post yesterday of any
use? I can detail what machine is crashing, under what user-
circumstances (usually multiple browsers), and that my Unicomp Model M keyboard continues to work on my back up machine but my main machine
crashes frequently when I put it there.

I can ssh from my backup machine using the Model M. Then, from a
terminal window, I can run pan& and evolution& and do what I wish using
pan and my mail program, with display on the backup machine, but is that
of significance?

I am reluctant to get into what breaks when because I don't know what information would be useful and compiling at random from hwinfo and
hardinfo is very time-consuming.

Cheers!

jim


--
UNIX is not user-unfriendly, it merely expects users to be computer- friendly.BatteryStatusNo_22387_4.core

--- MBSE BBS v1.0.7.13 (GNU/Linux-x86_64)
* Origin: A noiseless patient Spider (2:250/0@fidonet)

On 2/8/20 5:00 PM, Jim Beard wrote:

Separately,for TJ, is the sort of information in my post yesterday of any use? I can detail what machine is crashing, under what user-
circumstances (usually multiple browsers), and that my Unicomp Model M keyboard continues to work on my back up machine but my main machine
crashes frequently when I put it there.

I can ssh from my backup machine using the Model M. Then, from a
terminal window, I can run pan& and evolution& and do what I wish using
pan and my mail program, with display on the backup machine, but is that
of significance?

I am reluctant to get into what breaks when because I don't know what information would be useful and compiling at random from hwinfo and
hardinfo is very time-consuming.

Unfortunately, Jim, I'm the wrong person to ask. I know less about this
sort of thing than you do. My comment was made after reading the
comments in the bug, and seeing very little if anything that those
afflicted had in common, other than the i915 driver.

One thing I've noticed is that of those that mentioned which DE was
being used, Plasma has not yet come up. For my own part, I have three
machines in my care that use the i915 video driver, are used on a daily
basis, and so far none have shown symptoms. All three of my machines use Plasma. Is that relevant? I have no idea.

My processors are a Core 2 Duo, a first generation mobile i3, and a
Sandy Bridge i5, so all could be considered "older." Is that relevant? I
don't know.

My two desktops are using Logitech wireless keyboard/mouse combos, while
my laptop is using a Logitech mouse, but the built-in keyboard. Is that relevant? I don't know.

I think you need to ask in the bug report, to get an answer from
somebody who is working on the problem, and DOES know.

TJ

--- MBSE BBS v1.0.7.13 (GNU/Linux-x86_64)
* Origin: A noiseless patient Spider (2:250/0@fidonet)

On Sat, 8 Feb 2020 22:00:29 -0000 (UTC), Jim Beard wrote:

There is a
BatteryStatusNo_22387_4.core from yesterday, and a
gnome-shell_2082_11.core from this morning.

Are these worth keeping?

In your case. not really. What is significant is you are getting the
names of applications which have problems and not shutting down correctly.

What you could do is truncate the core files just to have a list that
you could add as information to the bug TJ without wasting disk space. IE.
truncate -s 0 /var/tmp/whatever_here.core

So far you have shown 3 different apps, indicating no pattern as of yet.

--- MBSE BBS v1.0.7.13 (GNU/Linux-x86_64)
* Origin: A noiseless patient Spider (2:250/0@fidonet)

On 2020-02-08, TJ <TJ@noneofyour.business> wrote:

One thing I've noticed is that of those that mentioned which DE was
being used, Plasma has not yet come up. For my own part, I have three machines in my care that use the i915 video driver, are used on a daily basis, and so far none have shown symptoms. All three of my machines use Plasma. Is that relevant? I have no idea.

Sorry not to have said-- I use Plasma as my DE and I have problems that
seem to be related to this bug.


--- MBSE BBS v1.0.7.13 (GNU/Linux-x86_64)
* Origin: A noiseless patient Spider (2:250/0@fidonet)