July 2020 - openSUSE Kernel Bugs - openSUSE Mailing Lists

[kernel-bugs] [Bug 1173870] New: Internal error: synchronous parity or ECC error - while building on obs-arm-3 (ThunderX)
by bugzilla_noreply＠suse.com 24 Jul '20

24 Jul '20

http://bugzilla.opensuse.org/show_bug.cgi?id=1173870 Bug ID: 1173870 Summary: Internal error: synchronous parity or ECC error - while building on obs-arm-3 (ThunderX) Classification: openSUSE Product: openSUSE Distribution Version: Leap 15.2 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: --- I noticed a build failure on obs-arm-3 machine (ThunderX1) about 'synchronous parity or ECC error', while building a kernel-preempt package. Kernel traces: [11412s] [11360.577260] Internal error: synchronous parity or ECC error: 96000018 [#1] SMP [11412s] [11360.585784] Modules linked in: qemu_fw_cfg e1000 sd_mod nls_iso8859_1 nls_cp437 vfat fat virtio_rng virtio_blk virtio_mmio xfs btrfs xor xor_neon zlib_deflate raid6_pq libcrc32c reiserfs ext4 mbcache jbd2 squashfs lz4_decompress fuse dm_snapshot dm_bufio dm_crypt dm_mod binfmt_misc loop sg scsi_mod [11412s] [11360.619330] CPU: 4 PID: 26711 Comm: cc1 Not tainted 5.3.18-lp152.84-default #1 openSUSE Leap 15.2 (unreleased) [11412s] CC [M] drivers/net/ethernet/neterion/vxge/vxge-config.o [11412s] [11360.635110] Hardware name: linux,dummy-virt (DT) [11412s] [11360.655870] pstate: 80000005 (Nzcv daif -PAN -UAO) [11412s] [11360.659090] pc : __arch_copy_to_user+0x10c/0x220 [11412s] [11360.662182] lr : cp_new_stat+0x140/0x178 [11412s] [11360.672133] sp : ffff000017943cd0 [11412s] [11360.675914] x29: ffff000017943cd0 x28: ffff8000f99d9e80 [11412s] [11360.683608] x27: 0000000000000000 x26: 0000000000000000 [11412s] [11360.688386] x25: 0000000056000000 x24: 0000000000000015 [11412s] [11360.698666] x23: 0000000000000000 x22: 0000000017943d18 [11412s] [11360.722256] x21: ffff8000f99d9e80 x20: ffff000011679000 [11412s] [11360.726995] x19: ffff000017943dc0 x18: 0000000000000000 [11412s] [11360.731753] x17: 0000000000000000 x16: 0000000000000000 [11412s] [11360.736488] x15: 0000000000000000 x14: 0000000000000000 [11412s] [11360.741256] x13: 0000000000000000 x12: 0000000000000000 [11412s] [11360.745976] x11: 0000000000000000 x10: 00000000000000eb [11412s] [11360.750741] x9 : 000000005f003b39 x8 : 00000001000081a4 [11412s] [11360.755451] x7 : 00000000000a42b5 x6 : 0000000017943d30 [11412s] [11360.760184] x5 : 0000000017943d98 x4 : 0000000000000008 [11412s] [11360.764885] x3 : 000000000000fd10 x2 : fffffffffffffff8 [11412s] [11360.769629] x1 : ffff000017943d20 x0 : 0000000017943d18 [11412s] [11360.774332] Call trace: [11412s] [11360.776631] __arch_copy_to_user+0x10c/0x220 [11412s] [11360.780498] __se_sys_newfstat+0x58/0x88 [11412s] [11360.784049] __arm64_sys_newfstat+0x20/0x30 [11412s] [11360.788029] el0_svc_common.constprop.0+0xa0/0x1f8 [11412s] [11360.792513] el0_svc_handler+0x34/0x90 [11412s] [11360.796102] el0_svc+0x10/0x14 [11412s] [11360.799389] Code: a8c12027 a88120c7 d503201f d503201f (a8c12829) [11412s] [11360.804980] ---[ end trace 929f196ebb48dbcd ]--- [11412s] CC [M] drivers/net/ethernet/neterion/vxge/vxge-ethtool.o [11412s] gcc: internal compiler error: Segmentation fault (program cc1) [11412s] Please submit a full bug report, [11412s] with preprocessed source if appropriate. [11412s] See <https://bugs.opensuse.org/> for instructions. [11412s] make[6]: *** [../scripts/Makefile.build:282: drivers/net/ethernet/neterion/vxge/vxge-ethtool.o] Error 4 [11412s] make[6]: *** Waiting for unfinished jobs.... -- You are receiving this mail because: You are the assignee for the bug.

1 1

[kernel-bugs] [Bug 1173085] Realtek RTL8117 NIC not recognized by Leap 15.2 RC (regression from 15.1)
by bugzilla_noreply＠suse.com 23 Jul '20

23 Jul '20

https://bugzilla.suse.com/show_bug.cgi?id=1173085 https://bugzilla.suse.com/show_bug.cgi?id=1173085#c40 --- Comment #40 from Swamp Workflow Management <swamp(a)suse.de> --- SUSE-SU-2020:2027-1: An update that solves 19 vulnerabilities and has 162 fixes is now available. Category: security (important) Bug References: 1058115,1065729,1071995,1085030,1148868,1152472,1152489,1153274,1154353,1154492,1155518,1155798,1156395,1157169,1158050,1158242,1158265,1158748,1158765,1158983,1159781,1159867,1160947,1161495,1162002,1162063,1162400,1162702,1164648,1164777,1164780,1165211,1165975,1166985,1167104,1167651,1167773,1168230,1168779,1168838,1169021,1169094,1169194,1169514,1169681,1170011,1170284,1170442,1170617,1170774,1170879,1170891,1170895,1171150,1171189,1171191,1171219,1171220,1171246,1171417,1171513,1171529,1171530,1171662,1171688,1171699,1171732,1171739,1171743,1171759,1171828,1171868,1171904,1171915,1171982,1171983,1172017,1172046,1172061,1172062,1172063,1172064,1172065,1172066,1172067,1172068,1172069,1172073,1172086,1172095,1172169,1172170,1172208,1172223,1172342,1172343,1172344,1172365,1172366,1172374,1172391,1172393,1172394,1172453,1172458,1172467,1172484,1172537,1172543,1172687,1172719,1172739,1172751,1172759,1172775,1172781,1172782,1172783,1172814,1172823,1172841,1172871,1172938,1172939,117294 0,1172956,1172983,1172984,1172985,1172986,1172987,1172988,1172989,1172990,1172999,1173060,1173068,1173085,1173139,1173206,1173271,1173280,1173284,1173428,1173438,1173461,1173514,1173552,1173573,1173625,1173746,1173776,1173817,1173818,1173820,1173822,1173823,1173824,1173825,1173826,1173827,1173828,1173830,1173831,1173832,1173833,1173834,1173836,1173837,1173838,1173839,1173841,1173843,1173844,1173845,1173847,1173860,1173894,1174018,1174244,1174345 CVE References: CVE-2019-19462,CVE-2019-20810,CVE-2019-20812,CVE-2020-10711,CVE-2020-10732,CVE-2020-10751,CVE-2020-10766,CVE-2020-10767,CVE-2020-10768,CVE-2020-10773,CVE-2020-12656,CVE-2020-12769,CVE-2020-12771,CVE-2020-12888,CVE-2020-13143,CVE-2020-13974,CVE-2020-14416,CVE-2020-15393,CVE-2020-15780 Sources used: SUSE Linux Enterprise Module for Public Cloud 15-SP2 (src): kernel-azure-5.3.18-18.5.1, kernel-source-azure-5.3.18-18.5.1, kernel-syms-azure-5.3.18-18.5.1 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. You are the assignee for the bug.

1 0

[kernel-bugs] [Bug 1173402] Kernel delays boot by 12s if ip= option given
by bugzilla_noreply＠suse.com 23 Jul '20

23 Jul '20

https://bugzilla.suse.com/show_bug.cgi?id=1173402 https://bugzilla.suse.com/show_bug.cgi?id=1173402#c19 --- Comment #19 from Thomas Blume <thomas.blume(a)suse.com> --- (In reply to Fabian Vogt from comment #18) > No, that "$?" is wrong because there is an if preceding it. > Example: > if false; then false; fi > echo $? # 0 > > So using $? after an if is not working as expected here, it will only > indicate > the exit code of "do_dhcp -4" or "do_dhcp", but never of "do_dhcp -6". Argh, you are right, took me some time to see it, thanks! [...] > Yay, spaghetti... fully agreed > > Please note I appreciate your comments and will try to addess them as best > > as possible, but without breaking anything working. > > Unfortunately code changes here are very delicate since it has a big impact > > on netboot. > > Yep, this is the reverse-engineering part of cleanup ;-) > > I don't see any downside to merging the "# No ip lines default to dhcp" block > with the "# no ip option directed at our interface?" one down below, it would > make the various options and flows much more obvious. Ok, working on an update. -- You are receiving this mail because: You are the assignee for the bug.

1 0

[kernel-bugs] [Bug 1173402] Kernel delays boot by 12s if ip= option given
by bugzilla_noreply＠suse.com 23 Jul '20

23 Jul '20

https://bugzilla.suse.com/show_bug.cgi?id=1173402 https://bugzilla.suse.com/show_bug.cgi?id=1173402#c18 --- Comment #18 from Fabian Vogt <fvogt(a)suse.com> --- (In reply to Thomas Blume from comment #16) > (In reply to Fabian Vogt from comment #15) > > > Hm, did you check the latest code? > > > There is: > > > > > > if [ $? -eq 0 ] && [ -n "$(ls /tmp/leaseinfo.${netif}*)" ]; then > > > > > > the leasinfo file won't be there if there was no dhcp setup. > > > > Yes, but the use of $? there is still wrong AFAICT. > > Ah, you mean when there is no ip= option at all and no bootdev either? No, that "$?" is wrong because there is an if preceding it. Example: if false; then false; fi echo $? # 0 So using $? after an if is not working as expected here, it will only indicate the exit code of "do_dhcp -4" or "do_dhcp", but never of "do_dhcp -6". > But how should the network get set up via ifup then? > Using rd.neednet without specifying an interface would make the script bail > out early: > > --> > # Huh? No $1? > [ -z "$1" ] && exit 1 > --< > > There is the ifname boot parameter, but that is again covered in another > script, e.g. parse-ifname.sh. ifup.sh is called by udev for each interface, so $1 is always set. Just "rd.neednet=1" works fine. > > Not tested, but would that just move the "dhcp twice" case to netroot only? > > There's nothing which prevents the "# no ip option directed at our > > interface?" > > block from running after "# No ip lines default to dhcp" as the former > > doesn't > > touch /tmp/net.${netif}.up, does it? > > Maybe, I'm overlooking something but AFAICS, the second if would call > do_dhcp only when bootdev is set or ip=dhcp(6); Indeed, so that would probably work. It's totally not obvious though. > --> > if [ -e /tmp/net.bootdev ]; then > BOOTDEV=$(cat /tmp/net.bootdev) > if [ "$netif" = "$BOOTDEV" ] || [ "$BOOTDEV" = "$(cat > /sys/class/net/${netif}/address)" ]; then > load_ipv6 > do_dhcp > fi > else > if getargs 'ip=dhcp6'; then > load_ipv6 > do_dhcp -6 > fi > if getargs 'ip=dhcp'; then > do_dhcp -4 > fi > fi > --< > > So, it shouldn't run again after the "# No ip lines default to dhcp" part. > But it would write did-setup, which is fine since it could have been setup > in "# No ip lines default to dhcp". Yay, spaghetti... > Please note I appreciate your comments and will try to addess them as best > as possible, but without breaking anything working. > Unfortunately code changes here are very delicate since it has a big impact > on netboot. Yep, this is the reverse-engineering part of cleanup ;-) I don't see any downside to merging the "# No ip lines default to dhcp" block with the "# no ip option directed at our interface?" one down below, it would make the various options and flows much more obvious. -- You are receiving this mail because: You are the assignee for the bug.

1 0

[kernel-bugs] [Bug 1174047] Weird load behaviour with kernel-5.3.18-lp152.20.7-default
by bugzilla_noreply＠suse.com 22 Jul '20

22 Jul '20

https://bugzilla.suse.com/show_bug.cgi?id=1174047 https://bugzilla.suse.com/show_bug.cgi?id=1174047#c5 Takashi Iwai <tiwai(a)suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #5 from Takashi Iwai <tiwai(a)suse.com> --- The *.26 kernel is built from the very same source as *.20 but just signed with a correct key (*.20 broke some secure boot-related stuff). So it's no wonder that it didn't work. A patch included recently was identified to be the fix for this problem, so the next kernel should work. I close this now with that promise; if the next one is still broken, please open. Thanks. -- You are receiving this mail because: You are the assignee for the bug.

1 0

[kernel-bugs] [Bug 1174391] /lib/firmware update causes Dell 7300 to hang on boot after loading initrd ramdisk
by bugzilla_noreply＠suse.com 22 Jul '20

22 Jul '20

https://bugzilla.suse.com/show_bug.cgi?id=1174391 https://bugzilla.suse.com/show_bug.cgi?id=1174391#c1 Takashi Iwai <tiwai(a)suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |janm2(a)gmx.de, | |tiwai(a)suse.com Flags| |needinfo?(janm2(a)gmx.de) --- Comment #1 from Takashi Iwai <tiwai(a)suse.com> --- It's a known problem regarding the AMDGPU firmware update that broke with this kernel-firmware update, but your case doesn't seem that. Or is it with AMDGPU? Other than that, the only other changes in this update were Realtek rtl8125b stuff, but this doesn't look matching with yours (with Realtek but different chips). Could you try to identify which kernel-firmware-xxx package may break things? It'd be greatly appreciated if we can know that. You can save initrd file beforehand (just copy /boot/initrd-xxx to /boot/initrd-xxx.old), and choose it in GRUB menu for recovery, too. -- You are receiving this mail because: You are the assignee for the bug.

1 0

[kernel-bugs] [Bug 1174116] New: Kernel repeatedly crashing
by bugzilla_noreply＠suse.com 20 Jul '20

20 Jul '20

https://bugzilla.suse.com/show_bug.cgi?id=1174116 Bug ID: 1174116 Summary: Kernel repeatedly crashing Classification: openSUSE Product: openSUSE Distribution Version: Leap 15.2 Hardware: Other OS: Other Status: NEW Severity: Major Priority: P5 - None Component: Kernel Assignee: kernel-bugs(a)opensuse.org Reporter: msvec(a)suse.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- Created attachment 839676 --> https://bugzilla.suse.com/attachment.cgi?id=839676&action=edit kernel log This is the latest 15.2 with kernel-default-5.3.18-lp152.20.7.1.x86_64 The only thing I need to do was: - kinit - access a file in the NFS directory See the attached crash log -- You are receiving this mail because: You are the assignee for the bug.

1 21

[kernel-bugs] [Bug 1173448] Webcam(earlier working) doesn't work now. Sony Vaio
by bugzilla_noreply＠suse.com 20 Jul '20

20 Jul '20

https://bugzilla.suse.com/show_bug.cgi?id=1173448 https://bugzilla.suse.com/show_bug.cgi?id=1173448#c7 --- Comment #7 from Takashi Iwai <tiwai(a)suse.com> --- You can try just installing the latest openSUSE Leap 15.1 kernel, e.g. from OBS Kernel:openSUSE-15.1 repo http://download.opensuse.org/repositories/Kernel:/openSUSE-15.1/standard/ Grab kernel-default.rpm, and install it manually via zypper zypper in --oldpackage kernel-default-4.12*.rpm You might need to add --nodeps option for ignoring the kernel-firmware dependency. Then reboot with that kernel (go "Advanced menu" in GRUB menu and choose it). Similarly, try Leap 15.2 kernel from http://download.opensuse.org/repositories/Kernel:/openSUSE-15.2/standard/ too -- You are receiving this mail because: You are the assignee for the bug.

1 0

[kernel-bugs] [Bug 1173402] Kernel delays boot by 12s if ip= option given
by bugzilla_noreply＠suse.com 20 Jul '20

20 Jul '20

https://bugzilla.suse.com/show_bug.cgi?id=1173402 https://bugzilla.suse.com/show_bug.cgi?id=1173402#c17 --- Comment #17 from Thomas Blume <thomas.blume(a)suse.com> --- (In reply to Thomas Blume from comment #16) > (In reply to Fabian Vogt from comment #15) > > > Hm, did you check the latest code? > > > There is: > > > > > > if [ $? -eq 0 ] && [ -n "$(ls /tmp/leaseinfo.${netif}*)" ]; then > > > > > > the leasinfo file won't be there if there was no dhcp setup. > > > > Yes, but the use of $? there is still wrong AFAICT. > > Ah, you mean when there is no ip= option at all and no bootdev either? > But how should the network get set up via ifup then? > Using rd.neednet without specifying an interface would make the script bail > out early: > > --> > # Huh? No $1? > [ -z "$1" ] && exit 1 > --< > > There is the ifname boot parameter, but that is again covered in another > script, e.g. parse-ifname.sh. Sorry, that reply was incomplete, $? is also needed in the do_dhcp case, because the function has parts where the return code is set explicitly. checking for leaseinfo is not the same, because this file is created by wicked in yet another function (dhcp_wicked_apply). -- You are receiving this mail because: You are the assignee for the bug.

1 0

[kernel-bugs] [Bug 1173402] Kernel delays boot by 12s if ip= option given
by bugzilla_noreply＠suse.com 20 Jul '20

20 Jul '20

https://bugzilla.suse.com/show_bug.cgi?id=1173402 https://bugzilla.suse.com/show_bug.cgi?id=1173402#c16 --- Comment #16 from Thomas Blume <thomas.blume(a)suse.com> --- (In reply to Fabian Vogt from comment #15) > > Hm, did you check the latest code? > > There is: > > > > if [ $? -eq 0 ] && [ -n "$(ls /tmp/leaseinfo.${netif}*)" ]; then > > > > the leasinfo file won't be there if there was no dhcp setup. > > Yes, but the use of $? there is still wrong AFAICT. Ah, you mean when there is no ip= option at all and no bootdev either? But how should the network get set up via ifup then? Using rd.neednet without specifying an interface would make the script bail out early: --> # Huh? No $1? [ -z "$1" ] && exit 1 --< There is the ifname boot parameter, but that is again covered in another script, e.g. parse-ifname.sh. > > Those parameters are a bit different, bootdev is documented as: > > --> > > bootdev=<interface> > > specify network interface to use routing and netroot information > > from. Required if multiple ip= lines are used. > > --< > > > > So it is bound to the netroot case and a specific interface, whereas > > rd.neednet does the network setup unconditionally. > > That seems to be working with netroot, but not depend on netroot. > It doesn't say that bootdev can only be specified if multiple ip= options > are set, but only that it is mandatory in that case. Hm, right, even though it doesn't make sense it is allowed to set rd.neednet together with bootdev. But in any case the bootdev option requires an specific interface name while in the rd.neednet only case $iface should be empty. > Not tested, but would that just move the "dhcp twice" case to netroot only? > There's nothing which prevents the "# no ip option directed at our > interface?" > block from running after "# No ip lines default to dhcp" as the former > doesn't > touch /tmp/net.${netif}.up, does it? Maybe, I'm overlooking something but AFAICS, the second if would call do_dhcp only when bootdev is set or ip=dhcp(6); --> if [ -e /tmp/net.bootdev ]; then BOOTDEV=$(cat /tmp/net.bootdev) if [ "$netif" = "$BOOTDEV" ] || [ "$BOOTDEV" = "$(cat /sys/class/net/${netif}/address)" ]; then load_ipv6 do_dhcp fi else if getargs 'ip=dhcp6'; then load_ipv6 do_dhcp -6 fi if getargs 'ip=dhcp'; then do_dhcp -4 fi fi --< So, it shouldn't run again after the "# No ip lines default to dhcp" part. But it would write did-setup, which is fine since it could have been setup in "# No ip lines default to dhcp". Please note I appreciate your comments and will try to addess them as best as possible, but without breaking anything working. Unfortunately code changes here are very delicate since it has a big impact on netboot. -- You are receiving this mail because: You are the assignee for the bug.

1 0