October 2022 - openSUSE Bugs - openSUSE Mailing Lists

[Bug 1195496] TW/Nvidia hangs at boot with Optimus graphic and 510.47.03 (G06) driver - but still works with G05 drivers
by bugzilla_noreply＠suse.com 05 Oct '22

05 Oct '22

https://bugzilla.suse.com/show_bug.cgi?id=1195496 https://bugzilla.suse.com/show_bug.cgi?id=1195496#c24 --- Comment #24 from Stefan Dirsch <sndirsch(a)suse.com> --- (In reply to Daniel Dadap from comment #23) > (In reply to Stefan Dirsch from comment #20) > > So the issue is only on TW? Strange ... > > > If the TW kernel is using the simpledrm FB driver, this is unfortunately > expected for now. We are still working on support for simpledrm. Hmm. But we add option "nosimplefb=1" to kernel boot commandline on TW, so this should not be the issue here. Check with cat /proc/cmdline if it's set. -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1183247] starting lxc container failes with GDBus.Error:org.freedesktop.machine1.NoMachineForPID: PID 4370 does not belong to any known machine
by bugzilla_noreply＠suse.com 05 Oct '22

05 Oct '22

https://bugzilla.suse.com/show_bug.cgi?id=1183247 https://bugzilla.suse.com/show_bug.cgi?id=1183247#c29 --- Comment #29 from Michal Koutn� <mkoutny(a)suse.com> --- (In reply to Eric van Blokland from comment #28) > I've been hit by this as well and had to shelve some upgrades. Is it the same issue like the initial comment? I.e. 'GDBus.Error:org.freedesktop.machine1.NoMachineForPID:'? What process does the offending PID refer to (is it the PID 1 of the container?) Can you check what's in /proc/$PID/cgroup (when the error occurs)? TY > Tumbleweed is working fine at the moment. FTR, openSUSE TW defaults to the unified (v2) hierarchy now and it's not affected (was confirmed in comment 4). -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1195496] TW/Nvidia hangs at boot with Optimus graphic and 510.47.03 (G06) driver - but still works with G05 drivers
by bugzilla_noreply＠suse.com 05 Oct '22

05 Oct '22

https://bugzilla.suse.com/show_bug.cgi?id=1195496 https://bugzilla.suse.com/show_bug.cgi?id=1195496#c23 --- Comment #23 from Daniel Dadap <ddadap(a)nvidia.com> --- (In reply to Stefan Dirsch from comment #20) > So the issue is only on TW? Strange ... If the TW kernel is using the simpledrm FB driver, this is unfortunately expected for now. We are still working on support for simpledrm. -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1196357] [riscv64][Unmatched] system boot takes long time at efistub
by bugzilla_noreply＠suse.com 05 Oct '22

05 Oct '22

https://bugzilla.suse.com/show_bug.cgi?id=1196357 https://bugzilla.suse.com/show_bug.cgi?id=1196357#c6 --- Comment #6 from Chester Lin <chester.lin(a)suse.com> --- (In reply to Chester Lin from comment #5) > (In reply to Matthias Brugger from comment #4) > > Chester did you use the SD card shipped with the board, or some different > > one? I'm asking because we have seen issues with SD card on the unmatch in > > the past: > > https://bugzilla.suse.com/show_bug.cgi?id=1197422#c15 > > Hi Matthias, > > I've tried three kinds of micro SD as below and they all have the same > symptom (low-speed read while loading bigger files in u-boot/efistub such as > initrd): > > 1. SanDisk Ultra 32GB Class 10 A1 with the preload image (Shipped with the > board) > 2. SanDisk Ultra 32GB Class 10 with tumbleweed (*No* A1 tag on the card) > 3. A-Data 32GB Class 10 with tumbleweed. I also tried booting the tumbleweed from NVMe drive [WD Blue SN550 NVMe SSD] and then manually copied the initrd from the microSD (SanDisk 32GB without A1 tag) to both NVMe and /tmp [tmpfs]. In this scenario, the read speed was just improved a little bit [-20 seconds] but it still took around 1 minute to finish the file copy. ====== localhost:~ # mount /dev/mmcblk0p3 /root/mnt/ localhost:~ # localhost:~ # df -hT Filesystem Type Size Used Avail Use% Mounted on devtmpfs devtmpfs 4.0M 0 4.0M 0% /dev tmpfs tmpfs 7.8G 0 7.8G 0% /dev/shm tmpfs tmpfs 3.2G 10M 3.2G 1% /run /dev/nvme0n1p3 ext4 917G 2.2G 869G 1% / tmpfs tmpfs 7.8G 0 7.8G 0% /tmp /dev/nvme0n1p1 vfat 16M 2.6M 14M 16% /boot/efi tmpfs tmpfs 1.6G 0 1.6G 0% /run/user/0 /dev/mmcblk0p3 ext4 29G 1.5G 26G 6% /root/mnt localhost:~ # localhost:~ # time cp /root/mnt/boot/initrd-5.19.12-1-default / real 1m2.766s user 0m0.000s sys 0m1.122s localhost:~ # localhost:~ # sync; echo 3 > /proc/sys/vm/drop_caches localhost:~ # localhost:~ # time cp /root/mnt/boot/initrd-5.19.12-1-default /tmp/ real 1m2.766s user 0m0.001s sys 0m0.768s localhost:~ # -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1197298] QEMU downstream patches break persistent binfmt registration by default
by bugzilla_noreply＠suse.com 05 Oct '22

05 Oct '22

https://bugzilla.suse.com/show_bug.cgi?id=1197298 https://bugzilla.suse.com/show_bug.cgi?id=1197298#c63 --- Comment #63 from Dario Faggioli <dfaggioli(a)suse.com> --- (In reply to Dirk Mueller from comment #57) > (In reply to Dirk Mueller from comment #55) > > > > So we can drop the other pieces in a week or so at least from factory. > > OBS/IBS patches have landed and are deployed, we can drop this now as well. > Well, much more than a week passed... So I'm sure we're safe to get rid of pretty much everything now. I've done this, and it's in the devel project. I'll push to factory soon, and close this bug when that is done -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1190012] dlmopen BUG on Tumbleweed - symbol lookup error: /lib64/libnss_compat.so.2: undefined symbol: _nss_compat_endaliasent
by bugzilla_noreply＠suse.com 05 Oct '22

05 Oct '22

https://bugzilla.suse.com/show_bug.cgi?id=1190012 https://bugzilla.suse.com/show_bug.cgi?id=1190012#c1 Andreas Schwab <schwab(a)suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #1 from Andreas Schwab <schwab(a)suse.com> --- This has been fixed in 2.34. -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1196357] [riscv64][Unmatched] system boot takes long time at efistub
by bugzilla_noreply＠suse.com 05 Oct '22

05 Oct '22

https://bugzilla.suse.com/show_bug.cgi?id=1196357 https://bugzilla.suse.com/show_bug.cgi?id=1196357#c5 Chester Lin <chester.lin(a)suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Flags|needinfo?(chester.lin@suse. | |com) | --- Comment #5 from Chester Lin <chester.lin(a)suse.com> --- (In reply to Matthias Brugger from comment #4) > Chester did you use the SD card shipped with the board, or some different > one? I'm asking because we have seen issues with SD card on the unmatch in > the past: > https://bugzilla.suse.com/show_bug.cgi?id=1197422#c15 Hi Matthias, I've tried three kinds of micro SD as below and they all have the same symptom (low-speed read while loading bigger files in u-boot/efistub such as initrd): 1. SanDisk Ultra 32GB Class 10 A1 with the preload image (Shipped with the board) 2. SanDisk Ultra 32GB Class 10 with tumbleweed (*No* A1 tag on the card) 3. A-Data 32GB Class 10 with tumbleweed. -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1194055] chromium: SIGABRT when using GCC 11
by bugzilla_noreply＠suse.com 05 Oct '22

05 Oct '22

https://bugzilla.suse.com/show_bug.cgi?id=1194055 https://bugzilla.suse.com/show_bug.cgi?id=1194055#c5 Callum Farmer <gmbr3(a)opensuse.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #5 from Callum Farmer <gmbr3(a)opensuse.org> --- fixed -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1203854] New: Command criu dump fails on Tumbleweed and ALP
by bugzilla_noreply＠suse.com 05 Oct '22

05 Oct '22

https://bugzilla.suse.com/show_bug.cgi?id=1203854 Bug ID: 1203854 Summary: Command criu dump fails on Tumbleweed and ALP 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: jlopez(a)suse.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- Dumping a process does not work. Runnning this simple loop test [1] fails on TW using criu-3.17.1 (although the same version works on Leap 15.4): (00.015852) Collecting fds (pid: 8313) (00.015856) ---------------------------------------- (00.015904) Found 4 file descriptors (00.015908) ---------------------------------------- (00.015931) Dump private signals of 8313 (00.015940) Dump shared signals of 8313 (00.015948) Dump rseq of 8313: ptr = 0x7f8df8e18f60 sign = 0x53053053 (00.015973) Parasite syscall_ip at 0x55f78eb6f000 (00.016150) Set up parasite blob using memfd (00.016201) Putting parasite blob into 0x7f5700f79000->0x7f8df8b34000 (00.016318) Dumping general registers for 8313 in native mode (00.016333) Dumping GP/FPU registers for 8313 (00.016357) x86: xsave runtime structure (00.016364) x86: ----------------------- (00.016367) x86: cwd:0x37f swd:0 twd:0 fop:0 mxcsr:0x1f80 mxcsr_mask:0xffff (00.016371) x86: magic1:0x46505853 extended_size:1092 xstate_bv:0x17 xstate_size:1088 (00.016378) x86: xstate_bv: 0x17 (00.016381) x86: ----------------------- (00.016384) Putting tsock into pid 8313 (00.016432) Error (criu/parasite-syscall.c:88): si_code=4 si_pid=8313 si_status=11 (00.016441) Error (criu/parasite-syscall.c:95): 8313 was stopped by 11 unexpectedly This was detected when testing podman checkpoints in TW and ALP (with cockpit), as part of the 1:1 system management workgroup. [1] https://criu.org/Simple_loop -- You are receiving this mail because: You are on the CC list for the bug.

1 9

[Bug 1203991] New: Thermald on openSUSE disables active power management, hindering performance
by bugzilla_noreply＠suse.com 05 Oct '22

05 Oct '22

http://bugzilla.opensuse.org/show_bug.cgi?id=1203991 Bug ID: 1203991 Summary: Thermald on openSUSE disables active power management, hindering performance Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Basesystem Assignee: screening-team-bugs(a)suse.de Reporter: tjyrinki(a)suse.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- Thermald in openSUSE currently sets --disable-active-power by default. It is done in two places /etc/sysconfig/thermald and /usr/lib/systemd/system/thermald.service. This removes the performance benefits thermald would provide. Currently on Fedora (https://kojipkgs.fedoraproject.org//packages/thermald/2.5/2.fc38/x86_64/the…) Debian (https://packages.debian.org/sid/amd64/thermald/download) and Ubuntu (https://launchpad.net/ubuntu/+source/thermald/2.5.1-1/+build/24492675) thermald is enabled by its normal defaults, /usr/sbin/thermald --systemd --dbus-enable --adaptive. With openSUSE's disabling, my Tiger Lake laptop under continous CPU load gives around 2200-2300MHz and consumes (pkgWatt in turbostat) around 15W (TDP of the CPU would be 28W). With the normal defaults, the CPU raises to 2900MHz with 20W consumption on my current example. For briefer periods, also a lot higher frequences can be kept for a short time. The disabling was added in openSUSE in January 2020, without citing bugs but probably as a precaution, at the same time upstream introduced the new features. Upstream stated back then "To disable all the above performance optimization, use --disable-active-power". -- You are receiving this mail because: You are on the CC list for the bug.

1 4