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.
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.
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.
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.
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.
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.
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.
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.
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.