Just locked again while using Firefox.

I was able to <alt-ctl-F2> to a terminal session where I did top and there was basically no CPU activity.  I did see Firefox's pid so killed it.  Switched back to graph session and everything was locked.

I did notice a number of abrt services via top running and SELinux Alert Browser is showing me:

SELinux is preventing gdb from read access on the chr_file renderD128.

*****  Plugin catchall (100. confidence) suggests   **************************

If you believe that gdb should be allowed read access on the renderD128 chr_file by default.
Then you should report this as a bug.
You can generate a local policy module to allow this access.
Do
allow this access for now by executing:
# ausearch -c 'gdb' --raw | audit2allow -M my-gdb
# semodule -X 300 -i my-gdb.pp

Additional Information:
Source Context                system_u:system_r:abrt_t:s0-s0:c0.c1023
Target Context                system_u:object_r:dri_device_t:s0
Target Objects                renderD128 [ chr_file ]
Source                        gdb
Source Path                   gdb
Port                          <Unknown>
Host                          lx140e.htt-consult.com
Source RPM Packages           
Target RPM Packages           
SELinux Policy RPM            selinux-policy-targeted-35.18-1.fc35.noarch
Local Policy RPM              selinux-policy-targeted-35.18-1.fc35.noarch
Selinux Enabled               True
Policy Type                   targeted
Enforcing Mode                Enforcing
Host Name                     lx140e.htt-consult.com
Platform                      Linux lx140e.htt-consult.com
                              5.18.6-100.fc35.x86_64 #1 SMP PREEMPT_DYNAMIC Wed
                              Jun 22 13:47:10 UTC 2022 x86_64 x86_64
Alert Count                   42
First Seen                    2022-01-27 19:37:03 EST
Last Seen                     2022-06-28 07:27:52 EDT
Local ID                      4a4eae04-7deb-492f-a462-f47be7c8ca0e

Raw Audit Messages
type=AVC msg=audit(1656415672.408:2572): avc:  denied  { read } for  pid=36264 comm="gdb" name="renderD128" dev="devtmpfs" ino=421 scontext=system_u:system_r:abrt_t:s0-s0:c0.c1023 tcontext=system_u:object_r:dri_device_t:s0 tclass=chr_file permissive=0


Hash: gdb,abrt_t,dri_device_t,chr_file,read


I also saw a lot of activity from pipewire.  Don't know what it is.

Meanwhile I rebooted with my old kernel:

15.17.12-200

Created attachment 1893272 [details]
related /var/log/messages

ARGH.  All I typed here got lost!

This is not a kernel problem as I now get these lockups even with kernel 15.17.12-200 that worked fine prior to the updates shown above.

Here is what SELinux reported at one point:

SELinux is preventing gdb from read access on the chr_file renderD128.

*****  Plugin catchall (100. confidence) suggests   **************************

If you believe that gdb should be allowed read access on the renderD128 chr_file by default.
Then you should report this as a bug.
You can generate a local policy module to allow this access.
Do
allow this access for now by executing:
# ausearch -c 'gdb' --raw | audit2allow -M my-gdb
# semodule -X 300 -i my-gdb.pp

Additional Information:
Source Context                system_u:system_r:abrt_t:s0-s0:c0.c1023
Target Context                system_u:object_r:dri_device_t:s0
Target Objects                renderD128 [ chr_file ]
Source                        gdb
Source Path                   gdb
Port                          <Unknown>
Host                          lx140e.htt-consult.com
Source RPM Packages           
Target RPM Packages           
SELinux Policy RPM            selinux-policy-targeted-35.18-1.fc35.noarch
Local Policy RPM              selinux-policy-targeted-35.18-1.fc35.noarch
Selinux Enabled               True
Policy Type                   targeted
Enforcing Mode                Enforcing
Host Name                     lx140e.htt-consult.com
Platform                      Linux lx140e.htt-consult.com
                              5.17.12-200.fc35.x86_64 #1 SMP PREEMPT Mon May 30
                              16:58:37 UTC 2022 x86_64 x86_64
Alert Count                   47
First Seen                    2022-01-27 19:37:03 EST
Last Seen                     2022-06-28 18:30:56 EDT
Local ID                      4a4eae04-7deb-492f-a462-f47be7c8ca0e

Raw Audit Messages
type=AVC msg=audit(1656455456.964:381): avc:  denied  { read } for  pid=5485 comm="gdb" name="renderD128" dev="devtmpfs" ino=419 scontext=system_u:system_r:abrt_t:s0-s0:c0.c1023 tcontext=system_u:object_r:dri_device_t:s0 tclass=chr_file permissive=0


Hash: gdb,abrt_t,dri_device_t,chr_file,read


==================

This is still urgent. There are web sites I use to go to with no problem that now lock up the video.

This seems to be related to my radeon video driver?

At one lockup, I was fast enough to switch to non-graphics session F2, and in top saw systemd-coredump taking a full CPU.  I don't know where to find this coredump.  But I was in the non-graphics session for 10min with no problem, but when I tried switching back to the graphics F1 session, the video locked.  I saw the non-graphics content, but video was locked, as top was no longer showing refreshes.

So someone that can figure this out, please change component as appropriate so we can get this fixed

thanks

Still crashing and the trigger to lock up the video and mouse clicks and keyboard is sitting on cnn in firefox.

I don't have to try and click any links there, so something they are using triggers the video failure.

I tried, per one comment to have:

cat /etc/modprobe.conf 
options radeon modeset=0


this was in place after a crash so I restarted with it, got things set up.  No thunderbirds running or really anything else.  Started firefox.  opened a window and went to cnn.  Waited maybe a minute and lock.

cnn was working saturday night before I ran dnf update, istalling the updates I list above.  What changed?

Most likely NOT kernel, but what is it?

Please advise.

my problem was not the kernel, but old radeon video driver that was defaulted for my Lenovo x140e.  The problem became serious with kernel updates, making it seem that was where the problem was.

I got help to do the following:

cat > /etc/modprobe.d/enable_amdgpu_disable_radeon.conf
options amdgpu si_support=1
options amdgpu cik_support=1
options radeon si_support=0
options radeon cik_support=0

dracut -f

And switch to the amdgpu driver.

Resulting in:

# lspci -nnk | egrep -i "VGA|DISPLAY" -A3
00:01.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. [AMD/ATI] Kabini [Radeon HD 8330] [1002:9832]
	Subsystem: Lenovo Device [17aa:2219]
	Kernel driver in use: amdgpu
	Kernel modules: radeon, amdgpu


I have been lockup free now for over a week and a new kernel update.  So I am closing this bug.