February 2021 - openSUSE Kernel Bugs - openSUSE Mailing Lists

[kernel-bugs] [Bug 1173819] New: 'BUG: workqueue lockup' on ThunderX2 machines with kernel 4.12.14 in OBS

by bugzilla_noreply＠suse.com

http://bugzilla.opensuse.org/show_bug.cgi?id=1173819 Bug ID: 1173819 Summary: 'BUG: workqueue lockup' on ThunderX2 machines with kernel 4.12.14 in OBS Classification: openSUSE Product: openSUSE Distribution Version: Leap 15.1 Hardware: aarch64 OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Kernel Assignee: kernel-bugs(a)opensuse.org Reporter: guillaume.gardet(a)arm.com QA Contact: qa-bugs(a)suse.de CC: adrian.schroeter(a)suse.com, afaerber(a)suse.com, dmueller(a)suse.com Found By: --- Blocker: --- obs-arm-7, -8 and -9 are often down in OBS these days due to kernel issues. One issue is a workqueue lockup: BUG: workqueue lockup - pool cpus=59 node=0 flags=0x0 nice=0 stuck for 92265s! -- You are receiving this mail because: You are the assignee for the bug.

5 hours, 52 minutes

1
7
0 0

[Bug 1182318] New: Superfluous mkinitrd / dracut calls at kernel post scriptlet

by bugzilla_noreply＠suse.com

https://bugzilla.suse.com/show_bug.cgi?id=1182318 Bug ID: 1182318 Summary: Superfluous mkinitrd / dracut calls at kernel post scriptlet 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: tiwai(a)suse.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- The current kernel rpm scriptlets have some room for optimization. Most notably, the initrd creation and boot loader setup are called at %post, and those can be postponed to %posttrans instead. The problem of multiple initrd creations and boot loader setups becomes more significant when another package touching initrd (e.g. coreutils) is installed together, or when the split kernel (kernel-default-extra) is installed together. As the initrd and the bootloeader setup are triggered in %post from both kernel-default and kernel-default-extra while the re-creation of the all initrd is triggered by another package update, this will end up two more extra calls that are superfluous. In addition to the above, the pre.sh script contains a few almost superfluous checks no one really cares. We may clean them up, too. -- You are receiving this mail because: You are the assignee for the bug.

2 months, 1 week

1
6
0 0

[kernel-bugs] [Bug 1175105] New: mdadm doesn't except partition for --add because of "dirt" in that partition of a fresh gpt table

by bugzilla_noreply＠suse.com

http://bugzilla.opensuse.org/show_bug.cgi?id=1175105 Bug ID: 1175105 Summary: mdadm doesn't except partition for --add because of "dirt" in that partition of a fresh gpt table Classification: openSUSE Product: openSUSE Distribution Version: Leap 15.1 Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Kernel Assignee: kernel-bugs(a)opensuse.org Reporter: ralf(a)czekalla.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- I'm about to migrate an important central private nextcloud server to 15.2. I'm use RAID1 for all my partitions and benefit from that with easy made clones with the help of mdadm by growing the number of raid-devices and adding a refreshed SSD with a new gpt partition table and cloned partitions descriptions. This worked for most of the six partitions but one. (It's not the first installation I transform with this idea. Did these processes already several times) This faulty one showed weird error messages I couldn't find a real good reason for, like ... ...on console: # mdadm --verbose /dev/md2 --add /dev/sdc5 mdadm: add new device failed for /dev/sdc5 as 4: Invalid argument # mdadm -E /dev/sdc5 /dev/sdc5: Magic : a92b4efc Version : 1.0 Feature Map : 0x9 Array UUID : 94bbbcd3:ad4d1b0b:dcd4d548:1af16050 Name : any:2 Creation Time : Fri Feb 2 20:09:03 2018 Raid Level : raid1 Raid Devices : 3 Avail Dev Size : 83892192 sectors (40.00 GiB 42.95 GB) Array Size : 41945984 KiB (40.00 GiB 42.95 GB) Used Dev Size : 83891968 sectors (40.00 GiB 42.95 GB) Super Offset : 83892208 sectors Unused Space : before=0 sectors, after=224 sectors State : active Device UUID : c9e17312:0069d580:42782958:8817e0f7 Internal Bitmap : -16 sectors from superblock Update Time : Mon Aug 10 18:09:21 2020 Bad Block Log : 512 entries available at offset -8 sectors - bad blocks present. Checksum : 7b5d72a - correct Events : 0 Device Role : spare Array State : AA. ('A' == active, '.' == missing, 'R' == replacing) First I was blinded by the "bad blocks present", but all devices checked out perfectly healthy in smart and also extended device scans didn't show any problems. Took me several hours to get through all this. dmesg: md: sdc5 does not have a valid v1.0 superblock, not importing! md: md_import_device returned -22 Also tried to --zero-superblock the partition of course. No change of behavior and still the above error message in dmesg remained. At the end I found a surprising hint on serverfault.com (https://serverfault.com/questions/696392/how-to-add-disk-back-to-raid-and-r…) from Oct. 2015 with a similar behavior that suggested to clean-up of the partition first with dd writing zeros (dd if=/dev/zero of=/dev/sdc5 status=progress) and try again later to add the last seemingly faulty partition. And long story short, this really worked. Somehow mdadm - and md behind - is choking on some dirt inside of partition blocks from old content before the disk/ssd was wiped with a new gpt partition table. (Of course with SSDs you try to prevent unnecessary writes and wiping every block of a disk first) I'm using md device type 1.0 here (in contrast to the serverfault.com case), where the RAID/md setup data is stored at the end of the partition. I had to wipe exactly this area at the end of the partition to add it afterwards successfully. Of course, no effect when doing this at the beginning of the partition (mentioned in the serverfault.com case) where md type 1.2 stores the md setup data. I think after 5 years this might need a clean up in mdadm or md device management. At least the error message should suggest to clean the partition first instead of this error message in dmesg. Also the --zero-superblock should wipe out the dirt beneath the superblock and not seemingly let some stuff leak here. Thanks Ralf -- You are receiving this mail because: You are the assignee for the bug.

2 months, 2 weeks

1
5
0 0

[kernel-bugs] [Bug 1176351] New: Audio device: Intel Corporation Device 02c8: not detected

by bugzilla_noreply＠suse.com

https://bugzilla.suse.com/show_bug.cgi?id=1176351 Bug ID: 1176351 Summary: Audio device: Intel Corporation Device 02c8: not detected 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: gp(a)suse.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- I've got a new notebook, Intel chipsets only, where everythings works - except for audio. It appears the audio chip/sound card are not detected by the kernel or initialized. lspci -v has: 00:1f.3 Audio device: Intel Corporation Device 02c8 (prog-if 80) Subsystem: Lenovo Device 22be Flags: fast devsel, IRQ 16, IOMMU group 13 Memory at ea33c000 (64-bit, non-prefetchable) [size=16K] Memory at ea000000 (64-bit, non-prefetchable) [size=1M] Capabilities: [50] Power Management version 3 Capabilities: [80] Vendor Specific Information: Len=14 <?> Capabilities: [60] MSI: Enable- Count=1/1 Maskable- 64bit+ Kernel modules: snd_hda_intel, snd_soc_skl, snd_sof_pci # lsmod | grep snd snd 114688 1 thinkpad_acpi soundcore 16384 1 snd # cat /proc/asound/cards --- no soundcards --- # dmesg | grep audio [ 18.072024] sof-audio-pci 0000:00:1f.3: DSP detected with PCI class/subclass/prog-if info 0x040380 [ 18.072026] sof-audio-pci 0000:00:1f.3: Digital mics found on Skylake+ platform, using SOF driver [ 18.072036] sof-audio-pci 0000:00:1f.3: enabling device (0004 -> 0006) [ 18.072179] sof-audio-pci 0000:00:1f.3: DSP detected with PCI class/subclass/prog-if 0x040380 [ 18.072267] sof-audio-pci 0000:00:1f.3: bound 0000:00:02.0 (ops i915_audio_component_bind_ops [i915]) [ 18.078993] sof-audio-pci 0000:00:1f.3: use msi interrupt mode [ 18.109492] sof-audio-pci 0000:00:1f.3: hda codecs found, mask 5 [ 18.109493] sof-audio-pci 0000:00:1f.3: using HDA machine driver skl_hda_dsp_generic now [ 18.109497] sof-audio-pci 0000:00:1f.3: DMICs detected in NHLT tables: 4 [ 18.109521] sof-audio-pci 0000:00:1f.3: Direct firmware load for intel/sof/sof-cml.ri failed with error -2 [ 18.109522] sof-audio-pci 0000:00:1f.3: error: request firmware intel/sof/sof-cml.ri failed err: -2 [ 18.109524] sof-audio-pci 0000:00:1f.3: error: failed to load DSP firmware -2 [ 18.110449] sof-audio-pci 0000:00:1f.3: error: sof_probe_work failed err: -2 [ 220.595600] sof-audio-pci 0000:00:1f.3: DSP detected with PCI class/subclass/prog-if info 0x040380 [ 220.595605] sof-audio-pci 0000:00:1f.3: Digital mics found on Skylake+ platform, using SOF driver [ 220.595786] sof-audio-pci 0000:00:1f.3: DSP detected with PCI class/subclass/prog-if 0x040380 [ 220.595899] sof-audio-pci 0000:00:1f.3: bound 0000:00:02.0 (ops i915_audio_component_bind_ops [i915]) [ 220.601386] sof-audio-pci 0000:00:1f.3: use msi interrupt mode [ 220.630638] sof-audio-pci 0000:00:1f.3: hda codecs found, mask 5 [ 220.630640] sof-audio-pci 0000:00:1f.3: using HDA machine driver skl_hda_dsp_generic now [ 220.630644] sof-audio-pci 0000:00:1f.3: DMICs detected in NHLT tables: 4 [ 220.630664] sof-audio-pci 0000:00:1f.3: Direct firmware load for intel/sof/sof-cml.ri failed with error -2 [ 220.630666] sof-audio-pci 0000:00:1f.3: error: request firmware intel/sof/sof-cml.ri failed err: -2 [ 220.630669] sof-audio-pci 0000:00:1f.3: error: failed to load DSP firmware -2 [ 220.631004] sof-audio-pci 0000:00:1f.3: error: sof_probe_work failed err: -2 -- You are receiving this mail because: You are the assignee for the bug.

4 months

1
15
0 0

[Bug 1180058] New: Please don't create /boot/do_purge_kernels on initial install

by bugzilla_noreply＠suse.com

https://bugzilla.suse.com/show_bug.cgi?id=1180058 Bug ID: 1180058 Summary: Please don't create /boot/do_purge_kernels on initial install 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: dcermak(a)suse.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- Currently the %post scriptlet of the kernel creates /boot/do_purge_kernels to trigger zypper's kernel purging. Could this be modified so that it only creates this file on upgrades and *not* on fresh installations? Currently this will cause zypper to try to purge old kernels on fresh installations. While that is short, it can cause noticeable delays until zypper can be used again, especially in resource constrained systems. Could the creation of this file be adjusted so that it is only created on upgrades and not on new installations? -- You are receiving this mail because: You are the assignee for the bug.

4 months

1
15
0 0

[Bug 1180917] New: kernel BUG at mm/huge_memory.c:2144!

by bugzilla_noreply＠suse.com

http://bugzilla.opensuse.org/show_bug.cgi?id=1180917 Bug ID: 1180917 Summary: kernel BUG at mm/huge_memory.c:2144! Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: S/390-64 OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Kernel Assignee: kernel-bugs(a)opensuse.org Reporter: azouhr(a)opensuse.org QA Contact: qa-bugs(a)suse.de CC: ihno(a)suse.com, ro(a)suse.de, sarah.kriesch(a)ibm.com Found By: --- Blocker: --- Recently, a number of packages fails to build and instead hangs with the command cc1plus. In a recent build, I found a kernel trace in a hanging worker: [ 608s] [ 596.875979] kernel BUG at mm/huge_memory.c:2144! [ 608s] [ 596.876290] monitor event: 0040 ilc:2 [#1] SMP [ 608s] [ 596.876374] Modules linked in: sha256_s390 sha_common overlay sd_mod t10_pi nls_iso8859_1 nls_cp437 vfat fat virtio_rng rng_core virtio_blk xfs btrfs blake2b_generic xor raid6_pq libcrc32c crc32_vx_s390 reiserfs squashfs fuse dm_snapshot dm_bufio dm_crypt dm_mod binfmt_misc loop sg scsi_mod [ 608s] [ 596.876666] CPU: 1 PID: 2660 Comm: cc1plus Not tainted 5.10.5-1-default #1 openSUSE Tumbleweed [ 608s] [ 596.876750] Hardware name: IBM 2964 N63 400 (KVM/Linux) [ 608s] [ 596.876797] Krnl PSW : 0704e00180000000 00000000e33fb9ea (__split_huge_pmd+0x62a/0xc30) [ 608s] [ 596.877158] R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:0 AS:3 CC:2 PM:0 RI:0 EA:3 [ 608s] [ 596.877328] Krnl GPRS: 0000000000000000 00000000b2b40215 0000000003c91000 fffffffffffff800 [ 608s] [ 596.877408] 0000000081691a00 00000000f2440237 00000000000000c0 0000000000000000 [ 608s] [ 596.877493] 0000000081691800 000003d083c91030 0000000086d81d48 000003ff71a40000 [ 608s] [ 596.877567] 0000000086c1c000 00000000e47c4268 00000000e33fb748 000003e003ef3a80 [ 608s] [ 596.877652] Krnl Code: 00000000e33fb9de: a71f0400 cghi %r1,1024 [ 608s] [ 596.877652] 00000000e33fb9e2: a784ff18 brc 8,00000000e33fb812 [ 608s] [ 596.877652] #00000000e33fb9e6: af000000 mc 0,0 [ 608s] [ 596.877652] >00000000e33fb9ea: a55b0602 oill %r5,1538 [ 608s] [ 596.877652] 00000000e33fb9ee: a7f4ff06 brc 15,00000000e33fb7fa [ 608s] [ 596.877652] 00000000e33fb9f2: e32010080004 lg %r2,8(%r1) [ 608s] [ 596.877652] 00000000e33fb9f8: a7210001 tmll %r2,1 [ 608s] [ 596.877652] 00000000e33fb9fc: a77401f1 brc 7,00000000e33fbdde [ 608s] [ 596.878162] Call Trace: [ 608s] [ 596.878190] [<00000000e33fb9ea>] __split_huge_pmd+0x62a/0xc30 [ 608s] [ 596.878257] ([<00000000e33fb6ca>] __split_huge_pmd+0x30a/0xc30) [ 608s] [ 596.878327] [<00000000e3379116>] zap_p4d_range+0x246/0xbb0 [ 608s] [ 596.878396] [<00000000e33808f6>] zap_page_range+0x1a6/0x2e0 [ 608s] [ 596.878458] [<00000000e33b2e14>] do_madvise.part.0+0x844/0xc70 [ 608s] [ 596.879153] [<00000000e33b32a8>] __s390x_sys_madvise+0x68/0x80 [ 608s] [ 596.879247] [<00000000e3c676bc>] system_call+0xe0/0x2ac [ 608s] [ 596.879347] Last Breaking-Event-Address: [ 608s] [ 596.879390] [<00000000e33fb9b2>] __split_huge_pmd+0x5f2/0xc30 [ 608s] [ 596.879465] ---[ end trace 50ad5147a244f7d2 ]--- I don't know if this is related boo#1163684 -- You are receiving this mail because: You are the assignee for the bug.

4 months

1
3
0 0

[kernel-bugs] [Bug 1177009] New: Leap 15.2 stopped working in KVM with ovmf-ia32 firmware

by bugzilla_noreply＠suse.com

http://bugzilla.opensuse.org/show_bug.cgi?id=1177009 Bug ID: 1177009 Summary: Leap 15.2 stopped working in KVM with ovmf-ia32 firmware Classification: openSUSE Product: openSUSE Distribution Version: Leap 15.2 Hardware: x86-64 OS: openSUSE Leap 15.2 Status: NEW Severity: Normal Priority: P5 - None Component: Kernel Assignee: kernel-bugs(a)opensuse.org Reporter: nwr10cst-oslnx(a)yahoo.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Firefox/78.0 Build Identifier: I'm reporting as a kernel bug, but it might be a bug elsewhere. And yes, I know that this is not a supported configuration. Situation: I have both Leap 15.2 and Tumbleweed installed side by side in a KVM virtual machine, using 32-bit efi for booting. Both Leap and Tumbleweed are 64-bit. I originally setup this VM under Leap 15.0 (as KVM host machine). Everything had been working well. However, I recently tried to boot the Leap 15.2 system in that VM, and it failed to boot. I see the kernel and initrd being loaded. And then there is a reset and I get back to the boot screen. However, Tumbleweed continues to boot without a problem on that virtual machine. I am booting with "grub2-i386-efi", which is installed for both Tumbleweed and for Leap 15.2. This does not appear to be a grub2 problem, because the kernel and initrd are being loaded. Before today, I most recently booted Leap 15.2 on Sept 22, and I updated it at that time. I then rebooted (successfully) to check after the update. I have not been able to boot since, until my workaround today. The KVM host is also running Leap 15.2, and I did apply some updates since Sept 22. My guess is that one of those updates affected how the virtualization is working. I have a similar install of Leap 15.2 on an external USB drive, and I have that setup so that it can boot with legacy BIOS, with 64-bit efi and with 32-bit efi. Testing with that, it also fails to boot the same virtual machine with 32-bit efi, bit it successfully boots with either legacy BIOS or with 64-bit efi. So it looks as if whatever is going wrong has to do with communication between the kernel and the 32-bit efi firmware. Booting the virtual machine to Tumbleweed, then setting up for rescue/chroot, I have installed kernel 5.8.11-1.gf4bb27a-default from the stable kernels repo. And now Leap 15.2 does boot successfully with that kernel. It does not boot with any of the 5.3.x kernels for Leap 15.2 that I have tested. Reproducible: Always -- You are receiving this mail because: You are the assignee for the bug.

4 months, 1 week

1
21
0 0

[Bug 1180749] New: AMD Ryzen 4800H Integrated Graphics brightness control not working as found in some Lenovo Legion 5 15ARH05

by bugzilla_noreply＠suse.com

http://bugzilla.opensuse.org/show_bug.cgi?id=1180749 Bug ID: 1180749 Summary: AMD Ryzen 4800H Integrated Graphics brightness control not working as found in some Lenovo Legion 5 15ARH05 Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: x86-64 OS: openSUSE Tumbleweed Status: NEW Severity: Normal Priority: P5 - None Component: Kernel Assignee: kernel-bugs(a)opensuse.org Reporter: antonyjr000(a)gmail.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- When using switchable graphics in Lenovo Legion 5 15ARH05, the AMD Renoir APU works along with NVIDIA Graphics(even non-free and prime works) but the brightness cannot be controlled by the Fn keys, Software or /sys/class/backlight I've tried setting all the kernel params like acpi_backlight=vender or native but the brightness control still does not work. I highly suspect it's a bug in the amdgpu kernel driver. For now nvidia graphics card works with brightness control. It is also worthy to note that cat /sys/class/backlight/*/actual_brightness always returns 311 and does not change even when executed echo 50 > /sys/class/backlight/*/brightness There are number of reports on this issue over the internet but nothing official. I've tried a lot of linux distros and none of them work and it seems it is broken even in the mainline kernel. I've also tried Kernel:HEAD version of the kernel without the nvidia graphics support but still the brightness control does not work. At the time writing I've booted linux 5.11-rc2 but the brightness control still does not work. -- You are receiving this mail because: You are the assignee for the bug.

4 months, 3 weeks

1
35
0 0

[Bug 1181479] New: LLVM 11 can not be built because of a kernel or hardware problem

by bugzilla_noreply＠suse.com

http://bugzilla.opensuse.org/show_bug.cgi?id=1181479 Bug ID: 1181479 Summary: LLVM 11 can not be built because of a kernel or hardware problem 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: sarah.kriesch(a)ibm.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Firefox/78.0 Build Identifier: OBS has got a failed build of LLVM 11 for s390x with the following message: [41008s] No buildstatus set, either the base system is broken (kernel/initrd/udev/glibc/bash/perl) [41008s] or the build host has a kernel or hardware problem... Reproducible: Always Steps to Reproduce: see: https://build.opensuse.org/package/live_build_log/openSUSE:Factory:zSystems… Actual Results: faild builds of LLVM11 because of a kernel or hardware problem on the base system (the VM) Expected Results: successful builds of LLVM11 in the OBS -- You are receiving this mail because: You are the assignee for the bug.

5 months, 1 week

1
9
0 0

[Bug 1182633] New: USB DAC does not work following OS upgrade (freq mismatch)

by bugzilla_noreply＠suse.com

http://bugzilla.opensuse.org/show_bug.cgi?id=1182633 Bug ID: 1182633 Summary: USB DAC does not work following OS upgrade (freq mismatch) Classification: openSUSE Product: openSUSE Distribution Version: Leap 15.2 Hardware: x86-64 OS: openSUSE Leap 15.2 Status: NEW Severity: Normal Priority: P5 - None Component: Kernel Assignee: kernel-bugs(a)opensuse.org Reporter: faorg-lists(a)yahoo.co.uk QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- User-Agent: Mozilla/5.0 (Windows NT 10.0; rv:78.0) Gecko/20100101 Firefox/78.0 Build Identifier: Having updated from Leap 15.1, my USB DAC has stopped working. Reproducible: Always Steps to Reproduce: 1. plug in the DAC 2. 3. Actual Results: Device not available in Pulse or Alsa. Kernel errors in syslog. Expected Results: Device should be available for audio playback. Still works in Tumbleweed. Feb 21 10:19:07 ada kernel: usb 1-1: 1:1: freq mismatch (RO clock): req 44100, clock runs @48000 More syslog output attached. see initial request in forums: https://forums.opensuse.org/showthread.php/550372-USB-DAC-no-longer-working -- You are receiving this mail because: You are the assignee for the bug.

6 months

1
20
0 0

2021

2020

openSUSE Kernel Bugs February 2021 ----- 2021 ----- October 2021 September 2021 August 2021 July 2021 June 2021 May 2021 April 2021 March 2021 February 2021 January 2021 ----- 2020 ----- December 2020 November 2020 October 2020 September 2020 August 2020 July 2020 June 2020 May 2020

openSUSE Kernel Bugs February 2021