November 2022 - openSUSE Bugs - openSUSE Mailing Lists

[Bug 1204315] [RPi] Kernel 6.0 - [drm] *ERROR* could not acquire memory range
by bugzilla_noreply＠suse.com 02 Nov '22

02 Nov '22

https://bugzilla.suse.com/show_bug.cgi?id=1204315 https://bugzilla.suse.com/show_bug.cgi?id=1204315#c19 --- Comment #19 from Thomas Zimmermann <tzimmermann(a)suse.com> --- (In reply to Thomas Zimmermann from comment #18) > (In reply to Takashi Iwai from comment #17) > > Then maybe better to have as Kconfig dependency, e.g. > > > > --- a/drivers/gpu/drm/tiny/Kconfig > > +++ b/drivers/gpu/drm/tiny/Kconfig > > @@ -69,6 +69,7 @@ config DRM_PANEL_MIPI_DBI > > config DRM_SIMPLEDRM > > tristate "Simple framebuffer driver" > > depends on DRM && MMU > > + depends on SYSFB=n > > select APERTURE_HELPERS > > select DRM_GEM_SHMEM_HELPER > > select DRM_KMS_HELPER > > Why? It has nothing to do with the driver. It would, BTW, prevent it from being used on x86, etc. -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1202950] Offline Upgrade to 15.4 stops before starting installer
by bugzilla_noreply＠suse.com 02 Nov '22

02 Nov '22

https://bugzilla.suse.com/show_bug.cgi?id=1202950 https://bugzilla.suse.com/show_bug.cgi?id=1202950#c15 Steffen Winterfeldt <snwint(a)suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |snwint(a)suse.com Component|Installation |X.Org Assignee|yast2-maintainers(a)suse.de |gfx-bugs(a)suse.de QA Contact|jsrain(a)suse.com |gfx-bugs(a)suse.de --- Comment #15 from Steffen Winterfeldt <snwint(a)suse.com> --- From the video it looks like some problem with Xorg. The screen goes into standby when Xorg is started. It is not clear why this happens. There is a log in /var/log/Xorg.0.log you could check. There might be a driver missing. You might try booting with the 'nomodeset' boot option. You can also boot with startshell=1 which would not start the installer but give you a bash prompt where you can run 'Xorg' manually and check what happens. In any case this looks not like an installer issue. Reassigning to Xorg people. -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1204315] [RPi] Kernel 6.0 - [drm] *ERROR* could not acquire memory range
by bugzilla_noreply＠suse.com 02 Nov '22

02 Nov '22

https://bugzilla.suse.com/show_bug.cgi?id=1204315 https://bugzilla.suse.com/show_bug.cgi?id=1204315#c18 --- Comment #18 from Thomas Zimmermann <tzimmermann(a)suse.com> --- (In reply to Takashi Iwai from comment #17) > Then maybe better to have as Kconfig dependency, e.g. > > --- a/drivers/gpu/drm/tiny/Kconfig > +++ b/drivers/gpu/drm/tiny/Kconfig > @@ -69,6 +69,7 @@ config DRM_PANEL_MIPI_DBI > config DRM_SIMPLEDRM > tristate "Simple framebuffer driver" > depends on DRM && MMU > + depends on SYSFB=n > select APERTURE_HELPERS > select DRM_GEM_SHMEM_HELPER > select DRM_KMS_HELPER Why? It has nothing to do with the driver. -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1204954] New: Temp file cleaning systemd warnings
by bugzilla_noreply＠suse.com 02 Nov '22

02 Nov '22

http://bugzilla.opensuse.org/show_bug.cgi?id=1204954 Bug ID: 1204954 Summary: Temp file cleaning systemd warnings Classification: openSUSE Product: openSUSE Distribution Version: Leap 15.4 Hardware: Other OS: openSUSE Leap 15.4 Status: NEW Severity: Normal Priority: P5 - None Component: Basesystem Assignee: screening-team-bugs(a)suse.de Reporter: bugz57(a)top.geek.nz QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- There's a warning caused by /usr/lib/tmpfiles.d/net-snmp.conf: # systemctl status systemd-tmpfiles-clean.service Oct 27 22:43:52 host systemd-tmpfiles[32536]: /usr/lib/tmpfiles.d/net-snmp.conf:1: Line references path below legacy directory /var/run/, updating /var/run/net-snmp ? /run/net-snmp; please update the tmpfiles.d/ drop-in file accordingly. It's probably harmless. > rpm -qf /usr/lib/tmpfiles.d/net-snmp.conf net-snmp-5.7.3-10.12.1.x86_64 More detrimental are: Nov 02 17:26:20 kaka systemd-tmpfiles[24586]: /usr/lib/tmpfiles.d/fs-tmp.conf:1: Duplicate line for path "/tmp", ignoring. Nov 02 17:26:20 kaka systemd-tmpfiles[24586]: /usr/lib/tmpfiles.d/fs-var-tmp.conf:1: Duplicate line for path "/var/tmp", ignoring. That's caused by creating (I want the junk taken out of temporary places at specified intervals) /etc/tmpfiles.d/5-tmp-local.conf D /tmp 1777 root root 7d d /var/tmp 1777 root root 70d The system files contain cat /usr/lib/tmpfiles.d/fs-*tmp.conf q /tmp 1777 root root - d /var/tmp 1777 root root - It seems systemd has no facility to override general system defaults with local host-specific values - is that correct? I would count that as a bug, it's not how unix usually works. -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1204567] New: default value of BASH_LOADABLES_PATH does not include the path in bash-loadables package.
by bugzilla_noreply＠suse.com 02 Nov '22

02 Nov '22

http://bugzilla.opensuse.org/show_bug.cgi?id=1204567 Bug ID: 1204567 Summary: default value of BASH_LOADABLES_PATH does not include the path in bash-loadables package. Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: x86-64 OS: openSUSE Tumbleweed Status: NEW Severity: Enhancement Priority: P5 - None Component: Other Assignee: screening-team-bugs(a)suse.de Reporter: jason(a)ferrer.com.ph QA Contact: qa-bugs(a)suse.de Found By: Community User Blocker: --- `declare -p BASH_LOADABLES_PATH` prints `declare -- BASH_LOADABLES_PATH="/usr/local/lib/bash:/usr/lib/bash:/opt/local/lib/bash:/usr/pkg/lib/bash:/opt/pkg/lib/bash:."` while `rpm -ql bash-loadables` prints /usr/lib64/bash /usr/lib64/bash/Makefile.sample /usr/lib64/bash/accept /usr/lib64/bash/basename /usr/lib64/bash/csv /usr/lib64/bash/cut /usr/lib64/bash/dirname /usr/lib64/bash/dsv /usr/lib64/bash/fdflags /usr/lib64/bash/finfo /usr/lib64/bash/getconf /usr/lib64/bash/head /usr/lib64/bash/id /usr/lib64/bash/ln /usr/lib64/bash/logname /usr/lib64/bash/mkdir /usr/lib64/bash/mkfifo /usr/lib64/bash/mktemp /usr/lib64/bash/mypid /usr/lib64/bash/pathchk /usr/lib64/bash/print /usr/lib64/bash/printenv /usr/lib64/bash/push /usr/lib64/bash/realpath /usr/lib64/bash/rm /usr/lib64/bash/rmdir /usr/lib64/bash/seq /usr/lib64/bash/setpgid /usr/lib64/bash/sleep /usr/lib64/bash/stat /usr/lib64/bash/strftime /usr/lib64/bash/sync /usr/lib64/bash/tee /usr/lib64/bash/truefalse /usr/lib64/bash/tty /usr/lib64/bash/uname /usr/lib64/bash/unlink /usr/lib64/bash/whoami `enable csv` will not find the loadable builtin `csv` Current work around set in `~/.bashrc` if [[ :$BASH_LOADABLES_PATH: != *:/usr/lib/64/bash:* ]]; then BASH_LOADABLES_PATH="/usr/lib/64/bash:$BASH_LOADABLES_PATH" fi then `source ~/.bashrc` load the loadable builtin csv via `enable csv` then `help csv` csv is just one of the loadable builtin in bash version 5.2 -- You are receiving this mail because: You are on the CC list for the bug.

1 4

[Bug 1204315] [RPi] Kernel 6.0 - [drm] *ERROR* could not acquire memory range
by bugzilla_noreply＠suse.com 02 Nov '22

02 Nov '22

https://bugzilla.suse.com/show_bug.cgi?id=1204315 https://bugzilla.suse.com/show_bug.cgi?id=1204315#c17 --- Comment #17 from Takashi Iwai <tiwai(a)suse.com> --- Then maybe better to have as Kconfig dependency, e.g. --- a/drivers/gpu/drm/tiny/Kconfig +++ b/drivers/gpu/drm/tiny/Kconfig @@ -69,6 +69,7 @@ config DRM_PANEL_MIPI_DBI config DRM_SIMPLEDRM tristate "Simple framebuffer driver" depends on DRM && MMU + depends on SYSFB=n select APERTURE_HELPERS select DRM_GEM_SHMEM_HELPER select DRM_KMS_HELPER -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1201689] bind9.16 and samba-ad-dc-4.15.7 using bind as backed systemd issue
by bugzilla_noreply＠suse.com 02 Nov '22

02 Nov '22

https://bugzilla.suse.com/show_bug.cgi?id=1201689 https://bugzilla.suse.com/show_bug.cgi?id=1201689#c9 Samuel Cabrero <scabrero(a)suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|IN_PROGRESS |RESOLVED Resolution|--- |FIXED --- Comment #9 from Samuel Cabrero <scabrero(a)suse.com> --- Released. -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1204315] [RPi] Kernel 6.0 - [drm] *ERROR* could not acquire memory range
by bugzilla_noreply＠suse.com 02 Nov '22

02 Nov '22

https://bugzilla.suse.com/show_bug.cgi?id=1204315 https://bugzilla.suse.com/show_bug.cgi?id=1204315#c16 --- Comment #16 from Thomas Zimmermann <tzimmermann(a)suse.com> --- Hi I can see the error message on my RPi3. But it's non-critical and we could just ignore it. (In reply to Takashi Iwai from comment #15) > Then maybe we need drm_aperture_remove_conflicting_pci_framebuffers()? e.g. IMHO the code works as expected. It's just that we're seeing two devices for the the same framebuffer. The first is created from the device-tree node [1] and the second is created from the EFI stub that's on the RPi. [2] But the EFI thing just another reference to the device-tree entry, so the memory overlaps. I have to verify all of this, but a fix would be to disable CONFIG_SYSFB on arm if this has no negative impact on other arm systems. [1] https://elixir.bootlin.com/linux/v6.0.6/source/drivers/of/platform.c#L587 [2] https://elixir.bootlin.com/linux/v6.0.6/source/drivers/firmware/sysfb_simpl… -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1180681] New: perf does not resolve plt symbols from libstdc++ right
by bugzilla_noreply＠suse.com 02 Nov '22

02 Nov '22

https://bugzilla.suse.com/show_bug.cgi?id=1180681 Bug ID: 1180681 Summary: perf does not resolve plt symbols from libstdc++ right 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: jslaby(a)suse.com QA Contact: qa-bugs(a)suse.de CC: martin.liska(a)suse.com, matz(a)suse.com, mliska(a)suse.cz, rguenther(a)suse.com, tonyj(a)suse.com Found By: --- Blocker: --- +++ This bug was initially created as a clone of Bug #1180610 +++ There is a problem with *@plt symbols in some libraries, they are unresolved by perf (memcmp@plt in this case): > 0.26% main2 /usr/lib64/libstdc++.so.6.0.28 0xa51a0 l [.] 0x00000000000a51a0 On the other hand, plt symbols in other libraries are fine (memset@plt in this case): > 0.17% main2 /usr/lib64/libantlr4-runtime.so.4.8 0x4ed10 l [.] memset@plt Dump of memcmp's nth .plt.rela entry: /usr/lib64/libantlr4-runtime.so.4.8: 154th addr=4e9d0 plt_off=4e020 hdr=10 entry=10 /usr/lib64/libstdc++.so.6.0.28: 772th addr=a1070 plt_off=9e020 hdr=10 entry=10 The difference (offset) of stdc++'s memcmp is 0xa51a0 (correct) - 0xa1070 (perf's computed) = 0x4130. The problem is perf assumes nth entry of .plt.rela to correspond to nth function in .plt, but memcmp is in .plt.sec in libstdc++.so: > Relocation section '.rela.plt' at offset 0x97900 contains 1018 entries: > Offset Info Type Symbol's Value Symbol's Name + Addend > ... > 00000000001dc838 0000007800000007 R_X86_64_JUMP_SLOT 0000000000000000 memcmp(a)GLIBC_2.2.5 + 0 See: https://github.com/torvalds/linux/blob/f5e6c330254ae691f6d7befe61c786eb5056… It takes symbol index from sym.r_info. Then it resolves its name from .dynsym, appending @plt to it. Then this name is added to symbol table along with address which is computed as .rela.plt index multiplied by entry size (shdr_plt.sh_entsize) plus plt header (shdr_plt.sh_entsize on x86_64 too). And from this comes (almost) the offset above: > $ objdump -h /usr/lib64/libstdc++.so.6|grep -E ' .plt(\.sec)? ' > 12 .plt 00003fb0 000000000009e020 000000000009e020 0009e020 2**4 > 14 .plt.sec 00003fa0 00000000000a2160 00000000000a2160 000a2160 2**4 0xa2160-0x9e020 = 0x4140. I assume the 0x10 difference is that perf adds shdr_plt.sh_entsize (0x10) to the offset to skip the first .plt entry (header). Now, what is .plt.sec? And how should perf find out whether to consider .plt or .plt.sec? Or generally, how to properly find an address of *@plt like memcmp@plt above? -- You are receiving this mail because: You are on the CC list for the bug.

1 6

[Bug 1204313] chronyd not ready when target time-sync.target is reached
by bugzilla_noreply＠suse.com 02 Nov '22

02 Nov '22

https://bugzilla.suse.com/show_bug.cgi?id=1204313 https://bugzilla.suse.com/show_bug.cgi?id=1204313#c3 Reinhard Max <max(a)suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |INVALID --- Comment #3 from Reinhard Max <max(a)suse.com> --- (In reply to Axel Braun from comment #0) > My expectation was that time-sync.target is reached *after* the time is > properly synced. This is obviously not the case. See the section on time-sync.target in the systemd.special(7) man page to synchronize your expectation with the respective specification. ;) > How can we achieve that time is synced when target is reached? Enable chrony-wait.target if you run a system that has no RTC, but is guaranteed to have internet access on boot. Enabling that by default would break e.g. laptops that do have an RTC, but need to be able to boot without network access, e.g. because WiFi can only be connected after the user has logged in. -- You are receiving this mail because: You are on the CC list for the bug.

1 0