March 2021 - openSUSE Kernel Bugs - openSUSE Mailing Lists

[Bug 1183056] New: Leap 15.3 kernel cannot load on a system with 32-bit UEFI
by bugzilla_noreply＠suse.com 16 Jun '21

16 Jun '21

http://bugzilla.opensuse.org/show_bug.cgi?id=1183056 Bug ID: 1183056 Summary: Leap 15.3 kernel cannot load on a system with 32-bit UEFI 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: 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 see this as related to bug 1172292 It seems impossible to load a Leap 15.3 kernel with 32-bit UEFI firmware. I tried several ways, but could not boot the installer. I eventually installed to a KVM virtual machine using legacy booting. I then took the installed memory image, and converted that to using 32-bit UEFI with ovmf-ia32-{code,vars}.bin firmware. And that still would not boot. I now have it successfully booting with kernel-default-5.3.18-lp152.63.1 which is a kernel from Leap 15.2. But it will not boot with the Leap 15.3 kernel. I'll grant that this is not an officially supported setup. Reproducible: Always -- You are receiving this mail because: You are the assignee for the bug.

1 4

[Bug 1181479] New: LLVM 11 can not be built because of a kernel or hardware problem
by bugzilla_noreply＠suse.com 12 May '21

12 May '21

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.

1 9

[Bug 1183824] New: When booting, only one cpu comes online on RPI3
by bugzilla_noreply＠suse.com 03 May '21

03 May '21

http://bugzilla.opensuse.org/show_bug.cgi?id=1183824 Bug ID: 1183824 Summary: When booting, only one cpu comes online on RPI3 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: dillon.ang.h(a)gmail.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- Since Tumbleweed 20210317, when booting up a Raspberry Pi 3, only one of the four CPUs comes online. I tested this on a clean install from the ISO and on a Zypper dup from 20210223. dmesg output: [ 0.005122] smp: Bringing up secondary CPUs ... [ 5.041231] CPU1: failed to come online [ 5.041253] CPU1: failed in unknown state : 0x0 [ 10.083487] CPU2: failed to come online [ 10.083513] CPU2: failed in unknown state : 0x0 [ 15.126053] CPU3: failed to come online [ 15.126078] CPU3: failed in unknown state : 0x0 [ 15.126172] smp: Brought up 1 node, 1 CPU [ 15.126186] SMP: Total of 1 processors activated. I will run further tests with an older kernel and report back. -- You are receiving this mail because: You are the assignee for the bug.

1 3

[Bug 1184088] New: frequent usb resets starting with 5.11-rc7, 5.11-rc6 was fine
by bugzilla_noreply＠suse.com 03 May '21

03 May '21

https://bugzilla.suse.com/show_bug.cgi?id=1184088 Bug ID: 1184088 Summary: frequent usb resets starting with 5.11-rc7, 5.11-rc6 was fine 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: dmueller(a)suse.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- Some change between 5.11-rc6 and 5.11-rc7 is causing frequently storms of usb resets, significantly eating cpu power: [Sa M�r 27 20:17:47 2021] usb 3-1.1.3: reset high-speed USB device number 6 using xhci_hcd [Sa M�r 27 20:17:52 2021] usb 3-1.1.3: reset high-speed USB device number 6 using xhci_hcd [Sa M�r 27 20:17:58 2021] usb 3-1.1.3: reset high-speed USB device number 6 using xhci_hcd [Sa M�r 27 20:18:03 2021] usb 3-1.1.3: reset high-speed USB device number 6 using xhci_hcd [Sa M�r 27 20:18:09 2021] usb 3-1.1.3: reset high-speed USB device number 6 using xhci_hcd [Sa M�r 27 20:18:15 2021] usb 3-1.1.3: reset high-speed USB device number 6 using xhci_hcd [Sa M�r 27 20:18:20 2021] usb 3-1.1.3: reset high-speed USB device number 6 using xhci_hcd it stops usually after turning off/on the monitor (the usb hub this is connected to is builtin to my display), but sometimes it just stops by itself, and then at some later point in time resumes again. No idea what exactly triggers it, but I've never seen this with 5.11-rc6 or below. lsusb -t -v for this sub tree is: /: Bus 03.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/4p, 480M ID 1d6b:0002 Linux Foundation 2.0 root hub |__ Port 1: Dev 18, If 0, Class=Hub, Driver=hub/6p, 480M ID 0451:8442 Texas Instruments, Inc. |__ Port 6: Dev 25, If 0, Class=, Driver=, 480M ID 0451:82ee Texas Instruments, Inc. |__ Port 2: Dev 21, If 3, Class=Human Interface Device, Driver=usbhid, 12M ID 047f:c025 Plantronics, Inc. |__ Port 2: Dev 21, If 1, Class=Audio, Driver=snd-usb-audio, 12M ID 047f:c025 Plantronics, Inc. |__ Port 2: Dev 21, If 2, Class=Audio, Driver=snd-usb-audio, 12M ID 047f:c025 Plantronics, Inc. |__ Port 2: Dev 21, If 0, Class=Audio, Driver=snd-usb-audio, 12M ID 047f:c025 Plantronics, Inc. |__ Port 5: Dev 24, If 0, Class=Human Interface Device, Driver=usbhid, 480M ID 0451:82ff Texas Instruments, Inc. |__ Port 1: Dev 19, If 0, Class=Hub, Driver=hub/4p, 480M ID 0bda:5411 Realtek Semiconductor Corp. RTS5411 Hub |__ Port 3: Dev 23, If 2, Class=Audio, Driver=snd-usb-audio, 480M ID 046d:0825 Logitech, Inc. Webcam C270 |__ Port 3: Dev 23, If 0, Class=Video, Driver=uvcvideo, 480M ID 046d:0825 Logitech, Inc. Webcam C270 |__ Port 3: Dev 23, If 3, Class=Audio, Driver=snd-usb-audio, 480M ID 046d:0825 Logitech, Inc. Webcam C270 |__ Port 3: Dev 23, If 1, Class=Video, Driver=uvcvideo, 480M ID 046d:0825 Logitech, Inc. Webcam C270 -- You are receiving this mail because: You are the assignee for the bug.

1 6

[Bug 1183009] New: Some armv6/7 builds on OBS fail due to kernel 5.11 modules not being loaded properly
by bugzilla_noreply＠suse.com 29 Apr '21

29 Apr '21

http://bugzilla.opensuse.org/show_bug.cgi?id=1183009 Bug ID: 1183009 Summary: Some armv6/7 builds on OBS fail due to kernel 5.11 modules not being loaded properly Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: armv7 OS: Other Status: NEW Severity: Major 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: afaerber(a)suse.com, dmueller(a)suse.com, fvogt(a)suse.com Found By: --- Blocker: --- Since last Factory check-in, which includes kernel upgrade to 5.11, we see some armv6/7 JeOS images build failing with 'mount' which does not know 'vfat' or 'btrfs'. Also, we have some guest kernel traces such as: [ 44s] [ 8.996985] vfat: section 4 reloc 1 sym '_raw_spin_lock': relocation 28 out of range (0xbf00901c -> 0xc101cb28) -- You are receiving this mail because: You are the assignee for the bug.

1 5

[Bug 1182633] New: USB DAC does not work following OS upgrade (freq mismatch)
by bugzilla_noreply＠suse.com 24 Apr '21

24 Apr '21

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.

1 20

[Bug 1183838] New: Full resolution of the monitor no longer available in 5.11 kernels with i9-9900K and Intel display driver
by bugzilla_noreply＠suse.com 12 Apr '21

12 Apr '21

http://bugzilla.opensuse.org/show_bug.cgi?id=1183838 Bug ID: 1183838 Summary: Full resolution of the monitor no longer available in 5.11 kernels with i9-9900K and Intel display driver 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: mciobanu(a)outlook.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:85.0) Gecko/20100101 Firefox/85.0 Build Identifier: I use TumbleWeed as my main OS, and also have a separate TumbleWeed partition to test the updates first. So my main system is still on 5.10.16-1-default, while the test system is on 5.11.6-1, after trying 5.11.2-1. There is no graphic card besides the one embedded in the CPU, with the built-in drivers, which so far has been good enough for me. On the test system, my 3440x1440 monitor is now seen as 2560x1080 (or sometimes 1024x768 or 1600x900), in the sense that you cannot set a higher resolution. The reason I'm saying this has to do with the kernel rather than with X, is what happens at boot: I use "nosplash", to see the boot messages. On the old/main system, there is some text with a large font for less than 1 second, and then it enters a text mode with around 90 lines, and then the X graphics mode of 3440x1440. On the updated system, the first boot goes the same in the text modes, but at reboots the text mode is really some 77 visible lines (or sometimes fewer), but it still thinks there are 90, so what happens is the bottom lines and right columns aren't shown. (Well, the bottom visible line is truncated, only the top of the characters are seen.) I think these text modes are configured before X had a chance to do anything, so it looks more like some "garbage" left in some memory from a previous run that decides the resolution. It didn't occur to me to try the older kernel (5.10.16-1) when I saw that things no longer worked as expected with 5.11.6-1, which would have made it clearer if the issue is with the kernel or not. Now I'm not sure how to go about installing an older kernel, as I don't see it in YaST. However, there is a workaround of sorts: Disconnect the DP cable and reconnect it. Then I can set the resolution to 3440x1440@60. This seems to make the text mode (e.g. Ctrl+Alt+F1) unavailable, though. Reproducible: Always Steps to Reproduce: 1. Start TumbleWeed with "nosplash" on a 3440x1440 monitor (Samsung CF791) and TW as of 2021.03.21 2. Reboot, once it started Actual Results: 1. In text mode during boot, bottom lines are not visible. 2. In graphics mode the resolution is something smaller (usually 2560x1080) and cannot be made 3440x1440 Expected Results: 1. All text lines should be visible during boot (except maybe the first boot). 2. It should be possible to set the resolution to 3440x1440@60 3. The resolution should be kept between reboots. -- You are receiving this mail because: You are the assignee for the bug.

1 3

[Bug 1182377] New: kernel-firmware-nvidia-20200208 lead to crash with kernel 5.10.x
by bugzilla_noreply＠suse.com 11 Apr '21

11 Apr '21

http://bugzilla.opensuse.org/show_bug.cgi?id=1182377 Bug ID: 1182377 Summary: kernel-firmware-nvidia-20200208 lead to crash with kernel 5.10.x Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: x86-64 OS: openSUSE Tumbleweed Status: NEW Severity: Major Priority: P5 - None Component: Kernel Assignee: kernel-bugs(a)opensuse.org Reporter: bruno(a)ioda-net.ch QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- With TW snapshot 20200215 come with kernel-firmware version kernel-firmware-nvidia = 20210208-1.1 Once rebooted the computer start to show kernel rip error typically like Feb 17 16:14:14 qt-kt kernel: snd_hda_intel 0000:01:00.1: azx_get_response timeout, switching to polling mode: last cmd=0x000f0000 Feb 17 16:14:14 qt-kt kernel: snd_hda_intel 0000:01:00.1: spurious response 0x8100073:0x0, last cmd=0x0f0000 Feb 17 16:14:14 qt-kt kernel: snd_hda_intel 0000:01:00.1: spurious response 0x0:0x0, last cmd=0x0f0000 Feb 17 16:14:14 qt-kt kernel: snd_hda_intel 0000:01:00.1: spurious response 0x0:0x0, last cmd=0x0f0000 Feb 17 16:14:14 qt-kt kernel: snd_hda_intel 0000:01:00.1: spurious response 0x0:0x0, last cmd=0x0f0000 Feb 17 16:14:14 qt-kt kernel: snd_hda_intel 0000:01:00.1: spurious response 0x0:0x0, last cmd=0x0f0000 Feb 17 16:14:14 qt-kt kernel: snd_hda_intel 0000:01:00.1: spurious response 0x510bda50:0xffff9b87, last cmd=0x000000 Feb 17 16:14:14 qt-kt kernel: snd_hda_intel 0000:01:00.1: spurious response 0x510bda50:0xffff9b87, last cmd=0x000000 Feb 17 16:14:14 qt-kt kernel: snd_hda_intel 0000:01:00.1: spurious response 0x513b2c60:0xffff9b87, last cmd=0x000000 Feb 17 16:14:14 qt-kt kernel: snd_hda_intel 0000:01:00.1: spurious response 0x0:0x0, last cmd=0x0f0000 Feb 17 16:14:14 qt-kt kernel: snd_hda_intel 0000:01:00.1: spurious response 0xf79f5536:0x7, last cmd=0x000000 Feb 17 16:14:14 qt-kt kernel: snd_hda_intel 0000:01:00.1: spurious response 0xf554b000:0x7f79, rp = 44, wp = 0 Feb 17 16:14:14 qt-kt kernel: ------------[ cut here ]------------ Feb 17 16:14:14 qt-kt kernel: BUG? Feb 17 16:14:14 qt-kt kernel: WARNING: CPU: 7 PID: 1894 at sound/hda/hdac_controller.c:215 snd_hdac_bus_update_rirb.cold+0x24/0x5b [snd_hda_core] Feb 17 16:14:14 qt-kt kernel: Modules linked in: nf_log_ipv6 xt_recent ipt_REJECT nf_reject_ipv4 xt_multiport xt_comment xt_physdev xt_set xt_hashlimit xt_addrtype xt_mark xt_CT nfnetlink_log xt_NFLOG nf_log_ipv4 nf_log_common xt_LOG nf_nat_tftp nf_nat_snmp_basic nf_conntrack_snmp nf_nat_sip nf_nat_pptp nf_nat_irc nf_nat_h323 nf_nat_ftp nf_nat_amanda ts_kmp nf_conntrack_amanda nf_conntrack_sane nf_conntrack_tftp nf_conntrack_sip nf_conntrack_pptp nf_conntrack_netlink nf_conntrack_netbios_ns nf_conntrack_broadcast nf_conntrack_irc nf_conntrack_h323 nf_conntrack_ftp cmac algif_hash algif_skcipher af_alg tun af_packet ip6table_mangle ip6table_nat ip6table_raw vboxnetadp(O) vboxnetflt(O) ip6table_filter ip6_tables ip_set_hash_net ip_set nfnetlink xt_tcpudp xt_conntrack iptable_mangle vboxdrv(O) iptable_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 iptable_raw dmi_sysfs iptable_filter ip_tables x_tables bpfilter bnep nvidia_drm(POE) nvidia_modeset(POE) nvidia_uvm(POE) x86_pkg_temp_thermal xpad Feb 17 16:14:14 qt-kt kernel: intel_powerclamp iTCO_wdt coretemp ff_memless intel_pmc_bxt iwlmvm nvidia(POE) kvm_intel ee1004 iTCO_vendor_support mei_hdcp mei_wdt ppdev dell_laptop intel_rapl_msr ledtrig_audio cdc_mbim dell_smm_hwmon drm_kms_helper kvm cdc_wdm mac80211 btusb btrtl btbcm dell_wmi cec cdc_ncm uvcvideo btintel libarc4 pcspkr dell_smbios irqbypass rc_core cdc_ether dcdbas snd_usb_audio sparse_keymap videobuf2_vmalloc i2c_i801 efi_pstore dell_wmi_descriptor videobuf2_memops qcserial iwlwifi usbnet mxm_wmi videobuf2_v4l2 bluetooth snd_usbmidi_lib usb_wwan intel_wmi_thunderbolt videobuf2_common e1000e mei_me wmi_bmof snd_rawmidi i2c_smbus processor_thermal_device ecdh_generic mii usbserial fb_sys_fops joydev ecc snd_seq_device videodev syscopyarea sysfillrect cfg80211 mei sysimgblt intel_rapl_common intel_pch_thermal ie31200_edac mc thermal tiny_power_button intel_soc_dts_iosf parport_pc dell_smo8800 parport int3403_thermal int3402_thermal int3400_thermal int340x_thermal_zone dell_rbtn Feb 17 16:14:14 qt-kt kernel: acpi_thermal_rel rfkill button acpi_pad ac nls_iso8859_1 nls_cp437 vfat fat drm fuse configfs hid_logitech_hidpp uas usb_storage hid_logitech_dj dm_crypt hid_generic usbhid xhci_pci xhci_pci_renesas xhci_hcd crct10dif_pclmul crc32_pclmul ghash_clmulni_intel rtsx_pci_sdmmc aesni_intel mmc_core glue_helper crypto_simd cryptd nvme serio_raw nvme_core usbcore rtsx_pci battery video wmi btrfs blake2b_generic libcrc32c crc32c_intel xor raid6_pq dm_mirror dm_region_hash dm_log snd_hda_intel snd_intel_dspcfg soundwire_intel soundwire_generic_allocation snd_soc_core snd_compress snd_pcm_dmaengine soundwire_cadence soundwire_bus snd_hda_codec snd_hwdep snd_hda_core snd_pcm snd_timer snd soundcore l2tp_ppp l2tp_netlink l2tp_core ip6_udp_tunnel udp_tunnel pppox ppp_generic slhc sg dm_multipath dm_mod scsi_dh_rdac scsi_dh_emc scsi_dh_alua br_netfilter bridge stp llc msr efivarfs Feb 17 16:14:14 qt-kt kernel: CPU: 7 PID: 1894 Comm: Xorg.bin Tainted: P OE 5.10.16-1-default #1 openSUSE Tumbleweed Feb 17 16:14:14 qt-kt kernel: Hardware name: Dell Inc. Precision 7510/0YH43H, BIOS 1.21.3 08/04/2020 Feb 17 16:14:14 qt-kt kernel: RIP: 0010:snd_hdac_bus_update_rirb.cold+0x24/0x5b [snd_hda_core] Feb 17 16:14:14 qt-kt kernel: Code: db e9 52 a1 ff ff 48 8b 3b 41 89 e9 44 89 e9 44 89 fa 48 c7 c6 f0 0c 3d c0 e8 93 ed c4 db 48 c7 c7 7d cc 3c c0 e8 d0 23 c2 db <0f> 0b 0f b7 83 90 03 00 00 e9 2f bf ff ff 48 8b 3b 44 89 e9 44 89 Feb 17 16:14:14 qt-kt kernel: RSP: 0018:ffffba2d0061f4b0 EFLAGS: 00010082 Feb 17 16:14:14 qt-kt kernel: RAX: 0000000000000000 RBX: ffff9b947992a018 RCX: ffff9b96045dab88 Feb 17 16:14:14 qt-kt kernel: RDX: 00000000ffffffd8 RSI: 0000000000000027 RDI: ffff9b96045dab80 Feb 17 16:14:14 qt-kt kernel: RBP: 0000000000000000 R08: ffff9b964474fc28 R09: 0000000000013ffb Feb 17 16:14:14 qt-kt kernel: R10: 00000000ffffc000 R11: 3fffffffffffffff R12: ffff9b947992a018 Feb 17 16:14:14 qt-kt kernel: R13: 0000000000007f79 R14: 00000000fffe0000 R15: 00000000f554b000 Feb 17 16:14:14 qt-kt kernel: FS: 00007f521a843940(0000) GS:ffff9b96045c0000(0000) knlGS:0000000000000000 Feb 17 16:14:14 qt-kt kernel: CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 Feb 17 16:14:14 qt-kt kernel: CR2: 00007f31b8031c68 CR3: 0000000271fe2005 CR4: 00000000003706e0 Feb 17 16:14:14 qt-kt kernel: DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 Feb 17 16:14:14 qt-kt kernel: DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Feb 17 16:14:14 qt-kt kernel: Call Trace: Feb 17 16:14:14 qt-kt kernel: snd_hdac_bus_get_response+0x6d/0x260 [snd_hda_core] Feb 17 16:14:14 qt-kt kernel: ? _dev_warn+0x6c/0x83 Feb 17 16:14:14 qt-kt kernel: ? wait_woken+0x80/0x80 Feb 17 16:14:14 qt-kt kernel: azx_rirb_get_response+0x24/0x70 [snd_hda_codec] Feb 17 16:14:14 qt-kt kernel: snd_hdac_bus_exec_verb_unlocked+0xa2/0x160 [snd_hda_core] Feb 17 16:14:14 qt-kt kernel: codec_exec_verb+0x72/0x110 [snd_hda_codec] Feb 17 16:14:14 qt-kt kernel: nv_audio_dynamic_power+0xf6/0x120 [nvidia] Feb 17 16:14:14 qt-kt kernel: _nv039365rm+0x28/0x30 [nvidia] Feb 17 16:14:14 qt-kt kernel: ? _nv000777rm+0x90/0x90 [nvidia] Feb 17 16:14:14 qt-kt kernel: ? _nv036119rm+0x184/0x190 [nvidia] Feb 17 16:14:14 qt-kt kernel: ? _nv038923rm+0xb8/0x150 [nvidia] Feb 17 16:14:14 qt-kt kernel: ? _nv037978rm+0x274/0x2d0 [nvidia] Feb 17 16:14:14 qt-kt kernel: ? _nv009273rm+0x34c/0x420 [nvidia] Feb 17 16:14:14 qt-kt kernel: ? _nv036234rm+0x57/0x100 [nvidia] Feb 17 16:14:14 qt-kt kernel: ? _nv008269rm+0x55/0xa0 [nvidia] Feb 17 16:14:14 qt-kt kernel: ? _nv008269rm+0x34/0xa0 [nvidia] Feb 17 16:14:14 qt-kt kernel: ? rm_kernel_rmapi_op+0x159/0x1b0 [nvidia] Feb 17 16:14:14 qt-kt kernel: ? nvkms_call_rm+0x4b/0x80 [nvidia_modeset] Feb 17 16:14:14 qt-kt kernel: ? _nv002678kms+0x51/0x60 [nvidia_modeset] Feb 17 16:14:14 qt-kt kernel: ? _nv000672kms+0x2cf/0x4f0 [nvidia_modeset] Feb 17 16:14:14 qt-kt kernel: ? os_acquire_spinlock+0xe/0x20 [nvidia] Feb 17 16:14:14 qt-kt kernel: ? _nv028196rm+0x4c/0x70 [nvidia] Feb 17 16:14:14 qt-kt kernel: ? _nv022269rm+0x60/0x60 [nvidia] Feb 17 16:14:14 qt-kt kernel: ? _nv002540kms+0x101/0x550 [nvidia_modeset] Feb 17 16:14:14 qt-kt kernel: ? os_acquire_spinlock+0xe/0x20 [nvidia] Feb 17 16:14:14 qt-kt kernel: ? _nv035411rm+0xc/0x20 [nvidia] Feb 17 16:14:14 qt-kt kernel: ? os_acquire_spinlock+0xe/0x20 [nvidia] Feb 17 16:14:14 qt-kt kernel: ? _nv035411rm+0xc/0x20 [nvidia] Feb 17 16:14:14 qt-kt kernel: ? _nv000022kms+0xbb/0x3d0 [nvidia_modeset] Feb 17 16:14:14 qt-kt kernel: ? _nv009226rm+0xc8/0x1d0 [nvidia] Feb 17 16:14:14 qt-kt kernel: ? _nv032826rm+0x40/0x40 [nvidia] Feb 17 16:14:14 qt-kt kernel: ? _nv000020kms+0x205/0x850 [nvidia_modeset] Feb 17 16:14:14 qt-kt kernel: ? os_acquire_spinlock+0xe/0x20 [nvidia] Feb 17 16:14:14 qt-kt kernel: ? _nv035411rm+0xc/0x20 [nvidia] Feb 17 16:14:14 qt-kt kernel: ? _nv009663rm+0x40/0x90 [nvidia] Feb 17 16:14:14 qt-kt kernel: ? _nv036161rm+0x2e/0xa0 [nvidia] Feb 17 16:14:14 qt-kt kernel: ? _nv038015rm+0x20/0x60 [nvidia] Feb 17 16:14:14 qt-kt kernel: ? _nv009661rm+0xbe/0x100 [nvidia] Feb 17 16:14:14 qt-kt kernel: ? _nv037980rm+0x120/0x130 [nvidia] Feb 17 16:14:14 qt-kt kernel: ? _nv037978rm+0xa9/0x2d0 [nvidia] Feb 17 16:14:14 qt-kt kernel: ? _nv039631rm+0x10/0x10 [nvidia] Feb 17 16:14:14 qt-kt kernel: ? _nv032865rm+0x1e/0x30 [nvidia] Feb 17 16:14:14 qt-kt kernel: ? os_acquire_spinlock+0xe/0x20 [nvidia] Feb 17 16:14:14 qt-kt kernel: ? _nv035386rm+0xc/0x20 [nvidia] Feb 17 16:14:14 qt-kt kernel: ? _nv040150rm+0x9b/0x190 [nvidia] Feb 17 16:14:14 qt-kt kernel: ? _nv002732kms+0x12b0/0x15f0 [nvidia_modeset] Feb 17 16:14:14 qt-kt kernel: ? _nv000556kms+0x50/0x50 [nvidia_modeset] Feb 17 16:14:14 qt-kt kernel: ? nvKmsIoctl+0x96/0x1d0 [nvidia_modeset] Feb 17 16:14:14 qt-kt kernel: ? nvkms_ioctl+0xf9/0x170 [nvidia_modeset] Feb 17 16:14:14 qt-kt kernel: ? nvidia_frontend_unlocked_ioctl+0x37/0x50 [nvidia] Feb 17 16:14:14 qt-kt kernel: ? __x64_sys_ioctl+0x83/0xb0 Feb 17 16:14:14 qt-kt kernel: ? do_syscall_64+0x33/0x80 Feb 17 16:14:14 qt-kt kernel: ? entry_SYSCALL_64_after_hwframe+0x44/0xa9 Feb 17 16:14:14 qt-kt kernel: ---[ end trace 86d01497afce5ce8 ]--- System hopefully still accessible by ssh and can be fixed remotely, but locally there no more workable display. Shutdown fails every other time. Work around (dirty one) replacing by kernel-firmware-nvidia-20210119-1.1 and a reboot fix the crash. Installed related nvidia packages S | Name | Type | Version | Arch | Repository ---+---------------------------+---------+-----------------------+--------+----------- i+ | kernel-firmware-nvidia | package | 20210208-1.1 | noarch | oss i+ | nvidia-computeG05 | package | 460.39-34.1 | x86_64 | nvidia i+ | nvidia-gfxG05-kmp-default | package | 460.39_k5.10.9_1-34.1 | x86_64 | nvidia i+ | nvidia-glG05 | package | 460.39-34.1 | x86_64 | nvidia i+ | nvidia-texture-tools | package | 2.0.8-3.14 | x86_64 | oss i+ | pcp-pmda-nvidia-gpu | package | 4.3.4-7.4 | x86_64 | oss i+ | x11-video-nvidiaG05 | package | 460.39-34.1 | x86_64 | nvidia complete journal log will be added and journal limited to backtrace. -- You are receiving this mail because: You are the assignee for the bug.

1 6

[Bug 1184074] New: switching video output from nvidia to hd530, system won't reboot/shutdown anymore
by bugzilla_noreply＠suse.com 02 Apr '21

02 Apr '21

http://bugzilla.opensuse.org/show_bug.cgi?id=1184074 Bug ID: 1184074 Summary: switching video output from nvidia to hd530, system won't reboot/shutdown anymore Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: x86-64 OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Kernel Assignee: kernel-bugs(a)opensuse.org Reporter: pandre.x(a)gmail.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- Created attachment 847740 --> http://bugzilla.opensuse.org/attachment.cgi?id=847740&action=edit output trying to reboot the system I installed the whole system with an Nvidia GT710. I know decided to use the internal gpu (HD530) and get ride of the nvidia. The system stopped to switch off and reboot properly. I have to do it brutally every single time. It seems it hangs without a particular reason. Switching back the HDMI cable to the nvidia, everything goes back to normal. -- You are receiving this mail because: You are the assignee for the bug.

1 9

[Bug 1183872] New: Regression: System hang when connecting HMDI with i915
by bugzilla_noreply＠suse.com 01 Apr '21

01 Apr '21

http://bugzilla.opensuse.org/show_bug.cgi?id=1183872 Bug ID: 1183872 Summary: Regression: System hang when connecting HMDI with i915 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: milanfix(a)protonmail.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- Created attachment 847526 --> http://bugzilla.opensuse.org/attachment.cgi?id=847526&action=edit Hardware info This bug doesn't occur on Leap 15.2 but it happens very consistently on Tumbleweed. How to reproduce: 1) Connect an external screen by HDMI *after* turning on the computer Expected behavior: The screen is recognized Actual behavior: Both screen go blank and the system is unusable If the screen is connected before turning on the computer then it will work as expected, but if it's re-plugged it will still hang. This isn't a desktop environment specific issue and it happens even without any X server at all. Speculation: This is most likely a kernel issue, specifically a bug in the i915 driver. If so, it was introduced between Linux 5.3 and 5.11. Things that were tried: i915.enable_psr=0 still, intel_idle.max_cstate=1 and i915.enable_dc=0 where all tried but the bug still occur. Tried to get a dump with kdump but nothing was written in /var/crash. Any tips to debug this issue so it can be narrowed down would be really helpful. I'm currently trying to find a way to test every kernel from 5.3 to 5.11 without having to actually compile them on tumbleweed, so it can, without a doubt confirmed it's a kernel issue and also find the version on which the regression was introduced. -- You are receiving this mail because: You are the assignee for the bug.

1 20