https://bugzilla.suse.com/show_bug.cgi?id=1189283
Bug ID: 1189283
Summary: kernel-obs-build needs af_alg
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: fvogt(a)suse.com
QA Contact: qa-bugs(a)suse.de
Found By: ---
Blocker: ---
libkcapi got updated to 1.3.1 (https://build.opensuse.org/request/show/910806)
and apparently gnutls picks that up now and enables support for it.
It seems like that depends on AF_ALG sockets though, which are currently not
enabled in kernel-obs-build (missing af_alg module), so various builds (libzip,
libvirt) fail with
libkcapi - Error: AF_ALG: socket syscall failed (errno: -97)
I'm not sure whether just af_alg is enough, it might need some other modules as
well.
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1198722
Bug ID: 1198722
Summary: initialize useful compiled in LSMs by default
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: ---
Currently CONFIG_LSM is very minimal, not even listing the LSMs that we compile
into the kernel, which requires manual fixing on kernel boot cmdline using the
"lsm=" parameter.
we can enable these
* landlock: optional ability for user land applications to sandbox
themselves
* yama: optional restrict of use of ptrace for nonprivileged users
* bpf: create eBPF based LSMs dynamically
bpf was enabled earlier already, but reverted due to bsc#1197746
--
You are receiving this mail because:
You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1196632
Bug ID: 1196632
Summary: Raspberry Pi 3: kernel errors in journal
Classification: openSUSE
Product: openSUSE Tumbleweed
Version: Current
Hardware: aarch64
URL: https://openqa.opensuse.org/tests/2220373/modules/jour
nal_check/steps/10
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: afaerber(a)suse.com, dmueller(a)suse.com,
mbrugger(a)suse.com
Found By: openQA
Blocker: Yes
Raspberry Pi 3 shows kernel errors in journal in openQA:
Feb 24 00:00:59.640173 localhost kernel: of_clk_hw_onecell_get: invalid index
15
Feb 24 00:00:59.640443 localhost kernel: [drm:vc4_vec_bind [vc4]] *ERROR*
Failed to get clock: -2
Feb 24 00:00:59.640588 localhost kernel: vc4-drm soc:gpu: failed to bind
3f806000.vec (ops vc4_vec_ops [vc4]): -2
Feb 24 00:01:03.628986 localhost kernel: lan78xx 1-1.1.1:1.0 eth0: kevent 4
may have been dropped
Feb 24 00:01:03.630784 localhost kernel: lan78xx 1-1.1.1:1.0 eth0: kevent 4
may have been dropped
See: https://openqa.opensuse.org/tests/2220373/modules/journal_check/steps/10
RPi 2 has similar traces:
Feb 24 00:01:05.797966 localhost kernel: of_clk_hw_onecell_get: invalid index
15
Feb 24 00:01:05.798406 localhost kernel: [drm:vc4_vec_bind [vc4]] *ERROR*
Failed to get clock: -2
Feb 24 00:01:05.798737 localhost kernel: vc4-drm soc:gpu: failed to bind
3f806000.vec (ops vc4_vec_ops [vc4]): -2
Feb 24 00:01:05.852969 localhost systemd-udevd[1029]: controlC1:
/usr/lib/udev/rules.d/78-sound-card.rules:5 Failed to write
ATTR{/sys/devices/platform/soc/3f902000.hdmi/sound/card1/controlC1/../uevent},
ignoring: No such file or directory
See: https://openqa.opensuse.org/tests/2220373#step/journal_check/10
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1195297
Bug ID: 1195297
Summary: fbtft spi screens no longer functions properly.
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: simonf.lees(a)suse.com
QA Contact: qa-bugs(a)suse.de
Found By: ---
Blocker: ---
Connected to the raspberry pi on my Robot I have a small 3.2" display
[1] (or a clone / older version) it connects via SPI on the raspberry
pi's GPIO header. In the past i've had it working with the overlay at
[2] and the fbtft driver.
This kinda setup is pretty common in the embedded / hobbyist world, I
don't use a desktop or anything just simple status apps using the
framebuffer directly on the other hand it wouldn't be the end of the
world if I moved to Qt.
Today I finally got a chance to update and as of now I no longer have an
/dev/fb1 (/dev/fb0 is hdmi) is that expected with my current setup? I
had other issues with the update and had to grab a fresh image and re
add my overlay and raspbery pi config so there is also a chance I missed
something setting it up again. I've put some dmesg output from the older
system the new system shows nothing and below that is an fbi command I
use for testing.
Log from previously working system:
[ 59.468595] fbtft: module is from the staging directory, the quality
is unknown, you have been warned.
[ 59.714749] fb_ili9340: module is from the staging directory, the
quality is unknown, you have been warned.
[ 59.716023] fb_ili9340 spi0.0: fbtft_property_value: buswidth = 8
[ 59.716049] fb_ili9340 spi0.0: fbtft_property_value: debug = 0
[ 59.716063] fb_ili9340 spi0.0: fbtft_property_value: rotate = 270
[ 59.716079] fb_ili9340 spi0.0: fbtft_property_value: fps = 25
[ 59.716093] fb_ili9340 spi0.0: fbtft_property_value: txbuflen = 32768
[ 61.352903] graphics fb1: fb_ili9340 frame buffer, 320x240, 150 KiB
video memory, 32 KiB buffer memory, fps=25, spi0.0 at 16 MHz
Test command:
sudo fbi -T 13 -d /dev/fb1 --noverbose 1-110313112A3.jpg
1. https://www.waveshare.com/wiki/3.2inch_RPi_LCD_(B)
2. https://github.com/swkim01/waveshare-dtoverlays
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1179538
Bug ID: 1179538
Summary: FAIL: gdb.arch/amd64-init-x87-values.exp:
check_setting_mxcsr_before_enable: check new value of
MXCSR is still in place
Classification: openSUSE
Product: openSUSE Tumbleweed
Version: Current
Hardware: Other
OS: Other
Status: NEW
Severity: Normal
Priority: P5 - None
Component: Development
Assignee: screening-team-bugs(a)suse.de
Reporter: tdevries(a)suse.com
QA Contact: qa-bugs(a)suse.de
Found By: ---
Blocker: ---
In more detail:
...
(gdb) PASS: gdb.arch/amd64-init-x87-values.exp:
check_setting_mxcsr_before_enable: step forward one instruction for mxcsr test
p/x $mxcsr^M
$1 = 0x1f80^M
(gdb) FAIL: gdb.arch/amd64-init-x87-values.exp:
check_setting_mxcsr_before_enable: check new value of MXCSR is still in place
...
This is with kernel-obs-build-5.9.11-1.1.
So the scenario is as follows:
- we set mxcsr to a non-default value
- then we stepi past a nop
- we check that mxcsr still has the same value
- it turns out, it doesn't: the register is back to default value
It sounds alot like the fix for
https://bugzilla.kernel.org/show_bug.cgi?id=207979 is active:
...
commit 7ad816762f9bf89e940e618ea40c43138b479e10
Author: Petteri Aimonen <jpa(a)git.mail.kapsi.fi>
Date: Tue Jun 16 11:12:57 2020 +0200
x86/fpu: Reset MXCSR to default in kernel_fpu_begin()
...
However, the commit has been in place since v5.8, and I don't see this problem
on a laptop with tumbleweed running kernel v5.9.10.
--
You are receiving this mail because:
You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1173748
Bug ID: 1173748
Summary: System hangups in dual monitor use, likely Plasma/Xorg
related
Classification: openSUSE
Product: openSUSE Tumbleweed
Version: Current
Hardware: Other
OS: Other
Status: NEW
Severity: Normal
Priority: P5 - None
Component: KDE Workspace (Plasma)
Assignee: opensuse-kde-bugs(a)opensuse.org
Reporter: P.Suetterlin(a)royac.iac.es
QA Contact: qa-bugs(a)suse.de
Found By: ---
Blocker: ---
I am experiencing repeated issues with my laptop (running current TW, 20200701)
when sitting in the dock with a second monitor connected.
It usually starts with the second monitor going dark, then getting signal again
(and the monitor displays the current input as info, so indeed the signal seems
to have been gone?). Sometimes, it does stay black until I move the cursor in
there and/or go to a workspace that has a window on that screen.
Sometimes, in that situation where the monitor is black, moving the cursor to
that screen doesn't help, but short after that the whole computer freezes dead.
It also isn't pingable via network anymore, only 5s power button switchoff
helps.
I've seen it several times already over the last months, sometimes not for a
longer time. With the current release I had it 2 times already, plus a
coredump of kwin after a restart (the first coredump since many months)
Unfortunately I never found anything in the logfiles after a lockup. And the
system is configured not to write coredumps, so also nothing from the kwin
crash :(
In short, I don't really have a clue if that is software or hardware, or how to
narrow it down, as I have so far not found a way to produce the issue.
I *think* it is only happening after the monitors went to DPMS suspend, and
with no window on the second monitor.
Hardware is a Lenovo T460p, Skylake with HD530 graphics, and Xorg based
KDE/Plasma.
Maybe someone has an idea what to check/look for.
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1195707
Bug ID: 1195707
Summary: What with new
CONFIG_FRAMEBUFFER_CONSOLE_LEGACY_ACCELERATION?
Classification: openSUSE
Product: openSUSE Tumbleweed
Version: Current
Hardware: Other
OS: Other
Status: NEW
Severity: Normal
Priority: P5 - None
Component: Kernel
Assignee: gfx-bugs(a)suse.de
Reporter: jslaby(a)suse.com
QA Contact: qa-bugs(a)suse.de
Found By: ---
Blocker: ---
5.17-rc3 introduced CONFIG_FRAMEBUFFER_CONSOLE_LEGACY_ACCELERATION. What should
we set it to? Currently we have:
> origin/master:config/i386/pae:CONFIG_FRAMEBUFFER_CONSOLE_LEGACY_ACCELERATION=y
> origin/master:config/ppc64/default:# CONFIG_FRAMEBUFFER_CONSOLE_LEGACY_ACCELERATION is not set
> origin/master:config/ppc64le/default:# CONFIG_FRAMEBUFFER_CONSOLE_LEGACY_ACCELERATION is not set
> origin/master:config/riscv64/default:# CONFIG_FRAMEBUFFER_CONSOLE_LEGACY_ACCELERATION is not set
> origin/master:config/s390x/default:# CONFIG_FRAMEBUFFER_CONSOLE_LEGACY_ACCELERATION is not set
> origin/master:config/x86_64/default:# CONFIG_FRAMEBUFFER_CONSOLE_LEGACY_ACCELERATION is not set
Is this OK?
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1194268
Bug ID: 1194268
Summary: disable btrfs asserts in default kernels
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: ---
while chasing for I/O performance issues in virtualized environments (usecase
Open Build Service package builds for example), I noticed that btrfs in our
default kernel has asserts enabled. according to the Kconfig help setting, this
setting is purely for development purposes.
I suggested to move the setting CONFIG_BTRFS_ASSERT only into the debug
flavors, however there was concerns that this affects finding memory
corruptions and other hardware related issues.
On the other side, in my brief testing it appeared disabling reduced code size
noticeably (in dual-digit percentage range) and also improved IOPS on a FIO
randrw test (on a cow file) by over 20%. I will replicate the tests to be sure.
This bug is to track how to address the issue and making asserts purely
developer only and disable them in production builds of the openSUSE
distribution.
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1191727
Bug ID: 1191727
Summary: Broadcom wi-fi card did not work after installing
fresh tumbleweed
Classification: openSUSE
Product: openSUSE Tumbleweed
Version: Current
Hardware: Other
OS: Other
Status: NEW
Severity: Normal
Priority: P5 - None
Component: Network
Assignee: screening-team-bugs(a)suse.de
Reporter: virex(a)mail.ru
QA Contact: qa-bugs(a)suse.de
Found By: ---
Blocker: ---
My Broadcom wi-fi-card on laptop did not work after installing fresh
tumbleweed.
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1179894
Bug ID: 1179894
Summary: warnings in OBS builds from kernel+initrd about
"Warning: running kernel does not support fscaps"
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: okurz(a)suse.com
QA Contact: qa-bugs(a)suse.de
CC: fvogt(a)suse.com, jslaby(a)suse.com, msuchanek(a)suse.com,
okurz(a)suse.com, thomas.blume(a)suse.com, tiwai(a)suse.com
Depends on: 1178401
Found By: ---
Blocker: ---
+++ This bug was initially created as a clone of Bug #1178401 +++
## Observation
https://build.opensuse.org/build/openSUSE:Factory/images/local/000product:o…
shows repeated warnings about:
```
[ 14s] Warning: running kernel does not support fscaps
[ 14s] Warning: running kernel does not support fscaps
[ 14s] Warning: running kernel does not support fscaps
[ 14s] Warning: running kernel does not support fscaps
[ 14s] Warning: running kernel does not support fscaps
[ 14s] Warning: running kernel does not support fscaps
[ 14s] Warning: running kernel does not support fscaps
[ 14s] Warning: running kernel does not support fscaps
```
## Steps to reproduce
Seemingly reproducible in any build of packages, e.g.
https://build.opensuse.org/public/build/openSUSE:Factory/standard/x86_64/00…
shows the same
## Expected result
Only errors and warnings in the log that I as package/project maintainer can
fix
--
You are receiving this mail because:
You are on the CC list for the bug.