July 2022 - openSUSE Bugs - openSUSE Mailing Lists

[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

[Bug 1191727] New: Broadcom wi-fi card did not work after installing fresh tumbleweed
by bugzilla_noreply＠suse.com 27 Jan '23

27 Jan '23

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.

1 7

[Bug 1179894] New: warnings in OBS builds from kernel+initrd about "Warning: running kernel does not support fscaps"
by bugzilla_noreply＠suse.com 27 Jan '23

27 Jan '23

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.

1 6

[Bug 1178463] New: Flood of "usb usb{2,6}-port1: Cannot enable." messages
by bugzilla_noreply＠suse.com 27 Jan '23

27 Jan '23

https://bugzilla.suse.com/show_bug.cgi?id=1178463 Bug ID: 1178463 Summary: Flood of "usb usb{2,6}-port1: Cannot enable." messages 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: lmb(a)suse.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- Created attachment 843325 --> https://bugzilla.suse.com/attachment.cgi?id=843325&action=edit lsusb -vv With the 5.10.0rc2 kernel from Kernel:HEAD, I'm experiencing a flood of: ... [ 372.567942] usb usb2-port1: Cannot enable. Maybe the USB cable is bad? [ 374.686509] usb usb6-port1: Cannot enable. Maybe the USB cable is bad? [ 377.026495] usb usb2-port1: Cannot enable. Maybe the USB cable is bad? [ 378.986503] usb usb6-port1: Cannot enable. Maybe the USB cable is bad? [ 381.446415] usb usb2-port1: Cannot enable. Maybe the USB cable is bad? [ 383.290504] usb usb6-port1: Cannot enable. Maybe the USB cable is bad? [ 385.918496] usb usb2-port1: Cannot enable. Maybe the USB cable is bad? [ 387.586478] usb usb6-port1: Cannot enable. Maybe the USB cable is bad? [ 390.386475] usb usb2-port1: Cannot enable. Maybe the USB cable is bad? [ 391.894454] usb usb6-port1: Cannot enable. Maybe the USB cable is bad? ... The XPS 13 is connected to a Belkin Thunberbird dock. As far as I can tell, except for these messages, all USB connected peripherals (keyboard, mouse, webcam) are working. Attaching lsusb -vv and dmesg output. -- You are receiving this mail because: You are on the CC list for the bug.

1 7

[Bug 1188487] New: BUG: workqueue lockup
by bugzilla_noreply＠suse.com 26 Jan '23

26 Jan '23

https://bugzilla.suse.com/show_bug.cgi?id=1188487 Bug ID: 1188487 Summary: BUG: workqueue lockup 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: tdevries(a)suse.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- I started seeing this bug on my tumbleweed system: ... 2021-07-07T16:24:41.803560+02:00 lena kernel: [1053710.804959] CPU: 3 PID: 31988 Comm: gdb Tainted: G D 5.12.10-1-default #1 openSUSE Tumbleweed Message from syslogd@lena at Jul 19 16:18:29 ... kernel:[722585.589404] BUG: workqueue lockup - pool cpus=0 node=0 flags=0x0 nice=0 stuck for inted: G D 5.12.10-1-default #1 openSUSE Tumbleweed 2021-07-07T16:24:41.803561+02:00 lena kernel: [1053710.804964] Hardware name: LENOVO 20F5S0KF00/20F5S0KF00, BIOS R02ET73W (1.46 ) 01/08/2020 2021-07-07T16:24:41.803563+02:00 lena kernel: [1053710.804966] Call Trace: 2021-07-07T16:24:41.803564+02:00 lena kernel: [1053710.804971] dump_stack+0x76/0x94 2021-07-07T16:24:41.803566+02:00 lena kernel: [1053710.804978] bad_page.cold+0x9b/0xa0 2021-07-07T16:24:41.803567+02:00 lena kernel: [1053710.804983] get_page_from_freelist+0x739/0x13a0 2021-07-07T16:24:41.803568+02:00 lena kernel: [1053710.804990] __alloc_pages_nodemask+0x161/0x310 2021-07-07T16:24:41.803569+02:00 lena kernel: [1053710.804993] pagecache_get_page+0x14c/0x4f0 2021-07-07T16:24:41.803570+02:00 lena kernel: [1053710.805000] grab_cache_page_write_begin+0 7-07T16:24:41.803572+02:00 lena kernel: [1053710.805009] iomap_write_actor+0x9f/0x1a0 2021-07-07T16:24:41.803573+02:00 lena kernel: [1053710.805013] iomap_apply+0x111/0x2e0 2021-07-07T16:24:41.803575+02:00 lena kernel: [1053710.805015] ? iomap_write_end+0x260/0x260 2021-07-07T16:24:41.803576+02:00 lena kernel: [1053710.805020] iomap_file_buffered_write+0x5c/0x80 2021-07-07T16:24:41.803577+02:00 lena kernel: [1053710.805023] ? iomap_write_end+0x260/0x260 2021-07-07T16:24:41.803578+02:00 lena kernel: [1053710.805026] xfs_file_buffered_write+0xbd/0x2b0 [xfs] 2021-07-07T16:24:41.803579+02:00 lena kernel: [1053710.805122] ? _flat_send_IPI_mask+0x21/0x40 2021-07-07T16:24:41.803580+02:00 lena kernel: [1053710.805128] ? generic_exec_single+0x50/0xc0 2021-07-07T16:24:41.803582+02:00 lena kernel: [1053710.805133] ? smp_call_function_single_async+0x17/0x20 2021-07-07T16:24:41.803583+02:00 lena kernel: [1053710.805138] new_sync_write+0x11c/0x1b0 2021-07-07T16:24:41.803583+02:00 lena kernel: [1053710.805143] vfs_write+0x1b8/0x270 2021-07-07T16:24:41.803585+02:00 lena kernel: [1053710.805146] ksys_write+0x5f/0xe0 2021-07-07T16:24:41.803586+02:00 lena kernel: [1053710.805150] do_syscall_64+0x33/0x80 2021-07-07T16:24:41.803587+02:00 lena kernel: [1053710.805155] entry_SYSCALL_64_after_hwframe+0x44/0xae 2021-07-07T16:24:41.803588+02:00 lena kernel: [1053710.805159] RIP: 0033:0x7fc4b3b4539f 2021-07-07T16:24:41.803589+02:00 lena kernel: [1053710.805162] Code: 89 54 24 18 48 89 74 24 10 89 7c 24 08 e8 b9 49 f9 ff 48 8b 54 24 18 48 8b 74 24 10 41 89 c0 8b 7c 24 08 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 31 44 89 c7 48 89 44 24 08 e8 0c 4a f9 ff 48 2021-07-07T16:24:41.803590+02:00 lena kernel: [1053710.805167] RSP: 002b:00007fff61dfb5f0 EFLAGS: 00000293 ORIG_RAX: 0000000000000001 2021-07-07T16:24:41.803592+02:00 lena kernel: [1053710.805171] RAX: ffffffffffffffda RBX: 0000000000001000 RCX: 00007fc4b3b4539f 2021-07-07T16:24:41.803592+02:00 lena kernel: [1053710.805174] RDX: 0000000000001000 RSI: 0000000001f9fe90 RDI: 000000000000000e 2021-07-07T16:24:41.803593+02:00 lena kernel: [1053710.805177] RBP: 0000000001f9fe90 R08: 0000000000000000 R09: 00007fff61dfbb30 2021-07-07T16:24:41.803594+02:00 lena kernel: [1053710.805180] R10: 0000000001a44440 R11: 0000000000000293 R12: 0000000000001000 2021-07-07T16:24:41.803596+02:00 lena kernel: [1053710.805182] R13: 00000000018442a0 R14: 0000000000001000 R15: 00007fc4b3c18700 ... This is with kernel: ... $ uname -a Linux lena 5.12.13-1-default #1 SMP Mon Jun 28 06:37:23 UTC 2021 (74bd8c0) x86_64 x86_64 x86_64 GNU/Linux ... It happens during a build and test run of gdb. I've updated and rebooted to kernel version 5.13.0-1-default, but ran into the same bug. -- You are receiving this mail because: You are on the CC list for the bug.

1 5

[Bug 1193762] New: libstorage-ng fails with 'device not found' even though the device exists
by bugzilla_noreply＠suse.com 26 Jan '23

26 Jan '23

https://bugzilla.suse.com/show_bug.cgi?id=1193762 Bug ID: 1193762 Summary: libstorage-ng fails with 'device not found' even though the device exists Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: YaST2 Assignee: yast2-maintainers(a)suse.de Reporter: snwint(a)suse.com QA Contact: jsrain(a)suse.com Found By: --- Blocker: --- Created attachment 854604 --> https://bugzilla.suse.com/attachment.cgi?id=854604&action=edit yast logs + lvm + lsblk output Running 'yast2 storage' throws an exception [libstorage] BlkDeviceImpl.cc(find_by_any_name):393 THROW: \ device not found, name:/dev/mapper/vg_b-tpool_tdata_rimage_1 even though the device clearly exists. If I mount the corresponding device with UUID 2f3d4144-0cb4-499a-a183-dd012f4c9dd6 and run the probing again, it works. The setup is an admittedly slightly convoluted LVM test setup. YaST logs for both failing and working runs are attached. -- You are receiving this mail because: You are on the CC list for the bug.

1 9

[Bug 1192623] New: ltp_nfs FCNTL_LOCKTESTS test causes stack trace in dmesg
by bugzilla_noreply＠suse.com 25 Jan '23

25 Jan '23

https://bugzilla.suse.com/show_bug.cgi?id=1192623 Bug ID: 1192623 Summary: ltp_nfs FCNTL_LOCKTESTS test causes stack trace in dmesg 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: --- Tumbleweed Build 20211110 kernel 5.14.14-2-default (2b5383f) (but it might have been failing in 5.13 and older kernels) https://openqa.opensuse.org/tests/2029105/file/serial0.txt Prints really long stack trace, which begins: [ 5211.445898][ C0] sysrq: Show State [ 5211.446508][ C0] task:systemd state:S stack: 0 pid: 1 ppid: 0 flags:0x00000000 [ 5211.447686][ C0] Call Trace: [ 5211.448216][ C0] __schedule+0x325/0x1530 [ 5211.448874][ C0] ? kmem_cache_alloc+0x151/0x480 [ 5211.449593][ C0] schedule+0x44/0xa0 [ 5211.450202][ C0] schedule_hrtimeout_range_clock+0x10b/0x120 [ 5211.451077][ C0] ? kfree+0xba/0x3c0 [ 5211.451934][ C0] ? sock_poll+0x4f/0xe0 [ 5211.452914][ C0] ? ep_done_scan+0xa7/0xf0 [ 5211.453723][ C0] do_epoll_wait+0x542/0x700 [ 5211.454594][ C0] ? wait_woken+0x70/0x70 [ 5211.455511][ C0] __x64_sys_epoll_wait+0x60/0x100 [ 5211.456475][ C0] ? syscall_exit_to_user_mode+0x18/0x40 [ 5211.457467][ C0] do_syscall_64+0x5c/0x80 [ 5211.458342][ C0] ? syscall_exit_to_user_mode+0x18/0x40 [ 5211.459302][ C0] ? do_syscall_64+0x69/0x80 [ 5211.460048][ C0] ? ksys_read+0x5f/0xe0 [ 5211.460755][ C0] ? syscall_exit_to_user_mode+0x18/0x40 [ 5211.461615][ C0] ? do_syscall_64+0x69/0x80 [ 5211.462361][ C0] ? syscall_exit_to_user_mode+0x18/0x40 [ 5211.463276][ C0] ? do_syscall_64+0x69/0x80 [ 5211.464043][ C0] ? exc_page_fault+0x68/0x130 [ 5211.464821][ C0] entry_SYSCALL_64_after_hwframe+0x44/0xae [ 5211.465736][ C0] RIP: 0033:0x7fe070700c1e [ 5211.466480][ C0] RSP: 002b:00007ffc484b5ed0 EFLAGS: 00000293 ORIG_RAX: 00000000000000e8 [ 5211.467713][ C0] RAX: ffffffffffffffda RBX: 0000562627698e40 RCX: 00007fe070700c1e [ 5211.468853][ C0] RDX: 00000000000000ae RSI: 000056262788a3e0 RDI: 0000000000000004 [ 5211.469999][ C0] RBP: 0000000000000001 R08: 0000000000000000 R09: 0000000000000006 [ 5211.471147][ C0] R10: 00000000ffffffff R11: 0000000000000293 R12: 0000000000000352 [ 5211.472315][ C0] R13: 00000000000000ae R14: 0000000000000055 R15: 0000562627698fd0 [ 5211.473472][ C0] task:kthreadd state:S stack: 0 pid: 2 ppid: 0 flags:0x00004000 [ 5211.474773][ C0] Call Trace: [ 5211.475449][ C0] __schedule+0x325/0x1530 [ 5211.476249][ C0] ? kernel_thread+0x55/0x70 [ 5211.477068][ C0] schedule+0x44/0xa0 [ 5211.477836][ C0] kthreadd+0x2c0/0x2e0 [ 5211.478647][ C0] ? kthread_is_per_cpu+0x30/0x30 [ 5211.479670][ C0] ret_from_fork+0x22/0x30 [ 5211.480495][ C0] task:rcu_gp state:I stack: 0 pid: 3 ppid: 2 flags:0x00004000 -- You are receiving this mail because: You are on the CC list for the bug.

1 6