December 2021 - openSUSE Bugs - openSUSE Mailing Lists

[Bug 1193142] usb mouse and usb keyboard not recognized by sddm
by bugzilla_noreply＠suse.com 01 Dec '21

01 Dec '21

https://bugzilla.suse.com/show_bug.cgi?id=1193142 https://bugzilla.suse.com/show_bug.cgi?id=1193142#c8 Takashi Iwai <tiwai(a)suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Flags| |needinfo?(jdd(a)dodin.org) --- Comment #8 from Takashi Iwai <tiwai(a)suse.com> --- Also, there are a few more 5.3.18-59.* kernel between the working (*.10) and (*.34). The following are available: 5.3.18-59.27.1 5.3.18-59.24.1 5.3.18-59.19.1 5.3.18-59.16.1 5.3.18-59.13.1 Could you try to install the older kernel with zypper install --oldpackage option, and check whether the problem appears? e.g. zypper install --oldpackage kernel-default-5.3.18-59.27.1 Narrowing down the regression range would be greatly helpful. But, before doing the above, better to increase the installable amount of kernels by editing /etc/zypp/zypp.conf. Add more entries to multiversion.kernels line, e.g. multiversion.kernels = latest,latest-1,lastest-2,latest-3,running -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1193120] New: extracting debug-info breaks shared library file.
by bugzilla_noreply＠suse.com 01 Dec '21

01 Dec '21

http://bugzilla.opensuse.org/show_bug.cgi?id=1193120 Bug ID: 1193120 Summary: extracting debug-info breaks shared library file. Classification: openSUSE Product: openSUSE Distribution Version: Leap 15.3 Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Development Assignee: screening-team-bugs(a)suse.de Reporter: matwey.kornilov(a)gmail.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- Hello, I am working on server:database flux package (written in Rust language) and I've found that the resulting shared object is broken on Leap 15.2 and Leap 15.3 (yet working on TW): > ldd libflux.so.0.139.0 not a dynamic executable The executables using this library also cannot run. For instance influxdb2: > ldd /usr/bin/influxd /usr/bin/influxd: error while loading shared libraries: libflux.so.0.139.0: object file has no loadable segments However, if I clone the package and disable debug info in the project configuration, then the resulting shared object is correct: > ldd libflux.so.0.139.0 linux-vdso.so.1 (0x00007ffd658e3000) libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007f0e6ccdd000) libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f0e6cabd000) libdl.so.2 => /lib64/libdl.so.2 (0x00007f0e6c8b9000) libc.so.6 => /lib64/libc.so.6 (0x00007f0e6c4e4000) /lib64/ld-linux-x86-64.so.2 (0x00007f0e6d436000) The following related info is available at the build log: [ 505s] extracting debug info from /home/abuild/rpmbuild/BUILDROOT/flux-0.139.0-lp153.1.1.x86_64/usr/lib64/libflux.so.0.139.0 [ 505s] objcopy: /home/abuild/rpmbuild/BUILDROOT/flux-0.139.0-lp153.1.1.x86_64/usr/lib/debug/usr/lib64/libflux.so.0.139.0-0.139.0-lp153.1.1.x86_64.debug: warning: allocated section `.note.gnu.build-id' not in segment [ 505s] objcopy: /home/abuild/rpmbuild/BUILDROOT/flux-0.139.0-lp153.1.1.x86_64/usr/lib/debug/usr/lib64/libflux.so.0.139.0-0.139.0-lp153.1.1.x86_64.debug: warning: allocated section `.hash' not in segment [ 505s] objcopy: /home/abuild/rpmbuild/BUILDROOT/flux-0.139.0-lp153.1.1.x86_64/usr/lib/debug/usr/lib64/libflux.so.0.139.0-0.139.0-lp153.1.1.x86_64.debug: warning: allocated section `.gnu.hash' not in segment [ 505s] objcopy: /home/abuild/rpmbuild/BUILDROOT/flux-0.139.0-lp153.1.1.x86_64/usr/lib/debug/usr/lib64/libflux.so.0.139.0-0.139.0-lp153.1.1.x86_64.debug: warning: allocated section `.dynsym' not in segment [ 505s] objcopy: /home/abuild/rpmbuild/BUILDROOT/flux-0.139.0-lp153.1.1.x86_64/usr/lib/debug/usr/lib64/libflux.so.0.139.0-0.139.0-lp153.1.1.x86_64.debug: warning: allocated section `.gnu.version' not in segment [ 505s] objcopy: /home/abuild/rpmbuild/BUILDROOT/flux-0.139.0-lp153.1.1.x86_64/usr/lib/debug/usr/lib64/libflux.so.0.139.0-0.139.0-lp153.1.1.x86_64.debug: warning: allocated section `.gnu.version_r' not in segment [ 505s] objcopy: /home/abuild/rpmbuild/BUILDROOT/flux-0.139.0-lp153.1.1.x86_64/usr/lib/debug/usr/lib64/libflux.so.0.139.0-0.139.0-lp153.1.1.x86_64.debug: warning: allocated section `.rela.dyn' not in segment [ 505s] objcopy: /home/abuild/rpmbuild/BUILDROOT/flux-0.139.0-lp153.1.1.x86_64/usr/lib/debug/usr/lib64/libflux.so.0.139.0-0.139.0-lp153.1.1.x86_64.debug: warning: allocated section `.rela.plt' not in segment [ 505s] objcopy: /home/abuild/rpmbuild/BUILDROOT/flux-0.139.0-lp153.1.1.x86_64/usr/lib/debug/usr/lib64/libflux.so.0.139.0-0.139.0-lp153.1.1.x86_64.debug: warning: allocated section `.init' not in segment [ 505s] objcopy: /home/abuild/rpmbuild/BUILDROOT/flux-0.139.0-lp153.1.1.x86_64/usr/lib/debug/usr/lib64/libflux.so.0.139.0-0.139.0-lp153.1.1.x86_64.debug: warning: allocated section `.plt' not in segment [ 505s] objcopy: /home/abuild/rpmbuild/BUILDROOT/flux-0.139.0-lp153.1.1.x86_64/usr/lib/debug/usr/lib64/libflux.so.0.139.0-0.139.0-lp153.1.1.x86_64.debug: warning: allocated section `.plt.got' not in segment [ 505s] objcopy: /home/abuild/rpmbuild/BUILDROOT/flux-0.139.0-lp153.1.1.x86_64/usr/lib/debug/usr/lib64/libflux.so.0.139.0-0.139.0-lp153.1.1.x86_64.debug: warning: allocated section `.text' not in segment [ 505s] objcopy: /home/abuild/rpmbuild/BUILDROOT/flux-0.139.0-lp153.1.1.x86_64/usr/lib/debug/usr/lib64/libflux.so.0.139.0-0.139.0-lp153.1.1.x86_64.debug: warning: allocated section `.fini' not in segment [ 505s] objcopy: /home/abuild/rpmbuild/BUILDROOT/flux-0.139.0-lp153.1.1.x86_64/usr/lib/debug/usr/lib64/libflux.so.0.139.0-0.139.0-lp153.1.1.x86_64.debug: warning: allocated section `.rodata' not in segment [ 505s] objcopy: /home/abuild/rpmbuild/BUILDROOT/flux-0.139.0-lp153.1.1.x86_64/usr/lib/debug/usr/lib64/libflux.so.0.139.0-0.139.0-lp153.1.1.x86_64.debug: warning: allocated section `.eh_frame_hdr' not in segment [ 505s] objcopy: /home/abuild/rpmbuild/BUILDROOT/flux-0.139.0-lp153.1.1.x86_64/usr/lib/debug/usr/lib64/libflux.so.0.139.0-0.139.0-lp153.1.1.x86_64.debug: warning: allocated section `.eh_frame' not in segment [ 505s] objcopy: /home/abuild/rpmbuild/BUILDROOT/flux-0.139.0-lp153.1.1.x86_64/usr/lib/debug/usr/lib64/libflux.so.0.139.0-0.139.0-lp153.1.1.x86_64.debug: warning: allocated section `.gcc_except_table' not in segment [ 505s] objcopy: /home/abuild/rpmbuild/BUILDROOT/flux-0.139.0-lp153.1.1.x86_64/usr/lib/debug/usr/lib64/libflux.so.0.139.0-0.139.0-lp153.1.1.x86_64.debug: warning: allocated section `.init_array' not in segment [ 505s] objcopy: /home/abuild/rpmbuild/BUILDROOT/flux-0.139.0-lp153.1.1.x86_64/usr/lib/debug/usr/lib64/libflux.so.0.139.0-0.139.0-lp153.1.1.x86_64.debug: warning: allocated section `.fini_array' not in segment [ 505s] objcopy: /home/abuild/rpmbuild/BUILDROOT/flux-0.139.0-lp153.1.1.x86_64/usr/lib/debug/usr/lib64/libflux.so.0.139.0-0.139.0-lp153.1.1.x86_64.debug: warning: allocated section `.data.rel.ro' not in segment [ 505s] objcopy: /home/abuild/rpmbuild/BUILDROOT/flux-0.139.0-lp153.1.1.x86_64/usr/lib/debug/usr/lib64/libflux.so.0.139.0-0.139.0-lp153.1.1.x86_64.debug: warning: allocated section `.got' not in segment [ 505s] objcopy: /home/abuild/rpmbuild/BUILDROOT/flux-0.139.0-lp153.1.1.x86_64/usr/lib/debug/usr/lib64/libflux.so.0.139.0-0.139.0-lp153.1.1.x86_64.debug: warning: allocated section `.data' not in segment [ 505s] objcopy: /home/abuild/rpmbuild/BUILDROOT/flux-0.139.0-lp153.1.1.x86_64/usr/lib/debug/usr/lib64/libflux.so.0.139.0-0.139.0-lp153.1.1.x86_64.debug: warning: allocated section `.dynamic' not in segment [ 505s] objcopy: /home/abuild/rpmbuild/BUILDROOT/flux-0.139.0-lp153.1.1.x86_64/usr/lib/debug/usr/lib64/libflux.so.0.139.0-0.139.0-lp153.1.1.x86_64.debug: warning: allocated section `.dynstr' not in segment [ 505s] objcopy: /home/abuild/rpmbuild/BUILDROOT/flux-0.139.0-lp153.1.1.x86_64/usr/lib64/st4WITaS: warning: allocated section `.note.gnu.build-id' not in segment [ 505s] objcopy: /home/abuild/rpmbuild/BUILDROOT/flux-0.139.0-lp153.1.1.x86_64/usr/lib64/st4WITaS: warning: allocated section `.hash' not in segment [ 505s] objcopy: /home/abuild/rpmbuild/BUILDROOT/flux-0.139.0-lp153.1.1.x86_64/usr/lib64/st4WITaS: warning: allocated section `.gnu.hash' not in segment [ 505s] objcopy: /home/abuild/rpmbuild/BUILDROOT/flux-0.139.0-lp153.1.1.x86_64/usr/lib64/st4WITaS: warning: allocated section `.dynsym' not in segment [ 505s] objcopy: /home/abuild/rpmbuild/BUILDROOT/flux-0.139.0-lp153.1.1.x86_64/usr/lib64/st4WITaS: warning: allocated section `.gnu.version' not in segment [ 505s] objcopy: /home/abuild/rpmbuild/BUILDROOT/flux-0.139.0-lp153.1.1.x86_64/usr/lib64/st4WITaS: warning: allocated section `.gnu.version_r' not in segment [ 505s] objcopy: /home/abuild/rpmbuild/BUILDROOT/flux-0.139.0-lp153.1.1.x86_64/usr/lib64/st4WITaS: warning: allocated section `.rela.dyn' not in segment [ 505s] objcopy: /home/abuild/rpmbuild/BUILDROOT/flux-0.139.0-lp153.1.1.x86_64/usr/lib64/st4WITaS: warning: allocated section `.rela.plt' not in segment [ 505s] objcopy: /home/abuild/rpmbuild/BUILDROOT/flux-0.139.0-lp153.1.1.x86_64/usr/lib64/st4WITaS: warning: allocated section `.init' not in segment [ 505s] objcopy: /home/abuild/rpmbuild/BUILDROOT/flux-0.139.0-lp153.1.1.x86_64/usr/lib64/st4WITaS: warning: allocated section `.plt' not in segment [ 505s] objcopy: /home/abuild/rpmbuild/BUILDROOT/flux-0.139.0-lp153.1.1.x86_64/usr/lib64/st4WITaS: warning: allocated section `.plt.got' not in segment [ 505s] objcopy: /home/abuild/rpmbuild/BUILDROOT/flux-0.139.0-lp153.1.1.x86_64/usr/lib64/st4WITaS: warning: allocated section `.text' not in segment [ 505s] objcopy: /home/abuild/rpmbuild/BUILDROOT/flux-0.139.0-lp153.1.1.x86_64/usr/lib64/st4WITaS: warning: allocated section `.fini' not in segment [ 505s] objcopy: /home/abuild/rpmbuild/BUILDROOT/flux-0.139.0-lp153.1.1.x86_64/usr/lib64/st4WITaS: warning: allocated section `.rodata' not in segment [ 505s] objcopy: /home/abuild/rpmbuild/BUILDROOT/flux-0.139.0-lp153.1.1.x86_64/usr/lib64/st4WITaS: warning: allocated section `.eh_frame_hdr' not in segment [ 505s] objcopy: /home/abuild/rpmbuild/BUILDROOT/flux-0.139.0-lp153.1.1.x86_64/usr/lib64/st4WITaS: warning: allocated section `.eh_frame' not in segment [ 505s] objcopy: /home/abuild/rpmbuild/BUILDROOT/flux-0.139.0-lp153.1.1.x86_64/usr/lib64/st4WITaS: warning: allocated section `.gcc_except_table' not in segment [ 505s] objcopy: /home/abuild/rpmbuild/BUILDROOT/flux-0.139.0-lp153.1.1.x86_64/usr/lib64/st4WITaS: warning: allocated section `.init_array' not in segment [ 505s] objcopy: /home/abuild/rpmbuild/BUILDROOT/flux-0.139.0-lp153.1.1.x86_64/usr/lib64/st4WITaS: warning: allocated section `.fini_array' not in segment [ 505s] objcopy: /home/abuild/rpmbuild/BUILDROOT/flux-0.139.0-lp153.1.1.x86_64/usr/lib64/st4WITaS: warning: allocated section `.data.rel.ro' not in segment [ 505s] objcopy: /home/abuild/rpmbuild/BUILDROOT/flux-0.139.0-lp153.1.1.x86_64/usr/lib64/st4WITaS: warning: allocated section `.got' not in segment [ 505s] objcopy: /home/abuild/rpmbuild/BUILDROOT/flux-0.139.0-lp153.1.1.x86_64/usr/lib64/st4WITaS: warning: allocated section `.data' not in segment [ 505s] objcopy: /home/abuild/rpmbuild/BUILDROOT/flux-0.139.0-lp153.1.1.x86_64/usr/lib64/st4WITaS: warning: allocated section `.dynamic' not in segment [ 505s] objcopy: /home/abuild/rpmbuild/BUILDROOT/flux-0.139.0-lp153.1.1.x86_64/usr/lib64/st4WITaS: warning: allocated section `.dynstr' not in segment [ 505s] dwz: Allocatable section in ./usr/lib64/libflux.so.0.139.0-0.139.0-lp153.1.1.x86_64.debug after non-allocatable ones [ 505s] /usr/lib/rpm/sepdebugcrcfix: Updated 2 CRC32s, 1 CRC32s did match. -- You are receiving this mail because: You are on the CC list for the bug.

1 1

[Bug 1193245] Sounds jump up to 74%
by bugzilla_noreply＠suse.com 01 Dec '21

01 Dec '21

https://bugzilla.suse.com/show_bug.cgi?id=1193245 https://bugzilla.suse.com/show_bug.cgi?id=1193245#c2 Takashi Iwai <tiwai(a)suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #2 from Takashi Iwai <tiwai(a)suse.com> --- . *** This bug has been marked as a duplicate of bug 1188516 *** -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1192429] Consider bringing newer LLVM to Leap 15.3
by bugzilla_noreply＠suse.com 01 Dec '21

01 Dec '21

https://bugzilla.suse.com/show_bug.cgi?id=1192429 https://bugzilla.suse.com/show_bug.cgi?id=1192429#c11 Richard Biener <rguenther(a)suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Flags| |needinfo?(meissner(a)suse.com | |) --- Comment #11 from Richard Biener <rguenther(a)suse.com> --- (In reply to Marcus Meissner from comment #10) > i masked the SLE binary conflict now and pushed it into the qa pipeline. > > (it has correct conflicts I hope) > > llvm5 is in 15-sp2 legacy only, so eol with end of 15-sp2 in a month. > llvm7 is actively supported currently, no eol set as there is no newer llvmX > in sles yet. There will not be any newer llvmX in sles (there is pieces of llvm9 and llvm11 but only the parts required by the graphics stack runtime are shipped and supported). The idea is that llvmX (and clangX) will come from PackageHub and thus be not L3 supported (apart from the graphics stack requirements, as said). Is there a way to make llvm7 EOL somehow without providing a (L3) supported replacement? -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1190854] New: amdgpu fails to probe Radeon Pro WX3200
by bugzilla_noreply＠suse.com 01 Dec '21

01 Dec '21

http://bugzilla.opensuse.org/show_bug.cgi?id=1190854 Bug ID: 1190854 Summary: amdgpu fails to probe Radeon Pro WX3200 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: grasland(a)lal.in2p3.fr QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- Created attachment 852729 --> http://bugzilla.opensuse.org/attachment.cgi?id=852729&action=edit dmesg log, with ANSI color codes On a Dell Precision 3650 equipped with a Radeon Pro WX3200, something very wrong happens during the amdgpu initialization process (or perhaps before, see below), which makes the card unusable on Linux. Thus, I have to fall back to the CPU's built-in graphics for the time being on this machine. The GPU is brand new and works on both the UEFI setup screen and Windows, which suggests to me that the hardware is not completely broken. But of course, this does not fully exclude the possibility of a hardware issue that would only be triggered by the Linux initialization process. You will find attached the dmesg log, with and without ANSI color codes as I personally find dmesg' color output much easier to visually parse. --- Let's have a closer look at the amdgpu logs, since that's what I'm directly interested in here. First we get the standard stuff, nothing special here as far as I can see. The CRAT table bit does looks suspicious, but it also happens during the init of my home Radeon RX 560 that otherwise works fine under Linux, so this does not seem to be a fatal issue... 771 �� [ 3.484654] [drm] amdgpu kernel modesetting enabled. 772 �� [ 3.484700] amdgpu: CRAT table not found 773 �� [ 3.484701] amdgpu: Virtual CRAT table created for CPU 774 �� [ 3.484707] amdgpu: Topology: Add CPU node ...then we get a power management failure, which may or may not be related to the problem at hand... 775 �� [ 3.484764] amdgpu 0000:01:00.0: can't change power state from D3hot to D0 (config space inaccessible) ...then more "normal" stuff, in the sense of stuff that looks close to what I see in the init logs of amdgpu on my RX 560... 776 �� [ 3.484888] [drm] initializing kernel modesetting (POLARIS12 0x1002:0x6981 0x1028:0x2B0D 0x10). 777 �� [ 3.484890] amdgpu 0000:01:00.0: amdgpu: Trusted Memory Zone (TMZ) feature not supported 778 �� [ 3.484895] [drm] register mmio base: 0x6E900000 779 �� [ 3.484896] [drm] register mmio size: 262144 780 �� [ 3.484898] [drm] add ip block number 0 <vi_common> 781 �� [ 3.484899] [drm] add ip block number 1 <gmc_v8_0> 782 �� [ 3.484899] [drm] add ip block number 2 <tonga_ih> 783 �� [ 3.484900] [drm] add ip block number 3 <gfx_v8_0> 784 �� [ 3.484900] [drm] add ip block number 4 <sdma_v3_0> 785 �� [ 3.484901] [drm] add ip block number 5 <powerplay> 786 �� [ 3.484901] [drm] add ip block number 6 <dm> 787 �� [ 3.484902] [drm] add ip block number 7 <uvd_v6_0> 788 �� [ 3.484902] [drm] add ip block number 8 <vce_v3_0> 789 �� [ 3.484913] amdgpu 0000:01:00.0: amdgpu: Fetched VBIOS from VFCT 790 �� [ 3.484914] amdgpu: ATOM BIOS: 113-D0155200-100 791 �� [ 3.484932] [drm] vm size is 256 GB, 2 levels, block size is 10-bit, fragment size is 9-bit ...however, after this the driver tries to set up MMIO to communicate with the device, and here is where I think things go very wrong. 792 �� [ 3.485705] amdgpu 0000:01:00.0: BAR 2: releasing [mem 0x6100000000-0x61001fffff 64bit pref] 793 �� [ 3.485708] amdgpu 0000:01:00.0: BAR 0: releasing [mem 0x6000000000-0x60ffffffff 64bit pref] 794 �� [ 3.485709] [drm:amdgpu_device_resize_fb_bar [amdgpu]] *ERROR* Problem resizing BAR0 (-16). 795 �� [ 3.485811] amdgpu 0000:01:00.0: BAR 0: assigned [mem 0x6000000000-0x60ffffffff 64bit pref] 796 �� [ 3.485831] amdgpu 0000:01:00.0: BAR 0: error updating (0x00000c != 0xffffffff) 797 �� [ 3.485847] amdgpu 0000:01:00.0: BAR 0: error updating (high 0x000060 != 0xffffffff) 798 �� [ 3.485863] amdgpu 0000:01:00.0: BAR 2: assigned [mem 0x6100000000-0x61001fffff 64bit pref] 799 �� [ 3.485864] amdgpu 0000:01:00.0: BAR 2: error updating (0x00000c != 0xffffffff) 800 �� [ 3.485880] amdgpu 0000:01:00.0: BAR 2: error updating (high 0x000061 != 0xffffffff) 801 �� [ 3.485901] amdgpu 0000:01:00.0: amdgpu: VRAM: 4294967295M 0x000000FFFF000000 - 0x001000FFFEEFFFFF (4294967295M used) 802 �� [ 3.485903] amdgpu 0000:01:00.0: amdgpu: GART: 256M 0x0000000000000000 - 0x000000000FFFFFFF 803 �� [ 3.485905] [drm] Detected VRAM RAM=4294967295M, BAR=4096M 804 �� [ 3.485906] [drm] RAM width 64bits UNKNOWN 805 �� [ 3.485913] [drm] amdgpu: 4294967295M of VRAM memory ready 806 �� [ 3.485914] [drm] amdgpu: 48026M of GTT memory ready. 807 �� [ 3.485916] [drm] GART: num cpu pages 65536, num gpu pages 65536 Failing to set up PCI BARs sounds bad, and concluding from this failed setup process that the GPU has 4 PiB of VRAM sounds even worse. I wouldn't be surprised if this were the point where things really went hopeless. But amdgpu is not the kind of program that will stop cleanly when the first error occurs, so it will first wait for an event that doesn't want to happen... 808 �� [ 3.600399] amdgpu 0000:01:00.0: amdgpu: Wait for MC idle timedout ! [...] 813 �� [ 3.714578] amdgpu 0000:01:00.0: amdgpu: Wait for MC idle timedout ! ...then emits a few more messages that also appear during the successful initialization process of my home RX 560, so which I consider "normal"... 814 �� [ 3.715166] [drm] PCIE GART of 256M enabled (table at 0x000000FFFF900000). 815 �� [ 3.716221] [drm] Chained IB support enabled! 816 �� [ 3.721721] amdgpu: hwmgr_sw_init smu backed is polaris10_smu ...and only then it dies brutally. 817 �� [ 3.726521] amdgpu: 818 �� last message was failed ret is 65535 819 �� [ 3.726522] amdgpu: 820 �� failed to send message 100 ret is 65535 821 �� [ 3.726525] amdgpu: SMC address must be 4 byte aligned. 822 �� [ 3.726525] amdgpu: [AVFS][Polaris10_SetupGfxLvlStruct] Problems copying VRConfig value over to SMC 823 �� [ 3.726526] amdgpu: [AVFS][Polaris10_AVFSEventMgr] Could not Copy Graphics Level table over to SMU 824 �� [ 3.726565] amdgpu: 825 �� last message was failed ret is 65535 826 �� [ 3.726566] amdgpu: 827 �� failed to send message 252 ret is 65535 828 �� [ 3.726566] amdgpu: 829 �� last message was failed ret is 65535 830 �� [ 3.726567] amdgpu: 831 �� failed to send message 253 ret is 65535 832 �� [ 3.726569] amdgpu: 833 �� last message was failed ret is 65535 834 �� [ 3.726570] amdgpu: 835 �� failed to send message 250 ret is 65535 836 �� [ 3.726571] amdgpu: 837 �� last message was failed ret is 65535 838 �� [ 3.726571] amdgpu: 839 �� failed to send message 251 ret is 65535 840 �� [ 3.726572] amdgpu: 841 �� last message was failed ret is 65535 842 �� [ 3.726573] amdgpu: 843 �� failed to send message 254 ret is 65535 844 �� [ 3.861852] [drm] Timeout wait for RLC serdes 0,0 [...] 846 �� [ 3.975981] amdgpu 0000:01:00.0: [drm:amdgpu_ring_test_helper [amdgpu]] *ERROR* ring gfx test failed (-110) 847 �� [ 3.976112] [drm:amdgpu_device_init.cold [amdgpu]] *ERROR* hw_init of IP block <gfx_v8_0> failed -110 848 �� [ 3.976241] amdgpu 0000:01:00.0: amdgpu: amdgpu_device_ip_init failed 849 �� [ 3.976242] amdgpu 0000:01:00.0: amdgpu: Fatal error during GPU init 850 �� [ 3.976244] amdgpu 0000:01:00.0: amdgpu: amdgpu: finishing device. 851 �� [ 3.977567] amdgpu: probe of 0000:01:00.0 failed with error -110 852 �� [ 3.977650] [drm] amdgpu: ttm finalized --- So, to summarize, it seems something goes wrong at the MMIO setup stage, which may or may not be related to an earlier power management failure. My question is, how can I investigate this further? Here's some random trial and error stuff I already tried to no avail: - Upgrade the UEFI firmware. It's now at the latest release, and it did not change a thing. - Attempt to disable ASPM in case PCIe power management could be the issue (I found reports of an ASPM-related nvidia driver crash that started with the same ACPI error message at the beginning). Does not change anything here, rolled back. - Attempt to downgrade to an earlier amdgpu firmware, as this fixed a similar-looking crash on Arch. Did not help here, went back to the current AMD firmware. - Attempt to set the AMD GPU as the primary GPU in UEFI. This does not fix amdgpu initialization, and it breaks i915 initialization, which is definitely worse. Rolled back. -- You are receiving this mail because: You are on the CC list for the bug.

1 12

[Bug 1193142] usb mouse and usb keyboard not recognized by sddm
by bugzilla_noreply＠suse.com 01 Dec '21

01 Dec '21

https://bugzilla.suse.com/show_bug.cgi?id=1193142 https://bugzilla.suse.com/show_bug.cgi?id=1193142#c7 --- Comment #7 from Takashi Iwai <tiwai(a)suse.com> --- Is it connected over USB type-C dock? If yes, could you try to connect to the built-in port and check whether it's recognized? Currently we have some issues about some type-C connected devices with 5.15.x kernel, and this might be one of them. -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1192429] Consider bringing newer LLVM to Leap 15.3
by bugzilla_noreply＠suse.com 01 Dec '21

01 Dec '21

https://bugzilla.suse.com/show_bug.cgi?id=1192429 https://bugzilla.suse.com/show_bug.cgi?id=1192429#c10 Marcus Meissner <meissner(a)suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Flags|needinfo?(meissner(a)suse.com | |) | --- Comment #10 from Marcus Meissner <meissner(a)suse.com> --- i masked the SLE binary conflict now and pushed it into the qa pipeline. (it has correct conflicts I hope) llvm5 is in 15-sp2 legacy only, so eol with end of 15-sp2 in a month. llvm7 is actively supported currently, no eol set as there is no newer llvmX in sles yet. -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1193017] PAM authentication fails in OpenVPN
by bugzilla_noreply＠suse.com 01 Dec '21

01 Dec '21

https://bugzilla.suse.com/show_bug.cgi?id=1193017 https://bugzilla.suse.com/show_bug.cgi?id=1193017#c6 Reinhard Max <max(a)suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Flags|needinfo?(matthias.adler@cr | |onic.de) | --- Comment #6 from Reinhard Max <max(a)suse.com> --- OK, thanks again, so we will remove that patch. The documentation for deferred_auth_pam is in /usr/share/doc/packages/openvpn/README.auth-pam : --- snip --- SYNCHRONOUS OPERATION Sometimes PAM modules take very long to complete (for example, a LDAP or Radius query might timeout trying to connect an unreachable external server). Normal plugin auth operation will block the whole OpenVPN process in this time, that is, all forwarding for all other clients stops. The auth-pam plugin can operate asynchronously ("deferred authentication") to remedy this situation. To enable this, put setenv deferred_auth_pam 1 in your openvpn server config. If set, this will make the "PAM background process" fork() and do its job detached from OpenVPN. When finished, a status file is written, which OpenVPN will then pick up and read the success/failure result from it. While the plugin is working in the background, OpenVPN will continue to service other clients normally. Asynchronous operation is recommended for all PAM queries that could "take time" (LDAP, Radius, NIS, ...). If only local files are queried (passwd, pam_userdb, ...), synchronous operation has slightly lower overhead, so this is still the default mode of operation. --- snap --- -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1192714] [Build 20211114] podman tests triggering gpf in kernel 5.15.1
by bugzilla_noreply＠suse.com 01 Dec '21

01 Dec '21

https://bugzilla.suse.com/show_bug.cgi?id=1192714 https://bugzilla.suse.com/show_bug.cgi?id=1192714#c29 --- Comment #29 from Jan Kara <jack(a)suse.com> --- Cool, I will add your tested-by tag and submit the patch upstream for inclusion. -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1193017] PAM authentication fails in OpenVPN
by bugzilla_noreply＠suse.com 01 Dec '21

01 Dec '21

https://bugzilla.suse.com/show_bug.cgi?id=1193017 https://bugzilla.suse.com/show_bug.cgi?id=1193017#c5 --- Comment #5 from Matthias Adler <matthias.adler(a)cronic.de> --- OK. It works now. Again I tested with and without the setting: setenv deferred_auth_pam 1 Both configurations work fine. If I have the setting enabled I get the following additional log entry: PLUGIN AUTH-PAM: BACKGROUND: <username>: deferred auth: PAM succeeded Otherwise I they look and work the same. What difference does the setting make? -- You are receiving this mail because: You are on the CC list for the bug.

1 0