Created attachment 1787333 [details] dmesg output previous boot 1. Please describe the problem: New install of Fedora 34 Workstation (GNOME) on a 2007 MacBook3,1 with 6GB RAM, 240GB SATA SSD and a Core 2 Duo T7500 CPU. System works perfectly on the original kernel 5.11.12, but the first system update installed kernel 5.12.6. Booting into kernel 5.12.6 and attempting to login to my account at the graphical GNOME login screen results in a "hard freeze" of the system, max fans and unable to get to TTY (virtual terminal). Have to power the system down forcibly. Boot menu appears on next boot, choosing the previous kernel entry (5.11.12) results once again in a working system. The freeze happens as I click on my highlighted user name at the login screen, before the password prompt has a chance to appear. I attempted to "versionlock" the kernel package and uninstalled the 5.12.6 packages, but the next run of the software updater has reinstalled the 5.12.6 packages and reintroduced the problem. 2. What is the Version-Release number of the kernel: 5.12.6 (package is 5.12.6-300) 3. Did it work previously in Fedora? If so, what kernel version did the issue *first* appear? Old kernels are available for download at https://koji.fedoraproject.org/koji/packageinfo?packageID=8 : Known working fine with kernel 5.11.12 installed with Fedora 34. 4. Can you reproduce this issue? If so, please provide the steps to reproduce the issue below: Install kernel 5.12.6 on MacBook3,1. Boot to graphical (GDM?) login screen. Click on user name. Hard system freeze before the password prompt can appear. 5. Does this problem occur with the latest Rawhide kernel? To install the Rawhide kernel, run ``sudo dnf install fedora-repos-rawhide`` followed by ``sudo dnf update --enablerepo=rawhide kernel``: Will try to test this and update later. 6. Are you running any modules that not shipped with directly Fedora's kernel?: Not that I know of. I'm not an advanced user. 7. Please attach the kernel logs. You can get the complete kernel log for a boot with ``journalctl --no-hostname -k > dmesg.txt``. If the issue occurred on a previous boot, use the journalctl ``-b`` flag. Attached "dmesg.txt" with output of ``journalctl -b --no-hostname -k > dmesg.txt``
*** This bug has been marked as a duplicate of bug 1963782 ***