Kernel 6.8.0-20-generic - lowlatency and generic merge into one

[1fallen]

A nice check ie:

ldd "$(command -v sshd)"

A look from Arch:

ldd "$(command -v sshd)"
        linux-vdso.so.1 (0x00007ffe96a52000)
        libcrypt.so.2 => /usr/lib/libcrypt.so.2 (0x0000781b92471000)
        libpam.so.0 => /usr/lib/libpam.so.0 (0x0000781b9245f000)
        libgssapi_krb5.so.2 => /usr/lib/libgssapi_krb5.so.2 (0x0000781b92404000)
        libkrb5.so.3 => /usr/lib/libkrb5.so.3 (0x0000781b9231a000)
        libcrypto.so.3 => /usr/lib/libcrypto.so.3 (0x0000781b91c00000)
        libz.so.1 => /usr/lib/libz.so.1 (0x0000781b922fb000)
        libc.so.6 => /usr/lib/libc.so.6 (0x0000781b91800000)
        libaudit.so.1 => /usr/lib/libaudit.so.1 (0x0000781b922c9000)
        libk5crypto.so.3 => /usr/lib/libk5crypto.so.3 (0x0000781b92296000)
        libcom_err.so.2 => /usr/lib/libcom_err.so.2 (0x0000781b92290000)
        libkrb5support.so.0 => /usr/lib/libkrb5support.so.0 (0x0000781b92282000)
        libkeyutils.so.1 => /usr/lib/libkeyutils.so.1 (0x0000781b9227b000)
        libresolv.so.2 => /usr/lib/libresolv.so.2 (0x0000781b92267000)
        /lib64/ld-linux-x86-64.so.2 => /usr/lib64/ld-linux-x86-64.so.2 (0x0000781b925e2000)
        libcap-ng.so.0 => /usr/lib/libcap-ng.so.0 (0x0000781b9225f000)

[MAFoElffen]

The thing I'm looking out for is... The canned warnings that were posted in the Wiki pages with low-latency kernels previous to 'this push' where that some modules may not work, or failed to build... That was for both the RT and low-latency series kernels. But I have heard that there have been a lot of patches to get around those issues, and maybe those warnings might not be relevant "today".

Honestly: IDK. Time will tell how this goes.

@Doug S --- How do you feel about all this as it relates to Server?

[Doug S]

The thing I'm looking out for is... The canned warnings that were posted in the Wiki pages with low-latency kernels previous to 'this push' where that some modules may not work, or failed to build... That was for both the RT and low-latency series kernels. But I have heard that there have been a lot of patches to get around those issues, and maybe those warnings might not be relevant "today".

Honestly: IDK. Time will tell how this goes.

@Doug S --- How do you feel about all this as it relates to Server?

As you know, I am happy about the merging of low-latency into generic. I have never been aware of any issues, although I mainly use the upstream mainline kernel, with no patches and no graphics. I have no experience with the RT kernel.

[MyMurry]

Today I got 6.8.0-22

Now my graphics flickers from time to time.

i915 0000:00:02.0: [drm] *ERROR* CPU pipe A FIFO underrun

[Doug S]

Today I got 6.8.0-22

Now my graphics flickers from time to time.

i915 0000:00:02.0: [drm] *ERROR* CPU pipe A FIFO underrun

What is your processor make and model? Do "grep --max-count=1 "model name" /proc/cpuinfo".
How many idle states does your system have? Do "ls -l -d /sys/devices/system/cpu/cpu6/cpuidle/state*".
Try disabling the deepest idle states, one by one, does it make a difference?
Were you previously using kernel 6.8.0-11 generic and did it work properly?

Example of what I am asking:

$ grep --max-count=1 "model name" /proc/cpuinfo
model name      : Intel(R) Core(TM) i5-10600K CPU @ 4.10GHz
$ ls -l -d /sys/devices/system/cpu/cpu6/cpuidle/state*
drwxr-xr-x 2 root root 0 Apr  7 11:01 /sys/devices/system/cpu/cpu6/cpuidle/state0
drwxr-xr-x 3 root root 0 Apr  7 11:01 /sys/devices/system/cpu/cpu6/cpuidle/state1
drwxr-xr-x 3 root root 0 Apr  7 11:01 /sys/devices/system/cpu/cpu6/cpuidle/state2
drwxr-xr-x 3 root root 0 Apr  7 11:01 /sys/devices/system/cpu/cpu6/cpuidle/state3
$ echo 1 | sudo tee /sys/devices/system/cpu/cpu*/cpuidle/state3/disable
1
$ grep . /sys/devices/system/cpu/cpu*/cpuidle/state3/disable
/sys/devices/system/cpu/cpu0/cpuidle/state3/disable:1
/sys/devices/system/cpu/cpu10/cpuidle/state3/disable:1
/sys/devices/system/cpu/cpu11/cpuidle/state3/disable:1
/sys/devices/system/cpu/cpu1/cpuidle/state3/disable:1
/sys/devices/system/cpu/cpu2/cpuidle/state3/disable:1
/sys/devices/system/cpu/cpu3/cpuidle/state3/disable:1
/sys/devices/system/cpu/cpu4/cpuidle/state3/disable:1
/sys/devices/system/cpu/cpu5/cpuidle/state3/disable:1
/sys/devices/system/cpu/cpu6/cpuidle/state3/disable:1
/sys/devices/system/cpu/cpu7/cpuidle/state3/disable:1
/sys/devices/system/cpu/cpu8/cpuidle/state3/disable:1
/sys/devices/system/cpu/cpu9/cpuidle/state3/disable:1
$ grep . /sys/devices/system/cpu/cpu1/cpuidle/state*/disable
/sys/devices/system/cpu/cpu1/cpuidle/state0/disable:0
/sys/devices/system/cpu/cpu1/cpuidle/state1/disable:0
/sys/devices/system/cpu/cpu1/cpuidle/state2/disable:0
/sys/devices/system/cpu/cpu1/cpuidle/state3/disable:1

[MyMurry]

norbert@norbert-Latitude-5580:~$ grep --max-count=1 "model name" /proc/cpuinfo
model name : Intel(R) Core(TM) i5-6200U CPU @ 2.30GHz

norbert@norbert-Latitude-5580:~$ sudo ls -l -d /sys/devices/system/cpu/cpu0/cpuidle/state*
drwxr-xr-x 2 root root 0 Apr 7 21:20 /sys/devices/system/cpu/cpu0/cpuidle/state0
drwxr-xr-x 3 root root 0 Apr 7 21:20 /sys/devices/system/cpu/cpu0/cpuidle/state1
drwxr-xr-x 3 root root 0 Apr 7 21:20 /sys/devices/system/cpu/cpu0/cpuidle/state2
drwxr-xr-x 3 root root 0 Apr 7 21:20 /sys/devices/system/cpu/cpu0/cpuidle/state3
drwxr-xr-x 3 root root 0 Apr 7 21:20 /sys/devices/system/cpu/cpu0/cpuidle/state4
drwxr-xr-x 3 root root 0 Apr 7 21:20 /sys/devices/system/cpu/cpu0/cpuidle/state5
drwxr-xr-x 3 root root 0 Apr 7 21:20 /sys/devices/system/cpu/cpu0/cpuidle/state6
drwxr-xr-x 3 root root 0 Apr 7 21:20 /sys/devices/system/cpu/cpu0/cpuidle/state7
drwxr-xr-x 3 root root 0 Apr 7 21:20 /sys/devices/system/cpu/cpu0/cpuidle/state8

I added "i915.enable_psr=0" to my boot config. This solve the problem. I will try to disable the deepest idle state.I used kernel 6.8.0-11 generic before without any problems.

[Doug S]

...
I will try to disable the deepest idle state.I used kernel 6.8.0-11 generic before without any problems.

If you are willing, it would be good to try to isolate why 6.8.0-11 generic worked and 6.8.0-20 has this issue.

You might need to disable more than just the deepest idle state, but try one state at a time. It would also be good to know the state names:

doug@s19:/media/nvme/home/doug/idle$ grep . /sys/devices/system/cpu/cpu1/cpuidle/state*/name
/sys/devices/system/cpu/cpu1/cpuidle/state0/name:POLL
/sys/devices/system/cpu/cpu1/cpuidle/state1/name:C1_ACPI
/sys/devices/system/cpu/cpu1/cpuidle/state2/name:C2_ACPI
/sys/devices/system/cpu/cpu1/cpuidle/state3/name:C3_ACPI

and:

doug@s15:~$ grep . /sys/devices/system/cpu/cpu1/cpuidle/state*/name
/sys/devices/system/cpu/cpu1/cpuidle/state0/name:POLL
/sys/devices/system/cpu/cpu1/cpuidle/state1/name:C1
/sys/devices/system/cpu/cpu1/cpuidle/state2/name:C1E
/sys/devices/system/cpu/cpu1/cpuidle/state3/name:C3
/sys/devices/system/cpu/cpu1/cpuidle/state4/name:C6

I wonder if adding "preempt=none" to the grub command line makes a difference? (hope I have the syntax correct, I didn't test it.) EDIT: after re-reading my first post on this thread, this shouldn't be the reason.

[MyMurry]

both commands are the same:

norbert@norbert-Latitude-5580:~$ grep . /sys/devices/system/cpu/cpu1/cpuidle/state*/name
/sys/devices/system/cpu/cpu1/cpuidle/state0/namePOLL
/sys/devices/system/cpu/cpu1/cpuidle/state1/name:C1
/sys/devices/system/cpu/cpu1/cpuidle/state2/name:C1E
/sys/devices/system/cpu/cpu1/cpuidle/state3/name:C3
/sys/devices/system/cpu/cpu1/cpuidle/state4/name:C6
/sys/devices/system/cpu/cpu1/cpuidle/state5/name:C7s
/sys/devices/system/cpu/cpu1/cpuidle/state6/name:C8
/sys/devices/system/cpu/cpu1/cpuidle/state7/name:C9
/sys/devices/system/cpu/cpu1/cpuidle/state8/name:C10

[Doug S]

both commands are the same:

I'm not sure what you mean there. If you were referring to my grub command line suggestion, "preempt=none", that was about your original issue, not what you would expect to see for idle state names. My two examples were from 2 different computers, one that has a specific intel_idle entry and one that doesn't, so it uses the relevant default ACPI states.

Anyway, I see that kernel 6.8.0-22-generic has been released. Does the issue still occur with the new kernel?

[Doug S]

Hmmm... there seems to be generic and lowlatency kernels again, with the kernel configuration differences:

doug@s19:~/kernel/linux$ scripts/diffconfig /boot/config-6.8.0-28-generic /boot/config-6.8.0-28-lowlatency
 PREEMPT n -> y
 PREEMPT_VOLUNTARY y -> n
 RCU_NOCB_CPU_DEFAULT_ALL n -> y
 VERSION_SIGNATURE "Ubuntu 6.8.0-28.28-generic 6.8.1" -> "Ubuntu 6.8.0-28.28.1-lowlatency 6.8.1"