August 2021 - openSUSE Kernel Bugs - openSUSE Mailing Lists

[Bug 1189030] New: Please reestablish the usage of firmware and kernel/stable/standard with Leap 15.3
by bugzilla_noreply＠suse.com 04 Aug '21

04 Aug '21

http://bugzilla.opensuse.org/show_bug.cgi?id=1189030 Bug ID: 1189030 Summary: Please reestablish the usage of firmware and kernel/stable/standard with Leap 15.3 Classification: openSUSE Product: openSUSE Distribution Version: Leap 15.3 Hardware: x86-64 OS: openSUSE Leap 15.3 Status: NEW Severity: Critical 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: --- Hi Guys, I now use the stable/standard kernel for the last 20 years with openSUSE and Leap - always with the newest version including firmware. NEVER had an issue! Since today I can't update it any more on standard Leap 15.3. A newly introduced dependency with productversion string from June 2021. Yesterday I still could install 5.13.7-3.1 The firmware and dracut packages have some missing dependencies since about a week or so. Also not good. Both need to be fixed soon! Please! We need an actual kernel to run actual hardware and not some 5.3.oldtimer! Lucily I have not so many Leap systems any more anyway, but some of the more long-term installations are still needed - again with an actual kernel. If nothing is possible anymore with the whole "why ever move the kernel out of boot" idea then you need to create a Leap-compatible stable version parallel to the tumbleweed version. Stopping this support of kernel-stable for Leap unannounced is really bad! Introducing this in a subsubversion is also not a good idea. I would name this a strong regression - please handle it accordingly. Best regards Ralf -- You are receiving this mail because: You are the assignee for the bug.

1 3

[Bug 1188436] New: Fan running really loud upon loading any type of web content
by bugzilla_noreply＠suse.com 04 Aug '21

04 Aug '21

http://bugzilla.opensuse.org/show_bug.cgi?id=1188436 Bug ID: 1188436 Summary: Fan running really loud upon loading any type of web content Classification: openSUSE Product: openSUSE Distribution Version: Leap 15.3 Hardware: x86-64 OS: openSUSE Leap 15.3 Status: NEW Severity: Normal Priority: P5 - None Component: Kernel Assignee: kernel-bugs(a)opensuse.org Reporter: latinovicne(a)gmail.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- Created attachment 851078 --> http://bugzilla.opensuse.org/attachment.cgi?id=851078&action=edit Dmesg This bug is very very similar to bug number 1188187 on Tumbleweed. Basically, whenever I load any type of web-content in Firefox (Gmail included), the processor goes up and up until it loads and then falls to some 6-7%. So on that part, it looks OK. Problem is, the fan is running crazy loud and the longer I play web content, be it Spotify or Gmail or Youtube, the browser keeps working slower and slower and video or any pages start glitching. It gets progressively worse, until you kill any type of web content (that's the process showing in the top output). I'm attaching the usual files. What can I do next? -- You are receiving this mail because: You are the assignee for the bug.

1 7

[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 03 Aug '21

03 Aug '21

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.

1 5

[Bug 1184804] move kernel out of /boot
by bugzilla_noreply＠suse.com 03 Aug '21

03 Aug '21

https://bugzilla.suse.com/show_bug.cgi?id=1184804 https://bugzilla.suse.com/show_bug.cgi?id=1184804#c61 --- Comment #61 from Swamp Workflow Management <swamp(a)suse.de> --- SUSE-SU-2021:2599-1: An update that solves four vulnerabilities, contains three features and has 23 fixes is now available. Category: security (important) Bug References: 1065729,1085224,1094840,1152472,1152489,1155518,1170511,1179243,1180092,1183871,1184114,1184804,1185308,1185791,1186206,1187215,1187585,1188036,1188080,1188116,1188121,1188176,1188267,1188268,1188269,1188405,1188525 CVE References: CVE-2021-22555,CVE-2021-35039,CVE-2021-3609,CVE-2021-3612 JIRA References: SLE-17042,SLE-17043,SLE-17268 Sources used: SUSE Linux Enterprise Module for Realtime 15-SP2 (src): kernel-rt-5.3.18-45.3, kernel-rt_debug-5.3.18-45.3, kernel-source-rt-5.3.18-45.3, kernel-syms-rt-5.3.18-45.2 NOTE: This line indicates an update has been released for the listed product(s). At times this might be only a partial fix. If you have questions please reach out to maintenance coordination. -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1188410] Enabling f2fs
by bugzilla_noreply＠suse.com 03 Aug '21

03 Aug '21

https://bugzilla.suse.com/show_bug.cgi?id=1188410 https://bugzilla.suse.com/show_bug.cgi?id=1188410#c3 --- Comment #3 from Lukas Ocilka <locilka(a)suse.com> --- I have added a link to this bug to the feature request mentioned in comment #1. I'm sorry, but there's nothing else I can do about it. So far no decision, but point taken :) -- You are receiving this mail because: You are the assignee for the bug.

1 0

[Bug 1187701] Ten64 fails to boot (kernel panic in initramfs) from nvme after upgrade to kernel 5.3.18-59.5-default
by bugzilla_noreply＠suse.com 03 Aug '21

03 Aug '21

https://bugzilla.suse.com/show_bug.cgi?id=1187701 https://bugzilla.suse.com/show_bug.cgi?id=1187701#c29 --- Comment #29 from Joerg Roedel <jroedel(a)suse.com> --- I noted that there are differences in the memory configuration of the machine between the good and the broken kernel. Might this be an issue with the DTB? Can you please try to boot the broken kernel with a DTB from the good kernel and see whether this makes a difference? -- You are receiving this mail because: You are the assignee for the bug.

1 0

[Bug 1188327] kernel 5.13.1 is crashing on boot on armv7 due to 'Unhandled fault: alignment exception' in ecdsa_set_pub_key
by bugzilla_noreply＠suse.com 03 Aug '21

03 Aug '21

https://bugzilla.suse.com/show_bug.cgi?id=1188327 https://bugzilla.suse.com/show_bug.cgi?id=1188327#c21 Mian Yousaf Kaukab <yousaf.kaukab(a)suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|REOPENED |RESOLVED Resolution|--- |FIXED --- Comment #21 from Mian Yousaf Kaukab <yousaf.kaukab(a)suse.com> --- Queued upstream: 0469dede0eee crypto: ecc - handle unaligned input buffer in ecc_swap_digits -- You are receiving this mail because: You are the assignee for the bug.

1 0

[Bug 1188702] New: NXP i.MX8MQ not able to recognize eMMC
by bugzilla_noreply＠suse.com 03 Aug '21

03 Aug '21

http://bugzilla.opensuse.org/show_bug.cgi?id=1188702 Bug ID: 1188702 Summary: NXP i.MX8MQ not able to recognize eMMC Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: aarch64 OS: openSUSE Tumbleweed Status: NEW Severity: Normal Priority: P5 - None Component: Kernel Assignee: kernel-bugs(a)opensuse.org Reporter: peng.fan(a)nxp.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- CONFIG_REGULATOR_PFUZE100 please enable this config CONFIG_REGULATOR_PCA9450 this config is not for 8MQ, but it will be used by other i.MX boards. -- You are receiving this mail because: You are the assignee for the bug.

1 1

[Bug 1188436] Fan running really loud upon loading any type of web content
by bugzilla_noreply＠suse.com 02 Aug '21

02 Aug '21

https://bugzilla.suse.com/show_bug.cgi?id=1188436 https://bugzilla.suse.com/show_bug.cgi?id=1188436#c11 --- Comment #11 from Nenad Latinovi�� <latinovicne(a)gmail.com> --- Thanks :) You're the best :) I'll get on it in the morning and will upload in a day or two the results of the outputs. What do you need, dmesg and lspci only? -- You are receiving this mail because: You are the assignee for the bug.

1 0

[Bug 1188436] Fan running really loud upon loading any type of web content
by bugzilla_noreply＠suse.com 02 Aug '21

02 Aug '21

https://bugzilla.suse.com/show_bug.cgi?id=1188436 https://bugzilla.suse.com/show_bug.cgi?id=1188436#c10 --- Comment #10 from Takashi Iwai <tiwai(a)suse.com> --- Yeah, it is :) I mean, a simple sound playback (e.g. aplay or whatever), and check whether you get some unexpected high load that triggers fan running. If this happens reliably, it is likely related with the hardware and the driver. Or if the simple network load would trigger the fan spinning, we should doubt about the network stack. That is, the basic strategy is divide-and-conquer. -- You are receiving this mail because: You are the assignee for the bug.

1 0