December 2020 - 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, 21 minutes

1
7
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

[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

[kernel-bugs] [Bug 1176775] New: Problems after upgrade to openSUSE Leap 15.2

by bugzilla_noreply＠suse.com

https://bugzilla.suse.com/show_bug.cgi?id=1176775 Bug ID: 1176775 Summary: Problems after upgrade to openSUSE Leap 15.2 Classification: openSUSE Product: openSUSE Distribution Version: Leap 15.2 Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Kernel Assignee: kernel-bugs(a)opensuse.org Reporter: tbazant(a)suse.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- After upgrade from 15.1 to 15.2 on my Dell Latitude 5300 2-in-1, the following happened: * network link dies after ~ 20 minutes of operations (both ethernet & wi-fi) * audio problems (microphone did not work) * `journalctl -f` was fludded with the following message: "hid-sensor-hub 001F:8087:0AC2.0002: hid_field_extract() called with n (192)" -- You are receiving this mail because: You are the assignee for the bug.

7 months, 3 weeks

1
13
0 0

[Bug 1180316] New: [Build 20201222] openQA test fails in kdump_and_crash

by bugzilla_noreply＠suse.com

http://bugzilla.opensuse.org/show_bug.cgi?id=1180316 Bug ID: 1180316 Summary: [Build 20201222] openQA test fails in kdump_and_crash Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other URL: https://openqa.opensuse.org/tests/1523048/modules/kdum p_and_crash/steps/58 OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Kernel Assignee: kernel-bugs(a)opensuse.org Reporter: dimstar(a)opensuse.org QA Contact: qa-bugs(a)suse.de Found By: openQA Blocker: Yes ## Observation openQA test in scenario opensuse-Tumbleweed-JeOS-for-kvm-and-xen-x86_64-jeos-extra@64bit_virtio-2G fails in [kdump_and_crash](https://openqa.opensuse.org/tests/1523048/modules/kdump_an… After the update to kernel 5.10, kdump_and_crash fails crash: cannot determine length of symbol: log_end ## Test suite description Same as jeos, plus some more tests. ## Reproducible Fails since (at least) Build [20190311](https://openqa.opensuse.org/tests/877894) ## Expected result Last good: (unknown) (or more recent) ## Further details Always latest result in this scenario: [latest](https://openqa.opensuse.org/tests/latest?arch=x86_64&distri=opensus… -- You are receiving this mail because: You are the assignee for the bug.

7 months, 3 weeks

1
1
0 0

[Bug 1180346] New: Kernel 5.10.1 Broken

by bugzilla_noreply＠suse.com

http://bugzilla.opensuse.org/show_bug.cgi?id=1180346 Bug ID: 1180346 Summary: Kernel 5.10.1 Broken Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other OS: Other Status: NEW Severity: Critical Priority: P5 - None Component: Kernel Assignee: kernel-bugs(a)opensuse.org Reporter: dev.dorrejo(a)gmail.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- Created attachment 844698 --> http://bugzilla.opensuse.org/attachment.cgi?id=844698&action=edit Journalctl logs Hello i installed the kernel 5.10.1 and face the next issue: if i have a mouse/keyboard/FlashUSB connected to the machine, this cant boot up, stay on a loop boot process with the kernel and have to use REISUB to restart the machine. when the machine boot up, the wireless and bluethooth do no work. Wireless/bluethooth card: 00:14.3 Network controller: Intel Corporation Wireless-AC 9560 [Jefferson Peak] (rev 10) USB Controller: USB controller: Intel Corporation Cannon Lake PCH USB 3.1 xHCI Host Controller (rev 10) now, if i connect the usb after the machine boot up, this will work. next, if i shutdown/reboot the machine with the mouse/keyboard/FlashUSB connected, this will go again with the same boot loop process when is booting. -- You are receiving this mail because: You are the assignee for the bug.

8 months

1
5
0 0

[kernel-bugs] [Bug 1175646] New: After bios update, some keyboard function keys not recognized.

by bugzilla_noreply＠suse.com

http://bugzilla.opensuse.org/show_bug.cgi?id=1175646 Bug ID: 1175646 Summary: After bios update, some keyboard function keys not recognized. 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: zhonb(a)yahoo.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- I performed a bios update on a Dell precision 7530, which resolved my issue with the bug reported here: https://bugzilla.opensuse.org/show_bug.cgi?id=1175626 However, the new bios version (1.13.1) does not map the keyboard function keys correctly. Some work (e.g., volume control, keyboard backlight) and some don't (wifi toggle, screen brightness). Is there a way to map the new keyboard configuration in the bios so it works correctly in openSUSE? The keyboard functions correctly in windows. It does not work correctly in LEAP, tumbleweed or the latest fedora release. -- You are receiving this mail because: You are the assignee for the bug.

8 months

1
6
0 0

[Bug 1179971] New: iwlwifi - "Microcode SW error detected"

by bugzilla_noreply＠suse.com

http://bugzilla.opensuse.org/show_bug.cgi?id=1179971 Bug ID: 1179971 Summary: iwlwifi - "Microcode SW error detected" Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other OS: Other Status: NEW Severity: Major Priority: P5 - None Component: Kernel Assignee: kernel-bugs(a)opensuse.org Reporter: sb56637(a)gmail.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- Hi, I'm experiencing relatively frequent issues with my Intel WiFI connection dropping, at least once a day. (Lenovo T530 laptop) Just now I had it drop about 5 times in a row during a Zoom meeting. By "drop" I mean that NetworkManager shows no connection for about 10 seconds, and it has to re-associate. Of course multiple things could be going wrong given that it's WiFI, but my router is a high quality Mikrotik device giving a strong signal to my laptop, and I don't have major problems with WiFI spectrum congestion in this area. Also, the router log is showing corresponding events like "disconnected, ok", whereas in the past when I had problems with the actual connection quality it would throw an error indicating there was "major data loss". I also found some nasty looking errors with traces in dmesg that seem to correspond to the timeframes of the episondes, although I can't be sure because I put my machine to sleep every night and therefore the time stamps are wrong. I pulled the most interesting bits out and changed the MAC addresses. I should also mention that I usually have a Bluetooth headphone connected. Thanks for the help! -- You are receiving this mail because: You are the assignee for the bug.

8 months

1
11
0 0

2021

2020

openSUSE Kernel Bugs December 2020

2021

2020

openSUSE Kernel Bugs December 2020 ----- 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 December 2020