April 2022 - openSUSE Kernel Bugs - openSUSE Mailing Lists

[Bug 1193652] New: Logitech mouse and keyboard stop working on the latest kernel.

by bugzilla_noreply＠suse.com

http://bugzilla.opensuse.org/show_bug.cgi?id=1193652 Bug ID: 1193652 Summary: Logitech mouse and keyboard stop working on the latest kernel. 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: benthomasgeorge7899(a)gmail.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- Created attachment 854509 --> http://bugzilla.opensuse.org/attachment.cgi?id=854509&action=edit Logs of the said issue The mouse and keyboard stopped working randomly first while working. Later on reboot it works fine with bios and grub encryption password but within minutes the kernel is loaded it disconnects the keyboard and mouse. Possible reasons have been checked for- 1. Issue is not cause due to tlp 2. Issue not caused due to autosuspend of usb. Both the mouse and keyboard and mouse are working fine on the previous kernel 5.15.5-1. Rollback to the previous kernel has solved the issue. -- You are receiving this mail because: You are the assignee for the bug.

2 days, 20 hours

1
57
0 0

[Bug 1190190] New: kmod: manpage of modprobe.d not correctly rendered

by bugzilla_noreply＠suse.com

http://bugzilla.opensuse.org/show_bug.cgi?id=1190190 Bug ID: 1190190 Summary: kmod: manpage of modprobe.d not correctly rendered 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: sebix+novell.com(a)sebix.at QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- The manpage of modprobe.d looks broken: man modprobe.d | head MODPROBE.D(5) modprobe.d MODPROBE.D(5) .SH "NAME" modprobe.d - Configuration directory for modprobe .SH "SYNOPSIS" .PP /lib/modprobe.d/*.conf .PP /usr/lib/modprobe.d/*.conf The corresponding package `kmod` does not have a bugowner assigned in OBS, so I chose none. Using TW 20210831. -- You are receiving this mail because: You are the assignee for the bug.

3 days, 15 hours

1
1
0 0

[Bug 1191322] New: Optimize building initrd when updating system

by bugzilla_noreply＠suse.com

http://bugzilla.opensuse.org/show_bug.cgi?id=1191322 Bug ID: 1191322 Summary: Optimize building initrd when updating system Classification: openSUSE Product: openSUSE Distribution Version: Leap 15.3 Hardware: All OS: Other Status: NEW Severity: Enhancement Priority: P5 - None Component: Kernel Assignee: kernel-bugs(a)opensuse.org Reporter: Ulrich.Windl(a)rz.uni-regensburg.de QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- When installing updates, dracut is called multiple times to update the initrds of all kernels, for example when lvm2 is updated or when the kernel is updated. It would be better if the initrds were updated once at the end of the transaction (as Fedora does it, for example). Despite of that when keeping older kernels, there may be reasons _not_ to update the initrds of the older kernels: First, some may be removed on next boot anyway, and second, more important: If the idea of older kernels (and initrds) is to have a failback in case the new kernel, initrd or and binaries inside are broken (and thus fail to boot), it seems preferable to have the proven old kernel and initrd. -- You are receiving this mail because: You are the assignee for the bug.

2 weeks

1
9
0 0

[Bug 1198064] New: k3s coredns issues with Kernel versions 5.16.15 and later

by bugzilla_noreply＠suse.com

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.

3 weeks, 4 days

1
8
0 0

[Bug 1184804] New: move kernel out of /boot

by bugzilla_noreply＠suse.com

http://bugzilla.opensuse.org/show_bug.cgi?id=1184804 Bug ID: 1184804 Summary: move kernel out of /boot 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: lnussel(a)suse.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- One of the motivations for UsrMerge is to have all read-only parts of the operating system in /usr. The kernel packages install files in /boot though which isn't in line with that idea. Having the kernel installed via rpm in /boot also causes issues with eg snapshots if /boot is on a separate partition. So it make sense to store the rpm provided parts of the kernel packages where the rest of the OS is and manage /boot separately. Looking at Fedora they install files like vmlinuz that used to be named /boot/$name-$kver as (/usr)/lib/modules/$kver/$name instead. They include /boot/$name-$kver as %ghost. -- You are receiving this mail because: You are the assignee for the bug.

1 month

1
28
0 0

[Bug 1199045] New: Kernel Patch for: drivers/gpu/drm/i915/display/intel_dp.c

by bugzilla_noreply＠suse.com

http://bugzilla.opensuse.org/show_bug.cgi?id=1199045 Bug ID: 1199045 Summary: Kernel Patch for: drivers/gpu/drm/i915/display/intel_dp.c Classification: openSUSE Product: openSUSE Distribution Version: Leap 15.3 Hardware: x86 OS: openSUSE Leap 15.3 Status: NEW Severity: Normal Priority: P5 - None Component: Kernel Assignee: kernel-bugs(a)opensuse.org Reporter: dh(a)infinity-it.ch QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- Every time I update the kernel on my DELL XPS-13-7390 Laptop, I have to apply this patch https://gitlab.freedesktop.org/drm/intel/uploads/f06d4d484ee2ff496b3501ebaf… and recompile the kernel. I got this patch from the intel gfx team. If I don't patch the kernel the screen of my DELL XPS-13-7390 Laptop has a permanent flickering. Would it be possible to patch the LEAP 15.3 default kernel with this patch? That would make a kernel update much easier and people like me and other people who use the same hardware, would not have to patch and recompile the kernel after each kernel update. -- You are receiving this mail because: You are the assignee for the bug.

1 month

1
5
0 0

[Bug 1193599] New: ntel_dp_detect [i915]] *ERROR* LSPCON init failed on port D

by bugzilla_noreply＠suse.com

http://bugzilla.opensuse.org/show_bug.cgi?id=1193599 Bug ID: 1193599 Summary: ntel_dp_detect [i915]] *ERROR* LSPCON init failed on port D Classification: openSUSE Product: openSUSE Distribution Version: Leap 15.4 Hardware: x86-64 OS: openSUSE Leap 15.4 Status: NEW Severity: Normal Priority: P5 - None Component: Kernel Assignee: kernel-bugs(a)opensuse.org Reporter: opendreas(a)gmail.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- The following errors appear at boot broken atomic modeset userspace detected, disabling atomic [drm spcon_init [i915]] *ERROR* Failed to probe lspcon [drm ntel_dp_detect [i915]] *ERROR* LSPCON init failed on port D [drm spcon_init [i915]] *ERROR* Failed to probe lspcon [drm ntel_dp_detect [i915]] *ERROR* LSPCON init failed on port D [drm spcon_init [i915]] *ERROR* Failed to probe lspcon [drm ntel_dp_detect [i915]] *ERROR* LSPCON init failed on port D [drm spcon_init [i915]] *ERROR* Failed to probe lspcon [drm ntel_dp_detect [i915]] *ERROR* LSPCON init failed on port D Full log https://paste.opensuse.org/83436185 Hardware Dell Precision 7530 CPU: Intel Xeon E-2186M GPU: Intel P630 / Nvidia Quadro P3200 -- You are receiving this mail because: You are the assignee for the bug.

1 month

1
24
0 0

[Bug 1196782] New: Kernel 5.16 and 5.17 32bit tumbleweed hang after freeing kernel memory

by bugzilla_noreply＠suse.com

http://bugzilla.opensuse.org/show_bug.cgi?id=1196782 Bug ID: 1196782 Summary: Kernel 5.16 and 5.17 32bit tumbleweed hang after freeing kernel memory Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: x86 OS: openSUSE Tumbleweed Status: NEW Severity: Critical Priority: P5 - None Component: Kernel Assignee: kernel-bugs(a)opensuse.org Reporter: linux(a)ljapunow.de QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- Kernel 5.16 32bit hangs after freeing kernel memory on Dell X300 and Precision M60. acpi=off solves the problem, but then undervolting (needs acpi) does not work anymore. With kernel 5.15 there is no problem. I also tested Dell E6420 (32bit kernel) and Samsung X20. Both work with kernel 5.16. -- You are receiving this mail because: You are the assignee for the bug.

1 month

1
6
0 0

[Bug 1198972] New: btrfs send slow

by bugzilla_noreply＠suse.com

http://bugzilla.opensuse.org/show_bug.cgi?id=1198972 Bug ID: 1198972 Summary: btrfs send slow 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: jon.brightwell(a)zpg.co.uk QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- We have a btrfs send that starts fast (25MiBs) but quickly crawls (100KiBs~). example command: /sbin/btrfs send -v "/sqldata/central/.snapshots/112/snapshot" | pv -btraT -B50m | ssh backup3.repl.x.net sudo btrfs receive "/backup/dbshard1a.prod.x.net/central/112" At subvol /sqldata/central/.snapshots/112/snapshot At subvol snapshot 777MiB {----} 0:02:55 [ 130KiB/s] [4.44MiB/s] It slows down after 400MiB. I added a buffer size to pv check to see if it was network but the buffer never fills. htop doesn't show any kernel threads struggling and dstat and iostat don't show much. It's a live DB server but there's plenty of IO capacity and we have 5 identical servers that cap out the network. # iostat -x 5 Linux 5.3.18-150300.59.54-default (dbshard1a.prod.x.net) 04/28/22 _x86_64_ (48 CPU) avg-cpu: %user %nice %system %iowait %steal %idle 2.22 0.00 1.27 0.09 0.00 96.43 Device r/s w/s rkB/s wkB/s rrqm/s wrqm/s %rrqm %wrqm r_await w_await aqu-sz rareq-sz wareq-sz svctm %util nvme3n1 58.24 441.63 791.34 8244.19 5.67 51.31 8.88 10.41 0.18 0.10 0.06 13.59 18.67 0.55 27.45 nvme0n1 86.05 441.56 1379.26 8244.25 5.18 51.38 5.67 10.42 0.14 0.10 0.06 16.03 18.67 0.53 28.00 nvme1n1 58.27 441.53 791.50 8245.03 5.67 51.32 8.87 10.41 0.18 0.10 0.06 13.58 18.67 0.55 27.40 nvme2n1 86.08 441.46 1379.37 8244.97 5.18 51.38 5.67 10.43 0.14 0.10 0.06 16.02 18.68 0.53 28.04 sda 11.45 14.98 712.51 79.42 0.45 0.08 3.79 0.52 4.37 0.15 0.05 62.20 5.30 1.07 2.84 sdb 11.30 14.98 699.35 79.42 0.44 0.08 3.72 0.52 4.44 0.15 0.05 61.90 5.30 1.08 2.83 avg-cpu: %user %nice %system %iowait %steal %idle 3.85 0.00 3.40 0.12 0.00 92.63 Device r/s w/s rkB/s wkB/s rrqm/s wrqm/s %rrqm %wrqm r_await w_await aqu-sz rareq-sz wareq-sz svctm %util nvme3n1 88.80 867.80 1016.00 11651.20 0.00 68.00 0.00 7.27 0.10 0.08 0.07 11.44 13.43 0.51 48.56 nvme0n1 66.00 867.40 728.80 11651.20 0.00 68.40 0.00 7.31 0.10 0.08 0.07 11.04 13.43 0.52 48.88 nvme1n1 93.00 863.00 1048.00 11732.80 0.00 72.00 0.00 7.70 0.10 0.08 0.08 11.27 13.60 0.51 48.64 nvme2n1 65.20 862.80 768.80 11732.80 0.00 72.20 0.00 7.72 0.18 0.08 0.08 11.79 13.60 0.53 48.72 sda 41.00 72.20 3498.40 445.10 0.00 0.00 0.00 0.00 0.85 0.11 0.05 85.33 6.16 1.28 14.48 sdb 36.60 72.20 2855.20 445.10 0.00 0.00 0.00 0.00 0.79 0.10 0.04 78.01 6.16 1.31 14.24 avg-cpu: %user %nice %system %iowait %steal %idle 4.43 0.00 3.30 0.12 0.00 92.15 Device r/s w/s rkB/s wkB/s rrqm/s wrqm/s %rrqm %wrqm r_await w_await aqu-sz rareq-sz wareq-sz svctm %util nvme3n1 70.80 761.20 769.60 10829.60 0.00 63.40 0.00 7.69 0.10 0.09 0.08 10.87 14.23 0.50 41.92 nvme0n1 92.20 761.00 869.60 10829.60 0.00 63.60 0.00 7.71 0.09 0.09 0.08 9.43 14.23 0.52 44.64 nvme1n1 68.80 751.20 767.20 10528.80 0.00 61.80 0.00 7.60 0.10 0.13 0.10 11.15 14.02 0.51 42.08 nvme2n1 91.00 751.00 931.20 10528.80 0.00 62.00 0.00 7.63 0.09 0.13 0.11 10.23 14.02 0.53 44.56 sda 14.00 46.60 1089.60 297.40 0.00 0.20 0.00 0.43 0.69 0.11 0.02 77.83 6.38 1.48 8.96 sdb 10.00 46.60 552.80 297.40 0.00 0.20 0.00 0.43 0.66 0.11 0.01 55.28 6.38 1.55 8.80 # dstat 5 You did not select any stats, using -cdngy by default. --total-cpu-usage-- -dsk/total- -net/total- ---paging-- ---system-- usr sys idl wai stl| read writ| recv send| in out | int csw 2 1 96 0 0|5753k 32M| 0 0 | 86B 376B| 17k 14k 4 3 92 0 0|8436k 95M|2705k 3862k| 0 0 | 39k 29k 5 3 93 0 0|2510k 34M|2119k 3624k| 819B 0 | 30k 22k 3 3 94 0 0|2274k 39M|3914k 4882k| 0 0 | 37k 27k 3 3 94 0 0|1385k 34M|2466k 3345k| 0 0 | 32k 22k # ps -aux | grep send root 7557 94.8 0.0 24572 172 pts/1 Rl+ 11:40 8:06 /sbin/btrfs send -v /sqldata/central/.snapshots/112/snapshot does seem to be maxing out one core. # ps -auxf | grep "btrfs" root 1679 0.0 0.0 0 0 ? I< Mar19 0:00 \_ [btrfs-worker] root 1680 0.0 0.0 0 0 ? I< Mar19 0:00 \_ [btrfs-worker-hi] root 1681 0.0 0.0 0 0 ? I< Mar19 0:00 \_ [btrfs-delalloc] root 1682 0.0 0.0 0 0 ? I< Mar19 0:00 \_ [btrfs-flush_del] root 1683 0.0 0.0 0 0 ? I< Mar19 0:00 \_ [btrfs-cache] root 1684 0.0 0.0 0 0 ? I< Mar19 0:00 \_ [btrfs-submit] root 1685 0.0 0.0 0 0 ? I< Mar19 0:00 \_ [btrfs-fixup] root 1686 0.0 0.0 0 0 ? I< Mar19 0:00 \_ [btrfs-endio] root 1687 0.0 0.0 0 0 ? I< Mar19 0:00 \_ [btrfs-endio-met] root 1688 0.0 0.0 0 0 ? I< Mar19 0:00 \_ [btrfs-endio-met] root 1689 0.0 0.0 0 0 ? I< Mar19 0:00 \_ [btrfs-endio-rai] root 1690 0.0 0.0 0 0 ? I< Mar19 0:00 \_ [btrfs-endio-rep] root 1691 0.0 0.0 0 0 ? I< Mar19 0:00 \_ [btrfs-rmw] root 1692 0.0 0.0 0 0 ? I< Mar19 0:00 \_ [btrfs-endio-wri] root 1693 0.0 0.0 0 0 ? I< Mar19 0:00 \_ [btrfs-freespace] root 1694 0.0 0.0 0 0 ? I< Mar19 0:00 \_ [btrfs-delayed-m] root 1695 0.0 0.0 0 0 ? I< Mar19 0:00 \_ [btrfs-readahead] root 1696 0.0 0.0 0 0 ? I< Mar19 0:00 \_ [btrfs-qgroup-re] root 1716 0.0 0.0 0 0 ? S Mar19 0:01 \_ [btrfs-cleaner] root 1717 1.5 0.0 0 0 ? S Mar19 872:22 \_ [btrfs-transacti] root 22056 0.8 0.0 0 0 ? I 05:23 3:28 \_ [kworker/u96:10-btrfs-endio-write] root 28815 0.0 0.0 0 0 ? I< 06:41 0:00 \_ [kworker/u97:2-btrfs-worker-high] root 43020 1.5 0.0 0 0 ? I 09:22 2:22 \_ [kworker/u96:12-btrfs-endio-meta] root 44734 1.5 0.0 0 0 ? I 09:41 2:05 \_ [kworker/u96:2-btrfs-endio-meta] root 45641 0.0 0.0 0 0 ? I< 09:51 0:00 \_ [kworker/u97:6-btrfs-worker-high] root 578 0.0 0.0 0 0 ? I< 10:34 0:00 \_ [kworker/u97:1-btrfs-worker-high] root 3129 0.0 0.0 0 0 ? I< 10:59 0:00 \_ [kworker/u97:3-btrfs-worker-high] root 4401 4.2 0.0 0 0 ? I 11:06 1:56 \_ [kworker/u96:8-btrfs-endio] root 5660 0.0 0.0 0 0 ? I< 11:20 0:00 \_ [kworker/u97:4-btrfs-worker-high] root 6567 7.8 0.0 0 0 ? I 11:30 1:45 \_ [kworker/u96:14-btrfs-endio-meta] root 6570 7.6 0.0 0 0 ? I 11:30 1:42 \_ [kworker/u96:20-btrfs-endio-meta] root 6574 4.6 0.0 0 0 ? I 11:30 1:01 \_ [kworker/u96:24-btrfs-endio-meta] root 6584 8.2 0.0 0 0 ? I 11:30 1:49 \_ [kworker/u96:25-btrfs-endio-write] root 6679 0.0 0.0 0 0 ? I< 11:31 0:00 \_ [kworker/u97:5-btrfs-worker-high] root 6681 7.4 0.0 0 0 ? I 11:31 1:34 \_ [kworker/u96:27-btrfs-endio-meta] root 7499 1.7 0.0 0 0 ? I 11:40 0:13 \_ [kworker/u96:1-btrfs-endio-meta] root 7500 2.7 0.0 0 0 ? I 11:40 0:21 \_ [kworker/u96:3-btrfs-endio] root 8460 0.1 0.0 0 0 ? I 11:50 0:00 \_ [kworker/u96:4-btrfs-endio-meta] #iotop PID PRIO USER DISK READ DISK WRITE SWAPIN IO COMMAND 7557 be/4 root 190.55 K/s 0.00 B/s 0.00 % 0.13 % btrfs send -v /sqldata/central/.snapshots/112/snapshot 6570 be/4 root 9.30 K/s 18.59 K/s 0.00 % 0.01 % [kworker/u96:20-bond0] 12922 be/4 mysql 1692.48 K/s 16.67 M/s 0.00 % 0.01 % mariadbd --defaults-file=/etc/my.appdata.cnf 7499 be/4 root 6.20 K/s 9.30 K/s 0.00 % 0.01 % [kworker/u96:1-btrfs-endio-write] 22056 be/4 root 3.10 K/s 15.49 K/s 0.00 % 0.00 % [kworker/u96:10-bond0] 7500 be/4 root 3.10 K/s 3.10 K/s 0.00 % 0.00 % [kworker/u96:3-btrfs-endio-write] 12761 be/4 mysql 24.79 K/s 1332.29 K/s 0.00 % 0.00 % mariadbd --defaults-file=/etc/my.central.cnf 6359 be/4 root 0.00 B/s 0.00 B/s 0.00 % 0.00 % [kworker/12:1-events] 9123 be/4 root 0.00 B/s 0.00 B/s 0.00 % 0.00 % [kworker/19:0-events] 3015 be/4 dd-agent 0.00 B/s 3.87 K/s 0.00 % 0.00 % agent run -p /opt/datadog-agent/run/agent.pid 6567 be/4 root 0.00 B/s 12.39 K/s 0.00 % 0.00 % [kworker/u96:14-btrfs-endio-write] 6584 be/4 root 0.00 B/s 9.30 K/s 0.00 % 0.00 % [kworker/u96:25-btrfs-endio-write] What diagnostics are recommended to work out why this one server is a slug and possibly bugged? :) scrub is fine but can't take server offline to do a check. No errors in dmesg or journal. -- You are receiving this mail because: You are the assignee for the bug.

1 month, 2 weeks

1
3
0 0

[Bug 1198835] New: Wrong work of Wi-Fi card MT7921

by bugzilla_noreply＠suse.com

http://bugzilla.opensuse.org/show_bug.cgi?id=1198835 Bug ID: 1198835 Summary: Wrong work of Wi-Fi card MT7921 Classification: openSUSE Product: openSUSE Distribution Version: Leap 15.4 Hardware: x86-64 OS: openSUSE Leap 15.4 Status: NEW Severity: Major Priority: P5 - None Component: Kernel Assignee: kernel-bugs(a)opensuse.org Reporter: nikita64volkov(a)gmail.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- Overview: Wifi adapter MEDIATEK MT7921 does not work correctly. If you reboot the system or turn it off and on, the adapter stops working, and it doesn��t matter how many times you repeat this action. It helps only to completely turn off the laptop, and disconnect it from the charger, after that the adapter starts working again the next time it is turned on. At first I thought it was a problem with my laptop, but then after reading the forums I realized that I was not the only one with such a problem, and not only on the same laptop model. Before that, I tried Fedora, it had the same problem, then after some kind of kernel update it was fixed. Recently I tried to check this problem on openSUSE Tumbleweed where it turned out that there is no such problem. Steps to Reproduce: Restart operating system. Actual Results: Wifi doesn't work. Widget for selecting a network says that no devices were found to connect to Wi-Fi. Expected Results: WiFi should work. Build Date & Hardware: Kernel: 5.14.21-150400.17-default x86_64 bits: 64 Desktop: KDE Plasma 5.24.4 Distro: openSUSE Leap 15.4 Beta Additional Information: I'm not an expert, I'm just guessing that due to a bug in the driver or firmware didn't properly turn off the Wi-Fi module, so the next time you turn it on, it doesn't work until you turn it off by powering it off, which requires shutting down the system and unplugging the charger. -- You are receiving this mail because: You are the assignee for the bug.

1 month, 2 weeks

1
12
0 0

2022

2021

2020

openSUSE Kernel Bugs April 2022