Since updating to the new 7.0.X kernel, I’ve been having issues (though not as many as many users on this forum).
On May 2, after noticing some instability on my system, I installed Kubuntu in a dual-boot setup: you might say I’m not very loyal, but I need some stability to be able to work.
Also, I’m puzzled by one thing: why are there these Nvidia and kernel 7 issues on OpenSUSE?
I’ve read all your posts, especially Lioli7k’s, with great interest.
The question I’m asking here:
Kubuntu is currently installed with kernel 7.0.0.15 and Nvidia 595.58.03 and has no stability issues.
Only rebooting and shutting down the machine don’t work.
On the Ubuntu forum, I can’t find any threads discussing the same problems.
So why doesn’t it work on OpenSUSE?
I’m not disparaging OpenSUSE in any way, I’m sticking with it but I’m puzzled.
Funnily enough, I happen to have an Ubuntu 26.04 VM lying on a shelf. So I can answer that question. On out of the box 7.0.0-14-generic kernel it uses lazy preemption mode by default.
CONFIG_PREEMPT_BUILD=y
CONFIG_ARCH_HAS_PREEMPT_LAZY=y
# CONFIG_PREEMPT is not set
CONFIG_PREEMPT_LAZY=y
# CONFIG_PREEMPT_RT is not set
CONFIG_PREEMPT_COUNT=y
CONFIG_PREEMPTION=y
CONFIG_PREEMPT_DYNAMIC=y
CONFIG_PREEMPT_RCU=y
CONFIG_HAVE_PREEMPT_DYNAMIC=y
CONFIG_HAVE_PREEMPT_DYNAMIC_CALL=y
CONFIG_PREEMPT_NOTIFIERS=y
CONFIG_DRM_I915_PREEMPT_TIMEOUT=640
CONFIG_DRM_I915_PREEMPT_TIMEOUT_COMPUTE=7500
CONFIG_DRM_XE_PREEMPT_TIMEOUT=640000
CONFIG_DRM_XE_PREEMPT_TIMEOUT_MAX=10000000
CONFIG_DRM_XE_PREEMPT_TIMEOUT_MIN=1
# CONFIG_DEBUG_PREEMPT is not set
# CONFIG_PREEMPT_TRACER is not set
# CONFIG_PREEMPTIRQ_DELAY_TEST is not set
Most of those options match OpenSUSE’s, just Ubuntu prefers lazy mode over full. Haven’t checked what’s the difference between full and lazy but neither work on my PC.
And then weird part happens. When I manually installed Nvidia driver on Ubuntu it also suggested some 6.19.0-1003-aws kernel. After a reboot it still used 7.0. I decided to look at that aws kernel config anyway.
CONFIG_PREEMPT_VOLUNTARY_BUILD=y
CONFIG_ARCH_HAS_PREEMPT_LAZY=y
# CONFIG_PREEMPT_NONE is not set
CONFIG_PREEMPT_VOLUNTARY=y
# CONFIG_PREEMPT is not set
# CONFIG_PREEMPT_LAZY is not set
# CONFIG_PREEMPT_RT is not set
# CONFIG_PREEMPT_DYNAMIC is not set
CONFIG_HAVE_PREEMPT_DYNAMIC=y
CONFIG_HAVE_PREEMPT_DYNAMIC_CALL=y
CONFIG_PREEMPT_NOTIFIERS=y
CONFIG_DRM_I915_PREEMPT_TIMEOUT=640
CONFIG_DRM_I915_PREEMPT_TIMEOUT_COMPUTE=7500
CONFIG_DRM_XE_PREEMPT_TIMEOUT=640000
CONFIG_DRM_XE_PREEMPT_TIMEOUT_MAX=10000000
CONFIG_DRM_XE_PREEMPT_TIMEOUT_MIN=1
# CONFIG_PREEMPTIRQ_DELAY_TEST is not set
It uses voluntary preemption mode. The same mode OpenSUSE’s 6.19.12 and current longterm kernels use. No conclusion yet since I’m still struggling to build a kernel from source (I don’t get OpenSUSE’s workflow on that yet. Probably need to seek help at mailing lists.) But it aligns with my suspicion so far.
I can but it’ll make it a lot more difficult to make it easily installable for testing. Especially since I need it to be a drop in replacement for current kernel-default. I’ve tried taking kernel-source and changing only build config but that didn’t worked. I guess I’ve messed up config options.
Did it fail to compile remotely on OBS? I usually compile remotely because I don’t want the overhead of all the development rpms. Could try to do that now if you think it might help.
I was compiling it locally. Unmodified specs from OBS worked flawlessly. Issues started when I modified config. Build was failing at checking build config stage. So I think problem exists somewhere between chair and keyboard.
Building a pkg.tar.zst on CachyOS was really straightforward. I just copied their build scripts, changed source URL to OpenSUSE’s kernel source, changed a few small things here and there, copied over OpenSUSE’s config from OBS, makepkg -s and boom. 30 minutes later I have a working kernel.
I haven’t contacted them yet. I’m trying to figure things out going off their documentation, rather than bothering devs right away on every friction point. I bet they have their hands full as it is.
I have a fix to propose in mind already. But I need at the very least test it on my PC rather than randomly tweak kernel without understanding the impact. This is the first time I’m doing anything with kernel sources.
FWIW, using the osc command-line tool doesn’t require that you have development RPMs installed - it builds in a build environment and installs what it needs there. The environment can be reused on multiple builds of the same package, or you can do a clean rebuild.
Local builds tend to be much faster than remote builds, so it’s a good way to test build options out before submitting a package for build remotely, and it won’t mess up your installed packages.
Oh yeah. Do you happen to know where documentation for building a kernel can be found? It seems to be scattered all over the place… So far I was referencing those links:
Those are the resources I probably would have started with myself, but running into issues, I’d probably hit the factory ML and ask for assistance there. Given the nature of this issue, I’m sure someone from the dev team would probably be happy to help in order to get to a faster resolution.
Been a while since I built my own kernel. But the other thing I’d probably do is link to the build in TW in the build service, pull it locally, make my config changes, and then try running the build using osc build (with the appropriate options to do a local build), since the build service project is known to build successfully.