March 2021 - openSUSE Kernel Bugs - openSUSE Mailing Lists

[Bug 1183739] Installing new kernel build (without source change - same uname-r) can cause nVidia driver removal
by bugzilla_noreply＠suse.com 19 Mar '21

19 Mar '21

https://bugzilla.suse.com/show_bug.cgi?id=1183739 https://bugzilla.suse.com/show_bug.cgi?id=1183739#c2 --- Comment #2 from Stefan Dirsch <sndirsch(a)suse.com> --- > Solutions: > Is it possible to use the full release number in file and directory names so that these kernels would be installed alongside old kernels? Unfortunately it's not that easy, i.e. if there would be /lib/modules/5.11.4-1.2-default /lib/modules/5.11.4-1.3-default instead of only one /lib/modules/5.11.4-1-default the kernels also would need to be named 5.11.4-1.2-default and .11.4-1.3-default. And not any longer just 5.11.4-1-default. > Or perhaps an easier solution is to not increment the minor release number and just the major e.g. 5.11.4-1, 5.11.4-2, 5.11.4-3, etc. ? This sounded more doable to me, but according to Takashi's comment it is not. --- The last number is the OBS checkin counter and it shouldn't be taken into the path; otherwise you'll have to rebuild everything even if nothing else is changed at all. --- -- You are receiving this mail because: You are the assignee for the bug.

1 0

[Bug 1183739] Installing new kernel build (without source change - same uname-r) can cause nVidia driver removal
by bugzilla_noreply＠suse.com 19 Mar '21

19 Mar '21

https://bugzilla.suse.com/show_bug.cgi?id=1183739 Michal Suchanek <msuchanek(a)suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Summary|Kernel update with a |Installing new kernel build |release minor number bump |(without source change - |causes old kernel removal |same uname-r) can cause | |nVidia driver removal -- You are receiving this mail because: You are the assignee for the bug.

1 0

[Bug 1182929] kernel fuse crash in heavy use with cvmfs
by bugzilla_noreply＠suse.com 19 Mar '21

19 Mar '21

https://bugzilla.suse.com/show_bug.cgi?id=1182929 https://bugzilla.suse.com/show_bug.cgi?id=1182929#c25 --- Comment #25 from Luis Henriques <lhenriques(a)suse.com> --- (In reply to Stefan Kluth from comment #24) > skluth@thserv04:~$ uname -a > Linux thserv04 5.12.0-rc3-1.g8d911cd-default #1 SMP Thu Mar 18 12:08:15 UTC > 2021 (8d911cd) x86_64 x86_64 x86_64 GNU/Linux > > The full build of the ATLAS software now ran to completion w/o problems. Awesome news! Thanks for your help. > Looks like a fix for us. Thanks for the efforts of everybody! > > Does this fix have a chance of backporting to LTS kernel 5.4.x? > > Our application is opensuse tumbleweed, but others would be affected too if > they use linux >= 5.4.x Yeah, I'll try to find out when this patch will be merged into mainline and, eventually, Cc'ed into stable kernels. I'll update this bugzilla as I get more details. -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1183753] New: xtables-addons fails to build with SLE kernel
by bugzilla_noreply＠suse.com 19 Mar '21

19 Mar '21

https://bugzilla.suse.com/show_bug.cgi?id=1183753 Bug ID: 1183753 Summary: xtables-addons fails to build with SLE kernel Classification: openSUSE Product: openSUSE Distribution Version: Leap 15.3 Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Kernel Assignee: kernel-bugs(a)opensuse.org Reporter: mlin(a)suse.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- xtables-addons in Leap 15.3 fails to build with SLE kernel [ 81s] /home/abuild/rpmbuild/BUILD/xtables-addons-default-3.9/extensions/xt_TARPIT.c: In function 'tarpit_tcp4': [ 81s] /home/abuild/rpmbuild/BUILD/xtables-addons-default-3.9/extensions/xt_TARPIT.c:211:2: error: implicit declaration of function 'nf_reset'; did you mean 'nf_ct_set'? [-Werror=implicit-function-declaration] [ 81s] nf_reset(nskb); [ 81s] ^~~~~~~~ [ 81s] nf_ct_set the complete build log at https://build.opensuse.org/package/live_build_log/openSUSE:Leap:15.3/xtable… -- You are receiving this mail because: You are the assignee for the bug.

1 1

[Bug 1183739] Kernel update with a release minor number bump causes old kernel removal
by bugzilla_noreply＠suse.com 19 Mar '21

19 Mar '21

https://bugzilla.suse.com/show_bug.cgi?id=1183739 https://bugzilla.suse.com/show_bug.cgi?id=1183739#c1 Takashi Iwai <tiwai(a)suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |msuchanek(a)suse.com, | |tiwai(a)suse.com --- Comment #1 from Takashi Iwai <tiwai(a)suse.com> --- The last number is the OBS checkin counter and it shouldn't be taken into the path; otherwise you'll have to rebuild everything even if nothing else is changed at all. The current behavior is a sort of workaround for the situation. Basically this kind of stuff is handled via the weak-link of KMP if it's a usual KMP. But Nvidia is an exception, of course, and it doesn't work like that. That said, from the kernel side, this is likely resolved as FEATURE. If any, Nvidia driver should have a better workaround for this corner case (e.g. listing the modules in ghost). -- You are receiving this mail because: You are the assignee for the bug.

1 0

[Bug 1183716] No kernel-debug for aarch64
by bugzilla_noreply＠suse.com 19 Mar '21

19 Mar '21

https://bugzilla.suse.com/show_bug.cgi?id=1183716 https://bugzilla.suse.com/show_bug.cgi?id=1183716#c6 --- Comment #6 from Guillaume GARDET <guillaume.gardet(a)arm.com> --- @dirk, could you also include CONFIG_KASAN_HW_TAGS=y in the debug config, please? -# CONFIG_KASAN is not set +CONFIG_KASAN=y +# CONFIG_KASAN_GENERIC is not set +CONFIG_KASAN_HW_TAGS=y +CONFIG_KASAN_STACK=1 +# CONFIG_TEST_KASAN_MODULE is not set -- You are receiving this mail because: You are the assignee for the bug.

1 0

[Bug 1183727] Shutdown hangs frequently in various places.
by bugzilla_noreply＠suse.com 19 Mar '21

19 Mar '21

https://bugzilla.suse.com/show_bug.cgi?id=1183727 https://bugzilla.suse.com/show_bug.cgi?id=1183727#c1 Takashi Iwai <tiwai(a)suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |tiwai(a)suse.com --- Comment #1 from Takashi Iwai <tiwai(a)suse.com> --- This rather sounds like a user-space issue than the kernel. Does "/sbin/reboot -f" also show the problem? -- You are receiving this mail because: You are the assignee for the bug.

1 0

[Bug 1182929] kernel fuse crash in heavy use with cvmfs
by bugzilla_noreply＠suse.com 18 Mar '21

18 Mar '21

https://bugzilla.suse.com/show_bug.cgi?id=1182929 https://bugzilla.suse.com/show_bug.cgi?id=1182929#c24 Stefan Kluth <skluth(a)mpp.mpg.de> changed: What |Removed |Added ---------------------------------------------------------------------------- Flags|needinfo?(skluth(a)mpp.mpg.de | |) | --- Comment #24 from Stefan Kluth <skluth(a)mpp.mpg.de> --- skluth@thserv04:~$ uname -a Linux thserv04 5.12.0-rc3-1.g8d911cd-default #1 SMP Thu Mar 18 12:08:15 UTC 2021 (8d911cd) x86_64 x86_64 x86_64 GNU/Linux The full build of the ATLAS software now ran to completion w/o problems. Looks like a fix for us. Thanks for the efforts of everybody! Does this fix have a chance of backporting to LTS kernel 5.4.x? Our application is opensuse tumbleweed, but others would be affected too if they use linux >= 5.4.x -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1183739] New: Kernel update with a release minor number bump causes old kernel removal
by bugzilla_noreply＠suse.com 18 Mar '21

18 Mar '21

http://bugzilla.opensuse.org/show_bug.cgi?id=1183739 Bug ID: 1183739 Summary: Kernel update with a release minor number bump causes old kernel removal Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Kernel Assignee: kernel-bugs(a)opensuse.org Reporter: kerossin(a)pm.me QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- When a kernel update is released that only bumps up the last number of the release the older kernel is removed and the new one installed instead of just installing the new. >rpm -qi kernel-default-5.11.4 > >Version : 5.11.4 >Release : 1.3 <- this is the number I'm talking about Perhaps a real example will makes this clearer. Recently Tumbleweed was on kernel 5.11.4-1.2, snapshot 20210315 had an update - 5.11.4-1.3. Zypper handles this update by removing -1.2 first and then installing -1.3. With the current configuration of kernel packages it's not possible to install both of these packages side by side because they use the exact same file and directory names, the minor release number is omitted, e.g. /boot/initrd-5.11.4-1-default, /lib/modules/5.11.4-1-default/. What problems does this cause: Well a fundamental one would be that it doesn't follow the convention and what everyone expects - a kernel update shouldn't touch the previous kernel and should be installed separately. Another one and how we noticed this issue is that it can mess with out of tree kernel modules during updates. We specifically noticed this with Nvidia driver kernel modules and it depends on how lucky you are. For example when 'zypper dup' installs kernel-default before kernel-default-devel you're in luck, no problem happens. But if you get unlucky and zypper installs kernel-default-devel before kernel-default that's when the problem occurs. Nvidia kernel module installation is triggered by kernel-default-devel installation and those modules are put into /lib/modules/$kernelversion/updates/. The removal of those modules is triggered by removal of kernel-default. So here's what happens with the 20210315 unlucky example: 1) kernel-default-devel-5.11.4-1.3 is installed 2) Nvidia modules are installed at /lib/modules/5.11.4-1-default/updates/ 3) kernel-default-5.11.4-1.2 is removed 4) Nvidia modules are deleted from /lib/modules/5.11.4-1-default/updates/ 5) kernel-default-5.11.4-1.3 is installed now your new kernel is left without Nvidia drivers and it will boot to the terminal. If it would use file and directory names with the full release number (/lib/modules/5.11.4-1.2-default/, /lib/modules/5.11.4-1.3-default/) this wouldn't happen and also the removal of the kernel wouldn't be nescessary. The way I see it this potentially affects not only Nvidia drivers, if other kernel modules are managed in a similar fashion they could be affected. *Note: this same thing occured with snapshot 20210222 when kernel went from 5.10.16-1.2 to 5.10.16-1.3. Solutions: Is it possible to use the full release number in file and directory names so that these kernels would be installed alongside old kernels? Or perhaps an easier solution is to not increment the minor release number and just the major e.g. 5.11.4-1, 5.11.4-2, 5.11.4-3, etc. ? -- You are receiving this mail because: You are the assignee for the bug.

1 0

[Bug 1182556] i915 [DRM] Random window/background flickering
by bugzilla_noreply＠suse.com 18 Mar '21

18 Mar '21

http://bugzilla.opensuse.org/show_bug.cgi?id=1182556 http://bugzilla.opensuse.org/show_bug.cgi?id=1182556#c10 --- Comment #10 from Peer FRANK <peer.frank(a)web.de> --- today I installed TW 20210316 with Kernel 5.11.6-1-default and the problem is gone. i915 with renderer Mesa DRI INtel HD Graphics 4400 on X11 -- You are receiving this mail because: You are the assignee for the bug.

1 0