June 2022 - openSUSE Bugs - openSUSE Mailing Lists

[Bug 1199195] New: pinebook hibernation
by bugzilla_noreply＠suse.com 28 Jan '23

28 Jan '23

http://bugzilla.opensuse.org/show_bug.cgi?id=1199195 Bug ID: 1199195 Summary: pinebook hibernation Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: aarch64 OS: openSUSE Tumbleweed Status: NEW Severity: Normal Priority: P5 - None Component: Basesystem Assignee: screening-team-bugs(a)suse.de Reporter: werwolf131313(a)gmail.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- > [werwolf@pbp] ~ > �� cat /proc/cmdline > BOOT_IMAGE=/boot/Image-5.17.4-1-default root=UUID=88f4ab19-f7b4-4d30-9322-096925da5034 resume=UUID=842067e2-7348-4ecc-82fa-89eb049dd35f loglevel=3 splash=silent systemd.show_status=1 delayacct mitigations=off security=apparmor > [werwolf@pbp] ~ > �� cat /etc/default/grub| grep -i cmdline > GRUB_CMDLINE_LINUX_DEFAULT="resume=UUID=842067e2-7348-4ecc-82fa-89eb049dd35f loglevel=3 splash=silent systemd.show_status=1 delayacct mitigations=off security=apparmor" > GRUB_CMDLINE_LINUX="" > [werwolf@pbp] ~ > �� cat /etc/dracut.conf.d/resume.conf > add_dracutmodules+=" resume " > [werwolf@pbp] ~ > �� sudo lsinitrd /boot/initrd-5.17.4-1-default| grep resume > resume > -rw-r--r-- 1 root root 50 May 3 23:21 etc/cmdline.d/95resume.conf > -rwxr-xr-x 1 root root 67656 Apr 29 11:55 usr/lib/systemd/systemd-hibernate-resume > -rwxr-xr-x 1 root root 67808 Apr 29 11:55 usr/lib/systemd/system-generators/systemd-hibernate-resume-generator > -rw-r--r-- 1 root root 680 Apr 29 11:50 usr/lib/systemd/system/systemd-hibernate-resume@.service The PBP hibernation does not work. a laptop goes into sleep normally, but cannot wake up. -- You are receiving this mail because: You are on the CC list for the bug.

1 2

[Bug 1188352] New: Can't enter LUKS password since kernel 5.13 on Pinebook Pro
by bugzilla_noreply＠suse.com 28 Jan '23

28 Jan '23

http://bugzilla.opensuse.org/show_bug.cgi?id=1188352 Bug ID: 1188352 Summary: Can't enter LUKS password since kernel 5.13 on Pinebook Pro 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: jonasdcdm(a)mailbox.org QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- Created attachment 851029 --> http://bugzilla.opensuse.org/attachment.cgi?id=851029&action=edit dmesg Since the upgrade to kernel 5.13 it's no longer possible to enter the LUKS password on boot. The physical keyboard works fine in GRUB, but the LUKS prompt won't see it, it doesn't register any key press. Entering the password via serial console works, and the Pinebook Pro boots to the desktop, where the physical keyboard works again. Kernel 5.12.13-1 is still working fine. -- You are receiving this mail because: You are on the CC list for the bug.

1 6

[Bug 1185174] New: [i815] kernel 5.11: Xorg fails to run: open /dev/dri/card0: No such file or directory; (EE) GARTInit: Unable to open /dev/agpgart (No such file or directory)
by bugzilla_noreply＠suse.com 27 Jan '23

27 Jan '23

http://bugzilla.opensuse.org/show_bug.cgi?id=1185174 Bug ID: 1185174 Summary: [i815] kernel 5.11: Xorg fails to run: open /dev/dri/card0: No such file or directory; (EE) GARTInit: Unable to open /dev/agpgart (No such file or directory) Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: i686 OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: X.Org Assignee: gfx-bugs(a)suse.de Reporter: mrmazda(a)earthlink.net QA Contact: gfx-bugs(a)suse.de Found By: --- Blocker: --- Created attachment 848660 --> http://bugzilla.opensuse.org/attachment.cgi?id=848660&action=edit dmesg tail; journal tail; Xorg.0.log; drm.debug=0x06 log_buf_len=1M Original Summary: [i815] kernel 5.11: Xorg fails to run: open /dev/dri/card0: No such file or directory; (EE) GARTInit: Unable to open /dev/agpgart (No such file or directory) Xorg is running on TW20210420 on this ancient i815 Dell using xf86-video-intel DDX and kernel 5.10, but fails as indicated in summary with 5.11.15. https://www.linuxquestions.org/questions/linux-hardware-18/intel-corporatio… has a short record of TW Xorg on this same PC's IGP working 13 months ago. # inxi -CGSxxy System: Host: gx150 Kernel: 5.10.16-1-default i686 bits: 32 compiler: gcc v: 10.2.1 Desktop: KDE 3 wm: kwin dm: N/A Distro: openSUSE Tumbleweed 20210420 CPU: Info: Single Core model: Intel Pentium III bits: 32 type: MCP arch: P6 III Tualitin rev: 1 cache: L1: 32 KiB L2: 256 KiB flags: pae sse bogomips: 2259 Speed: 1130 MHz min/max: N/A Core speed (MHz): 1: 1130Graphics: Device-1: Intel 82815 Graphics vendor: Dell driver: N/A bus-ID: 00:02.0 chip-ID: 8086:1132 Display: x11 server: X.Org 1.20.10 driver: loaded: intel unloaded: fbdev,modesetting,vesa resolution: 1680x1050~60Hz s-dpi: 90 OpenGL: renderer: llvmpipe (LLVM 11.0.1 128 bits) v: 4.5 Mesa 21.0.2 compat-v: 3.1 direct render: Yes # zypper se -si intel ... i | intel-vaapi-driver | package | 2.4.1-2.4 | i586 | OSS i+ | kernel-firmware-intel | package | 20210315-1.1 | noarch | OSS i | libdrm_intel1 | package | 2.4.105-1.1 | i586 | OSS i+ | xf86-video-intel | package | 2.99.917+git8674.25c9a2fcc-5.7 | i586 | OSS # rpm -qa | grep nel-def kernel-default-5.4.14-2.1.i586 OK kernel-default-5.5.13-1.1.i586 OK kernel-default-5.7.11-1.1.i586 OK kernel-default-5.8.15-1.2.i586 OK kernel-default-5.9.14-1.2.i586 OK kernel-default-5.10.16-1.3.i586 OK kernel-default-5.11.2-1.2.i586 FAIL kernel-default-5.11.15-1.2.i586 FAIL -- You are receiving this mail because: You are on the CC list for the bug.

1 10

[Bug 1198722] New: initialize useful compiled in LSMs by default
by bugzilla_noreply＠suse.com 27 Jan '23

27 Jan '23

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.

1 5

[Bug 1196632] New: Raspberry Pi 3: kernel errors in journal
by bugzilla_noreply＠suse.com 27 Jan '23

27 Jan '23

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.

1 7

[Bug 1195297] New: fbtft spi screens no longer functions properly.
by bugzilla_noreply＠suse.com 27 Jan '23

27 Jan '23

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.

1 4

[Bug 1179538] New: FAIL: gdb.arch/amd64-init-x87-values.exp: check_setting_mxcsr_before_enable: check new value of MXCSR is still in place
by bugzilla_noreply＠suse.com 27 Jan '23

27 Jan '23

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.

1 12

[Bug 1173748] New: System hangups in dual monitor use, likely Plasma/Xorg related
by bugzilla_noreply＠suse.com 27 Jan '23

27 Jan '23

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.

1 7

[Bug 1195707] New: What with new CONFIG_FRAMEBUFFER_CONSOLE_LEGACY_ACCELERATION?
by bugzilla_noreply＠suse.com 27 Jan '23

27 Jan '23

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.

1 3

[Bug 1194268] New: disable btrfs asserts in default kernels
by bugzilla_noreply＠suse.com 27 Jan '23

27 Jan '23

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.

1 4