Can confirm, just compiled 6.0 of the Clear Linux kernel and it’s working fine on my Arch install.
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.
5 Likes
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.
5 Likes
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.
5 Likes
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
1 Like
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 
8 Likes
Confirming that 5.9.13-arch1-1 is now working. No trouble with the display.
5 Likes
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 
2 Likes
Fedora peeps, 5.19.13 is fully available via standard update. 
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.
1 Like
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.
4 Likes
This is the beauty of the Framework community. Wonderful.
3 Likes
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.
1 Like
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.
2 Likes
Problem confirmed, Fredora 36,
1 Like