Severe flashing/blank/lagging screen after update to kernel 5.19

Using 5.17 kernel and did sudo dnf update , rebooting into 5.19 kernel and found out that screen starts to flash/lag and to show black/random patterns.

Here is the output from inxi -Fzx

inxi -Fzx output
  Kernel: 5.19.8-200.fc36.x86_64 arch: x86_64 bits: 64 compiler: gcc v: 2.37-35.fc36
    Console: tty 3 Distro: Fedora release 36 (Thirty Six)
  Type: Laptop System: LENOVO product: 21CX v: ThinkBook 14 G4+ IAP serial: <superuser required>
  Mobo: LENOVO model: LNVNB161216 v: SDK0T76479 WIN serial: <superuser required> UEFI: LENOVO
    v: HYCN38WW date: 07/15/2022
  ID-1: BAT0 charge: 51.0 Wh (83.9%) condition: 60.8/62.0 Wh (98.1%) volts: 16.9 min: 15.5
    model: Sunwoda L21D4PD6 status: discharging
  Info: 12-core (4-mt/8-st) model: 12th Gen Intel Core i5-12500H bits: 64 type: MST AMCP
    arch: Alder Lake rev: 3 cache: L1: 1.1 MiB L2: 9 MiB L3: 18 MiB
  Speed (MHz): avg: 2937 high: 3100 min/max: 400/4500:3300 cores: 1: 3100 2: 3100 3: 500
    4: 3100 5: 3100 6: 3100 7: 3100 8: 3100 9: 3100 10: 3100 11: 3100 12: 3100 13: 3100 14: 3100
    15: 3100 16: 3100 bogomips: 99532
  Flags: avx avx2 ht lm nx pae sse sse2 sse3 sse4_1 sse4_2 ssse3 vmx
  Device-1: Intel Alder Lake-P Integrated Graphics vendor: Lenovo driver: i915 v: kernel
    arch: Gen12.2 bus-ID: 00:02.0
  Device-2: Luxvisions Innotech Integrated RGB Camera type: USB driver: uvcvideo bus-ID: 3-6:2
  Display: server: v: 1.20.14 with: Xwayland v: 22.1.3 driver: X: loaded: modesetting
    unloaded: fbdev,vesa gpu: i915 tty: 360x112 resolution: 2880x1800
  Message: GL data unavailable in console. Try -G --display
  Device-1: Intel Alder Lake PCH-P High Definition Audio vendor: Lenovo
    driver: sof-audio-pci-intel-tgl bus-ID: 00:1f.3
  Sound Server-1: ALSA v: k5.19.8-200.fc36.x86_64 running: yes
  Sound Server-2: PulseAudio v: 15.0 running: no
  Sound Server-3: PipeWire v: 0.3.57 running: yes
  Device-1: Intel Ethernet I219-V vendor: Lenovo driver: e1000e v: kernel port: N/A
    bus-ID: 00:1f.6
  IF: enp0s31f6 state: down mac: <filter>
  Device-2: Intel Wi-Fi 6 AX210/AX211/AX411 160MHz driver: iwlwifi v: kernel bus-ID: 2c:00.0
  IF: wlp44s0 state: up mac: <filter>
  Device-1: Intel AX210 Bluetooth type: USB driver: btusb v: 0.8 bus-ID: 3-10:3
  Report: rfkill ID: hci0 rfk-id: 2 state: up address: see --recommends
  Local Storage: total: 1.38 TiB used: 8.22 GiB (0.6%)
  ID-1: /dev/nvme0n1 vendor: Micron model: MTFDKBA512TFH size: 476.94 GiB temp: 30.9 C
  ID-2: /dev/nvme1n1 vendor: Western Digital model: WD Blue SN570 1TB SSD size: 931.51 GiB
    temp: 33.9 C
  ID-1: / size: 842.98 GiB used: 8.05 GiB (1.0%) fs: ext4 dev: /dev/nvme1n1p1
  ID-2: /boot/efi size: 256 MiB used: 175.6 MiB (68.6%) fs: vfat dev: /dev/nvme0n1p1
  ID-1: swap-1 type: partition size: 24 GiB used: 0 KiB (0.0%) dev: /dev/nvme1n1p2
  ID-2: swap-2 type: zram size: 8 GiB used: 0 KiB (0.0%) dev: /dev/zram0
  System Temperatures: cpu: 34.0 C mobo: N/A
  Fan Speeds (RPM): N/A
  Processes: 335 Uptime: 12m Memory: 15.35 GiB used: 1.86 GiB (12.1%) Init: systemd
  target: graphical (5) Compilers: gcc: 12.2.1 Packages: N/A note: see --pkg Shell: Bash
  v: 5.1.16 inxi: 3.3.19

, and from journalctl --since -10m after lagging happened

journalctl output on


I appriciate any help and advices, and would like to provide more details if needed.

So I did some more research, and found this Arch wiki page about intel graphics screen flickering problem, which suggests:

A temporary solution is to disable this feature using the kernel parameter i915.enable_psr=0 .

And for configuring kernel parameter in Fedora I used grubby with this guide:

  1. look in the file /etc/default/grub if you see GRUB_ENABLE_BLSCFG=true, then you are running with the BLS setup
  2. To modify a single kernel entry (for example, to temporarily work around a display problem) use a grubby comman:
grubby --update-kernel /boot/vmlinuz-5.19.8-200.fc36.x86_64 --args='i915.enable_psr=0'
  1. reboot and screen flickering should gone
  2. If you want to remove the kernel argument, use
grubby --update-kernel /boot/vmlinuz-5.19.8-200.fc36.x86_64 --remove-args='i915.enable_psr=0'

It solved my problem for now, and I will keep using this for a few day to see how itt goes.


grubby works, though it sort of forces you to work “blind” (in the sense that you can’t examine the configs you’re changing) which I don’t love.

If you want a bit more direct control over the process, you can sudo dnf install blsctl to install the config tool for the BootLoader System. It allows you to examine and modify each entry’s configs directly. e.g. on my F36, Nvidia-using-nouveau system: (I’ve wrapped long lines for readability)

$ sudo blsctl entry list
0 5593b6f732944ad491ba36d3b37def31-5.19.6-200.fc36.x86_64.conf
1 5593b6f732944ad491ba36d3b37def31-5.18.19-200.fc36.x86_64.conf
2 5593b6f732944ad491ba36d3b37def31-5.18.18-200.fc36.x86_64.conf
3 5593b6f732944ad491ba36d3b37def31-0-rescue.conf
4 622bc38e3e154842b6a560ee125d842d-0-rescue.conf

$ # (Yes, I should get rid of that extra rescue config, must be a leftover)
$ sudo blsctl cmdline 0 show
root=/dev/mapper/vg00-lv_root ro resume=/dev/mapper/vg00-lv_swap rhgb quiet $tuned_params

sudo blsctl cmdline <num> set i915.enable_psr=0 would set that parameter on the specified entry, you can use sudo blsctl cmdline all set ... to modify all entries at once, and sudo blsctl cmdline all clear i915.enable_psr would remove it from all entries.

Prefer the set subcommand to sudo blsctl cmdline __ add, which will always add an additional parameter setting even if that parameter already exists on the given commandline, leaving you with redundant parameters. (But sometimes you need redundant parameters, like in my entries. That’s what the add subcommand is for, along with the remove subcommand which is more surgical than clear.)

1 Like

Thank you Frank! I tried sudo blsctl cmdline 0 set i915.enable_psr=0 for my case and it works.

I have also do grubby --update-kernel /boot/vmlinuz-5.19.8-200.fc36.x86_64 --remove-args='i915.enable_psr=0' on my system to prevent potential duplicated parameters.

If /boot/vmlinuz-5.19.8-200.fc36.x86_64 is entry 0 in blsctl entry list, you should check (sudo blsctl cmdline 0 show) that your parameter is still there.

blsctl and grubby operate on the same files (the bootloader entries in /boot/loader/entries/), so they can and will affect each other. In other words, doing something like this:

sudo blsctl cmdline all set i915.enable_psr=0
sudo grubby --update-kernel /boot/vmlinuz-5.19.8-200.fc36.x86_64 \

…would result in every commandline containing that parameter except the one corresponding to kernel 5.19.8, because the grubby command would remove the parameter that blsctl added.


Thank you for pointing that out, Frank. I actually did this in such an order:

  1. sudo grubby --update-kernel /boot/vmlinuz-5.19.8-200.fc36.x86_64 \ --remove-args="i915.enable_psr=0" to undo my grubby stuff.

  2. sudo blsctl cmdline 0 show to check the parameters, i915.enable_psr=0 was gone.

  3. sudo blsctl cmdline 0 set i915.enable_psr=0 to set kernel parameters with blsctl.

  4. Check again with sudo blsctl cmdline 0 show , and i915.enable_psr=0 was there as expected.

Thnaks again for you help! I truly appreciate it.

1 Like

Those entries are not redundant. Each applies to a specific LV and is not repeated.

Correct, the values are distinct, but they’re both set on the same parameter. And if you used the parameter-only commands like blsctl cmdline __ clear or blsctl cmdline __ set, it would overwrite/remove all of the existing entries. Hence the existence of blsctl cmdline __ add and blsctl cmdline __ remove, which will leave any other parameters alone).

OK, maybe “repeated” is slightly more precise than “redundant”. (The parameter definitely is repeated, just with a different value each time. Thus making them not technically redundant — conceded.)