DO NOT USE 5.19.12.
Intel devs are saying it can potentially damage lcd panels:
After looking at some logs we do end up with potentially bogus
panel power sequencing delays, which may harm the LCD panel.
https://lore.kernel.org/all/YzwooNdMECzuI5+h@intel.com/
The patches are being reverted and a new stable release will be out soon.
Also to confirm, I was running the 6.0rc7 linux-mainline on Arch w/o a problem and I’m now updated to the official 6.0 release w/o any issues as well.
Linux 5.19.13 is out, and I can confirm it’s working fine.
Whooooooo boy. This just bit me on F36.
To quickly recover:
Hold the power button down to turn the unit off, then turn it back on. You have to be quick and catch the GRUB boot loader. The default (naughty) kernel will be up top (in this case 5.19.12-200.fc36 on a F36 system). You want to down arrow one time to get to the previous kernel (5.19.11-200.fc36 for me), and hit enter. Your system will boot like normal. Now the trick is going to be making your previous kernel the default for a while. It’s actually not too bad.
Log into your system, open up a terminal and type:
sudo grubby --default-index
It should return 0 on a normal day. We’re going for abnormal. Let’s get a list of kernels!
sudo grubby --info=ALL
You’ll get some output. Notice that the most recently installed kernel is most likely index=0, and the previous one is most likely index=1. We’re going to tell it to use index=1 by default.
sudo grubby --set-default-index=1
It will tell you the new default is /boot/loader/entries/someweirdguid-5.19.11-200(more kernel version barf, etc.) with index 1…
After that you should be able to reboot without worrying about that pesky 5.19.12 business… At least until the next kernel update. 
I hope this helps someone who stumbles upon this topic in a panic. These situations can be pretty scary for folks the first time it happens to them.
Hello there.
Any chance you could check if systemctl hibernation resumes without a black screen on your side ?
I would really appreciate it.
Thanks Aggraxis for this info.
After thinking the problem wasn’t showing up in the Fedora 37 beta with kernel 5.19.12 (as in my previous post), the screen started to flicker on power off, which then took about 30 seconds. So it’s now reverted to 5.19.11-300.fc37 for the moment.
But /dev won’t have been mounted and pacman downgrade would fail.
as @5uie1 said, Runlevel 3 (multi-user mode with networking) and black listing i915 module works as intended.
//before
# linux /vmlinuz-linux root=UUID=[some-random-uuid] rw loglevel=3
// after
linux /vmlinuz-linux root=UUID=[some-random-uuid] rw 3 module_blacklist=i915 loglevel=3
FYI this was fixed in the 5.19.13 kernel as well: Regression on 5.19.12, display flickering on Framework laptop - Jerry Ling
now closing the loop and self-referencing the thread that was in the email 
Confirming that 5.9.13-arch1-1 is now working. No trouble with the display.
Just got my framework and i was so excited at the first moment. Then i downloaded a fresh arch iso with the 5.19.12 kernel … you can’t imagine how disappointed i was for half a hour, thankfully i found this thread 
I just got the update for 5.19.13 in Fedora 36, and it automatically it set my default-index back to 0 during installation.
So if you do a grubby --default-kernel or --default-index after you install the 5.19.13 package you can verify that it has changed the index back for you. In my case it required no additional effort on my part. dnf upgrade, reboot, profit. The system is working like normal. Also, you guys are all awesome. Thanks everyone for sharing info.
This is the beauty of the Framework community. Wonderful.
Hello,
I had to roll back to a previous kernel release, 5.19.12 fails to load. It seems like it is related to this bug.
I am running Opensuse Tumbleweed. The issue is not Dependent on the Distribution however.
Can confirm - problem also occurs with my 12th-Gen Framework running Fedora Kinoite 37-pre. Rolling back from 5.19.12 to 5.19.11 fixes the problem.
Problem confirmed, Fredora 36,
FYI for Fedora users - kernel 5.19.13 is being pushed to testing:
https://bodhi.fedoraproject.org/updates/FEDORA-2022-356f5d97a9 (Fedora 37)
https://bodhi.fedoraproject.org/updates/FEDORA-2022-6805c86132 (Fedora 36)
I can confirm that 5.19.13 on Fedora Kinoite 37-pre fixes the problem with 5.19.12.
Fedora peeps, 5.19.13 is fully available via standard update. 
