July 2022 - openSUSE Kernel Bugs - openSUSE Mailing Lists

[Bug 1201917] New: nfsserver loses additional exports initiated via exportfs commands
by bugzilla_noreply＠suse.com 20 Aug '22

20 Aug '22

http://bugzilla.opensuse.org/show_bug.cgi?id=1201917 Bug ID: 1201917 Summary: nfsserver loses additional exports initiated via exportfs commands 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: ralf.koelmel(a)kit.edu QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- i'm seeing since several months (certainly on kernel 5.3.18-150300.59.68-default and 5.3.18-150300.59.76-default, but maybe it has begun earlier) a problem with explicit NFS exportfs commands (e.g "exportfs -o rw,async,no_root_squash,no_subtree_check <ip:path>"), whose NFS exports are going "lost" (mostly after one day). It seems that some automatic reload is happening, but i haven't triggered this. The file date of /var/lib/nfs/etab has changed, but no message about a reload in the nfs-server logs or in the system messages. But the expected export is not anymore present in etab or on the list of "exportfs -s". Because i have now stale mountpoints on some clients, as workaround i have to add these temporary exports to a exports file to get a stable NFS mountpoint, which will be needed only for a few days. In "former" times such exports from explicit NFS exportfs commands were remaining since a manual reload or a restart of the nfs server was triggered. Is this now an expected behaviour on the openSUSE NFS server? -- You are receiving this mail because: You are the assignee for the bug.

1 1

[Bug 1201446] New: Steam deck - Power consumption will be higher as BIOS has not been configured for suspend-to-idle.
by bugzilla_noreply＠suse.com 19 Aug '22

19 Aug '22

http://bugzilla.opensuse.org/show_bug.cgi?id=1201446 Bug ID: 1201446 Summary: Steam deck - Power consumption will be higher as BIOS has not been configured for suspend-to-idle. 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: monkeyboyted(a)yahoo.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- Created attachment 860141 --> http://bugzilla.opensuse.org/attachment.cgi?id=860141&action=edit journalctl log Suspend doesn't work on the steam deck. When trying to press the power button, the screen will flash but go black again. I had to hard cycle the deck and boot it from scratch again. LSB Version: n/a Distributor ID: openSUSE Description: openSUSE Tumbleweed Release: 20220711 Codename: n/a uname -a Linux steamdeck.lan 5.18.9-2-default #1 SMP PREEMPT_DYNAMIC Wed Jul 6 05:57:32 UTC 2022 (a7c5f9c) x86_64 x86_64 x86_64 GNU/Linux -- You are receiving this mail because: You are the assignee for the bug.

1 39

[Bug 1198064] New: k3s coredns issues with Kernel versions 5.16.15 and later
by bugzilla_noreply＠suse.com 17 Aug '22

17 Aug '22

http://bugzilla.opensuse.org/show_bug.cgi?id=1198064 Bug ID: 1198064 Summary: k3s coredns issues with Kernel versions 5.16.15 and later 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: opensuse_buildservice(a)ojkastl.de QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- I am running k3s (various versions) on some openSUSE MicroOS machines (MicroOS based on Tumbleweed) with automatic updates enabled. Recently I noticed that coredns does no longer get working connections to the outside. Which leads to coredns never reaching LIVE status and hence the whole cluster being broken. From the coredns pod logs: [ERROR] plugin/errors: 2 2710547001195683759.7881225443334916626. HINFO: read udp 10.0.0.190:35403->192.168.99.1:53: i/o timeout [ERROR] plugin/errors: 2 2710547001195683759.7881225443334916626. HINFO: read udp 10.0.0.190:35711->192.168.99.121:53: i/o timeout (192.168.99.1 and 192.168.99.121 are the local DNS resolver and the nodes IP address) Rolling back to a snapshot having kernel 5.16.14 solved the issue and the cluster is working again. In short: kernel version 5.16.14 good kernel version 5.16.15 coredns broken kernel version 5.17.1 coredns broken Robert reported similar issues with weave being broken in boo#1197490, where rolling back to an older snapshot also solved the issue https://bugzilla.opensuse.org/show_bug.cgi?id=1197490 Here is the bug report for k3s, to make them aware of possible breakage: https://github.com/k3s-io/k3s/issues/5379 Please reach out if you need more details. Kind Regards, Johannes -- You are receiving this mail because: You are the assignee for the bug.

1 9

[Bug 1196373] New: JeOS: proc-sys-fs-binfmt_misc.mount: failed
by bugzilla_noreply＠suse.com 12 Aug '22

12 Aug '22

https://bugzilla.suse.com/show_bug.cgi?id=1196373 Bug ID: 1196373 Summary: JeOS: proc-sys-fs-binfmt_misc.mount: failed 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: petr.vorel(a)suse.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- binfmt_misc [1] is somehow broken on current JeOS. Found on my fork of opensuse-Tumbleweed-JeOS-for-kvm-and-xen-x86_64-Build20220222-jeos-ltp-commands@uefi_virtio-2G job [2], but also verified locally on JeOS 20220221. $ systemctl status proc-sys-fs-binfmt_misc.mount �� proc-sys-fs-binfmt_misc.mount - Arbitrary Executable File Formats File System Loaded: loaded (/usr/lib/systemd/system/proc-sys-fs-binfmt_misc.mount; disabled; vendor preset: disabled) Active: failed (Result: exit-code) since Wed 2022-02-23 18:41:43 UTC; 1min 6s ago TriggeredBy: �� proc-sys-fs-binfmt_misc.automount Where: /proc/sys/fs/binfmt_misc What: binfmt_misc Docs: https://www.kernel.org/doc/html/latest/admin-guide/binfmt-misc.html https://www.freedesktop.org/wiki/Software/systemd/APIFileSystems CPU: 6ms Feb 23 18:41:43 jeos-tumbleweed systemd[1]: Mounting Arbitrary Executable File Formats File System... Feb 23 18:41:43 jeos-tumbleweed mount[7585]: mount: /proc/sys/fs/binfmt_misc: unknown filesystem type 'binfmt_misc'. Feb 23 18:41:43 jeos-tumbleweed systemd[1]: proc-sys-fs-binfmt_misc.mount: Mount process exited, code=exited, status=> Feb 23 18:41:43 jeos-tumbleweed systemd[1]: proc-sys-fs-binfmt_misc.mount: Failed with result 'exit-code'. Feb 23 18:41:43 jeos-tumbleweed systemd[1]: Failed to mount Arbitrary Executable File Formats File System. $ df -a on JeOS reports: df: /proc/sys/fs/binfmt_misc: No such device ... $ ls /proc/sys/fs/binfmt_misc/ ls: cannot access '/proc/sys/fs/binfmt_misc/': No such device $ grep BINFMT_MISC /boot/config-5.15.12-1-default CONFIG_BINFMT_MISC=m (the same setup is on normal "desktop" Tumbleweed, where it works). [1] https://www.kernel.org/doc/html/latest/admin-guide/binfmt-misc.html [2] http://quasar.suse.cz/tests/8530#step/df01_ext2_sh/8 -- You are receiving this mail because: You are the assignee for the bug.

1 16

[Bug 1180591] New: Display backlight stuck at 100%
by bugzilla_noreply＠suse.com 08 Aug '22

08 Aug '22

http://bugzilla.opensuse.org/show_bug.cgi?id=1180591 Bug ID: 1180591 Summary: Display backlight stuck at 100% 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: maurizio.galli(a)gmail.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- Created attachment 844855 --> http://bugzilla.opensuse.org/attachment.cgi?id=844855&action=edit system information I have just upgraded my device to Tumbleweed and now backlight brightness is stuck at 100% with no way to change it. I have tried several methods, including xbacklight and Xfce settings. Backlight control used to work fine with Kernel 5.3 shipped by Leap. I found a recent report using similar hardware that could suggest a regression in the kernel: https://discuss.getsol.us/d/6039-brightness-control-not-working-on-apple-di… I attached information about my system but please let me know what else I can provide. -- You are receiving this mail because: You are the assignee for the bug.

1 24

[Bug 1199848] New: kernel crash / error_code(0x0000) - not-present page
by bugzilla_noreply＠suse.com 05 Aug '22

05 Aug '22

http://bugzilla.opensuse.org/show_bug.cgi?id=1199848 Bug ID: 1199848 Summary: kernel crash / error_code(0x0000) - not-present page Classification: openSUSE Product: openSUSE Distribution Version: Leap 15.4 Hardware: x86-64 OS: openSUSE Leap 15.4 Status: NEW Severity: Critical Priority: P5 - None Component: Kernel Assignee: kernel-bugs(a)opensuse.org Reporter: obs(a)akr.yagii.de QA Contact: qa-bugs(a)suse.de CC: hare(a)suse.com, obs(a)akr.yagii.de, rtsvetkov(a)suse.com, sweiberg(a)suse.com, tiwai(a)suse.com Depends on: 1196213 Found By: --- Blocker: --- +++ This bug was initially created as a clone of Bug #1196213 +++ Opening new bug as suggested there. I have observed two more crashes with kernel 5.14.21-150400.122.ga565947-default, both again with [26800.044019] #PF: error_code(0x0000) - not-present page Circumstances have been different though: the attached crash dmesg occurred when trying to boot off an inserted USB-Stick attached to a QEMU-KVM VM or when attaching the new USB Host device to a running VM. The same happens for the SLE15-SP4 kernel 5.14.21-150400.139.g11e974a-default. dmesg submitted with Bug #1196213. -- You are receiving this mail because: You are the assignee for the bug.

1 10

[Bug 1201632] New: kernel 5.3.18-150300.59.81-default: host fails to start qemu guests
by bugzilla_noreply＠suse.com 03 Aug '22

03 Aug '22

http://bugzilla.opensuse.org/show_bug.cgi?id=1201632 Bug ID: 1201632 Summary: kernel 5.3.18-150300.59.81-default: host fails to start qemu guests 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: hsk17(a)mail.de QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- after latest kernel patch upgrade, i.e. from kernel-default-5.3.18-150300.59.76.1 to kernel-default-5.3.18-150300.59.81.1, on host, host fails to start libvirt/qemu guests: "virsh start guest" reports guest started, but guest remains inaccessible, and the console window within virt-manager stays at a pure black screen. reboot host to previous kernel 5.3.18-150300.59.76-default, and qemu guests start up as usual. i observed this on hosts running leap 15.3 with all patches installed. which further information about the case is needed? -- You are receiving this mail because: You are the assignee for the bug.

1 3

[Bug 1201845] New: mt7921e 0000:03:00.0: driver own failed
by bugzilla_noreply＠suse.com 03 Aug '22

03 Aug '22

https://bugzilla.suse.com/show_bug.cgi?id=1201845 Bug ID: 1201845 Summary: mt7921e 0000:03:00.0: driver own failed 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: kostas.peletidis(a)suse.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- Background: I was changing the firewall zone in the settings of my WLAN connection using NetworkManager. Suddenly I noticed many web sites were becoming unreachable and commands such as "ss -na4" would hang indefinitely (Ctrl-C wouldn't work). The processes of commands that involved the network could not be killed, not even with SIGKILL. It might also be worth mentioning that a VirtualBox VM was running at the time, again running Tumbleweed and NetworkManager. The VM had a network interface bridged to the wlan interface, wlp3s0. It was not possible to shut down or even kill the VM when the issue was noticed. Shutting down the actual machine wasn't possible either, a hard poweroff had to be done. The output of dmesg follows below, with a few lines before the "cut here" mark for context: [11249.676616] r8169 0000:02:00.0 enp2s0f0: Link is Down [11453.812782] mt7921e 0000:03:00.0: driver own failed [11454.986117] mt7921e 0000:03:00.0: driver own failed [11454.986134] mt7921e 0000:03:00.0: chip reset [11456.170894] mt7921e 0000:03:00.0: driver own failed [11456.278532] pcieport 0000:00:02.3: pciehp: Slot(0): Link Down [11456.278536] pcieport 0000:00:02.3: pciehp: Slot(0): Card not present [11456.313973] wlp3s0: deauthenticating from f8:5b:3b:0f:2b:9f by local choice (Reason: 3=DEAUTH_LEAVING) [11457.286206] mt7921e 0000:03:00.0: Timeout for driver own [11458.400420] mt7921e 0000:03:00.0: driver own failed [11458.400442] ------------[ cut here ]------------ [11458.400443] WARNING: CPU: 2 PID: 8597 at kernel/kthread.c:659 kthread_park+0x81/0x90 [11458.400454] Modules linked in: mptcp_diag tcp_diag udp_diag raw_diag inet_diag tun rfcomm nft_objref nf_conntrack_netbios_ns nf_conntrack_broadcast ccm cmac algif_hash ecb algif_skcipher af_alg af_packet nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib nft_reject_inet nf_reject_ipv4 nf_reject_ipv6 nft_reject nft_ct bridge stp llc nft_chain_nat nf_tables ebtable_nat ebtable_broute ip6table_nat ip6table_mangle ip6table_raw ip6table_security iptable_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 iptable_mangle iptable_raw vboxnetadp(O) vboxnetflt(O) iptable_security nfnetlink ebtable_filter ebtables ip6table_filter ip6_tables iptable_filter bpfilter bnep btusb btrtl btbcm btintel btmtk bluetooth uvcvideo videobuf2_vmalloc videobuf2_memops videobuf2_v4l2 videobuf2_common vboxdrv(O) videodev ecdh_generic mc qrtr dmi_sysfs msr nls_iso8859_1 nls_cp437 vfat fat mt7921e mt7921_common snd_acp3x_pdm_dma snd_acp3x_rn snd_soc_dmic mt76_connac_lib snd_sof_amd_renoir snd_ctl_led [11458.400527] snd_sof_amd_acp mt76 snd_sof_pci snd_sof snd_hda_codec_realtek snd_sof_utils mac80211 snd_hda_codec_generic snd_hda_codec_hdmi snd_soc_core snd_hda_intel snd_compress libarc4 snd_intel_dspcfg snd_pcm_dmaengine snd_intel_sdw_acpi snd_acp_pci snd_hda_codec pcspkr r8169 snd_pci_acp6x snd_hda_core cfg80211 efi_pstore snd_pci_acp5x joydev snd_hwdep think_lmi realtek snd_rn_pci_acp3x mdio_devres wmi_bmof thinkpad_acpi firmware_attributes_class snd_acp_config snd_pcm snd_soc_acpi ledtrig_audio libphy snd_pci_acp3x platform_profile snd_timer rfkill i2c_piix4 k10temp thermal tiny_power_button snd soundcore ac acpi_cpufreq button fuse configfs ip_tables x_tables usbhid amdgpu drm_ttm_helper ttm xhci_pci iommu_v2 xhci_pci_renesas xhci_hcd ucsi_acpi hid_multitouch nvme gpu_sched typec_ucsi hid_generic usbcore ccp drm_dp_helper serio_raw roles nvme_core sp5100_tco typec wmi battery video i2c_hid_acpi i2c_hid btrfs blake2b_generic libcrc32c crc32c_intel xor raid6_pq sg [11458.400598] dm_multipath dm_mod scsi_dh_rdac scsi_dh_emc scsi_dh_alua efivarfs [11458.400605] CPU: 2 PID: 8597 Comm: kworker/u32:11 Tainted: G O 5.18.11-1-default #1 openSUSE Tumbleweed dfca0849ead84314c7d214c3a61e8eeef78902fa [11458.400611] Hardware name: LENOVO 20XGS0V508/20XGS0V508, BIOS R1NET47W (1.17) 12/21/2021 [11458.400613] Workqueue: mt76 mt7921_mac_reset_work [mt7921_common] [11458.400627] RIP: 0010:kthread_park+0x81/0x90 [11458.400633] Code: 00 48 85 c0 74 2d 31 c0 5b 5d c3 cc cc cc cc 0f 0b 48 8b ab a8 0a 00 00 a8 04 74 ac 0f 0b b8 da ff ff ff 5b 5d c3 cc cc cc cc <0f> 0b b8 f0 ff ff ff eb d5 0f 0b eb cf 66 90 0f 1f 44 00 00 41 55 [11458.400636] RSP: 0018:ffffb026c964fe00 EFLAGS: 00010202 [11458.400640] RAX: 0000000000000004 RBX: ffff9ae989282900 RCX: 0000000000000000 [11458.400642] RDX: 0000000000000003 RSI: 0000000000000003 RDI: ffff9ae989282900 [11458.400643] RBP: ffff9ae9944d8580 R08: 0000000000000000 R09: 00000000fffffff0 [11458.400645] R10: 0000000000000003 R11: ffff9aec6e2c38a8 R12: ffff9ae9871308e0 [11458.400646] R13: ffff9ae9871320e0 R14: ffff9ae987138610 R15: ffff9ae987132430 [11458.400649] FS: 0000000000000000(0000) GS:ffff9aec5ee80000(0000) knlGS:0000000000000000 [11458.400651] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [11458.400653] CR2: 0000561d5a80d1b0 CR3: 00000002a73ce000 CR4: 0000000000750ee0 [11458.400655] PKRU: 55555554 [11458.400657] Call Trace: [11458.400659] <TASK> [11458.400664] mt7921e_mac_reset+0x9e/0x2d0 [mt7921e 3c18704b3a7506787a289600f5bf8b01993445b3] [11458.400672] mt7921_mac_reset_work+0x9f/0x14a [mt7921_common 3c26fb2d3d9614b27e4189eb21b64c97b9b38876] [11458.400681] process_one_work+0x20f/0x3d0 [11458.400689] worker_thread+0x4a/0x3b0 [11458.400692] ? process_one_work+0x3d0/0x3d0 [11458.400695] kthread+0xda/0x100 [11458.400699] ? kthread_complete_and_exit+0x20/0x20 [11458.400704] ret_from_fork+0x22/0x30 [11458.400711] </TASK> [11458.400712] ---[ end trace 0000000000000000 ]--- [11658.821384] vboxnetflt: 134306 out of 1469774 packets were not sent (directed to host) -- You are receiving this mail because: You are the assignee for the bug.

1 8

[Bug 1200306] New: USB Mouse responds poorly when high bandwidth used by USB Ethernet adapter
by bugzilla_noreply＠suse.com 02 Aug '22

02 Aug '22

http://bugzilla.opensuse.org/show_bug.cgi?id=1200306 Bug ID: 1200306 Summary: USB Mouse responds poorly when high bandwidth used by USB Ethernet adapter Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: x86-64 OS: openSUSE Tumbleweed Status: NEW Severity: Critical Priority: P5 - None Component: Kernel Assignee: kernel-bugs(a)opensuse.org Reporter: php4fan(a)gmail.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- Steps to reproduce: - plug a usb ethernet adapter and connect to an Etherent LAN - plug a USB mouse (in my case, a wireless one) - stream video, download something heavy, or do a speedtest at speedtest.net or similar, and move the mouse meanwhile Expected: the mouse should always respond smoothly no matter what Observed: when network bandwidth usage is high, the mouse responds sluggishly This actually looks like the initial symptoms of bug 1184817 (which I had stopped observing and assumed was fixed), although for now I'm only experiencing mouse unsersponsiveness and not the whole system falling apart. -- You are receiving this mail because: You are the assignee for the bug.

1 1

[Bug 1201867] New: Kernel regression: Crashkernel doesn't start
by bugzilla_noreply＠suse.com 02 Aug '22

02 Aug '22

https://bugzilla.suse.com/show_bug.cgi?id=1201867 Bug ID: 1201867 Summary: Kernel regression: Crashkernel doesn't start Classification: openSUSE Product: openSUSE Distribution Version: Leap 15.3 Hardware: aarch64 URL: https://openqa.opensuse.org/tests/2481397/modules/kdum p_and_crash/steps/48 OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Kernel Assignee: kernel-bugs(a)opensuse.org Reporter: fvogt(a)suse.com QA Contact: qa-bugs(a)suse.de Found By: openQA Blocker: Yes AArch64 only. Kernel logs say: [ 66.889582] sysrq: Trigger a crash [ 66.889826] Kernel panic - not syncing: sysrq triggered crash [ 66.890195] CPU: 0 PID: 4256 Comm: bash Kdump: loaded Tainted: G N 5.3.18-150300.59.81-default #1 SLE15-SP3 [ 66.890902] Hardware name: QEMU KVM Virtual Machine, BIOS 0.0.0 02/06/2015 [ 66.891338] Call trace: [ 66.891502] dump_backtrace+0x0/0x1c0 [ 66.891737] show_stack+0x24/0x30 [ 66.891954] dump_stack+0xb0/0xdc [ 66.892184] panic+0x148/0x364 [ 66.892396] sysrq_handle_crash+0x1c/0x20 [ 66.892668] __handle_sysrq+0xb0/0x1b0 [ 66.892943] write_sysrq_trigger+0x70/0x88 [ 66.893223] proc_reg_write+0x78/0xd0 [ 66.893474] __vfs_write+0x48/0x80 [ 66.893708] vfs_write+0xac/0x1c8 [ 66.893936] ksys_write+0x74/0xf8 [ 66.894163] __arm64_sys_write+0x24/0x30 [ 66.894432] el0_svc_common.constprop.0+0x84/0x218 [ 66.895025] el0_svc_handler+0x34/0x90 [ 66.895483] el0_svc+0x10/0x540 [ 66.926829] Starting crashdump kernel... [ 66.927353] Bye! Kernel 5.3.18-150300.59.76 works (https://openqa.opensuse.org/tests/2471490#step/kdump_and_crash/50), 5.3.18-150300.59.81 does not (https://openqa.opensuse.org/tests/2472635#step/kdump_and_crash/45) ## Observation openQA test in scenario opensuse-15.3-JeOS-for-AArch64-aarch64-jeos-extra@USBboot_aarch64 fails in [kdump_and_crash](https://openqa.opensuse.org/tests/2481397/modules/kdump_an… ## Test suite description Same as jeos, plus some more tests. ## Reproducible Fails since (at least) Build [9.556](https://openqa.opensuse.org/tests/2472150) ## Expected result Last good: [9.555](https://openqa.opensuse.org/tests/2471490) (or more recent) ## Further details Always latest result in this scenario: [latest](https://openqa.opensuse.org/tests/latest?arch=aarch64&distri=opensu… -- You are receiving this mail because: You are the assignee for the bug.

1 2