May 2022 - openSUSE Bugs - openSUSE Mailing Lists

[Bug 1114273] New: Broadband connection established but all packages dropped
by bugzilla_noreply＠novell.com 10 Jan '23

10 Jan '23

http://bugzilla.opensuse.org/show_bug.cgi?id=1114273 Bug ID: 1114273 Summary: Broadband connection established but all packages dropped Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: x86-64 OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Network Assignee: bnc-team-screening(a)forge.provo.novell.com Reporter: dpbasti(a)wp.pl QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- I tested https://bugzilla.opensuse.org/show_bug.cgi?id=1104571 on 2018.10.31 Tumbleweeed. The same result as on Leap15. All RX and all TX packages are dropped Connection is established, signal strength is good, IP is obtained, Routing is set to default gw received from 4g modem, DNS servers are also received. Cannot even ping gateway. The same setup works as soon as I boot Ubuntu with no different settings in NetworkManager. wwan0: flags=4291<UP,BROADCAST,RUNNING,NOARP,MULTICAST> mtu 1500 inet 10.111.71.20 netmask 255.255.255.248 broadcast 10.111.71.23 inet6 fe80::73fb:926a:b538:f135 prefixlen 64 scopeid 0x20<link> ether 7a:c6:53:8c:bf:03 txqueuelen 1000 (Ethernet) RX packets 0 bytes 0 (0.0 B) RX errors 1280 dropped 0 overruns 0 frame 0 TX packets 0 bytes 0 (0.0 B) TX errors 42 dropped 0 overruns 0 carrier 0 collisions 0 -- You are receiving this mail because: You are on the CC list for the bug.

2 1

[Bug 1187195] New: pulseaudio battery drain
by bugzilla_noreply＠suse.com 10 Jan '23

10 Jan '23

http://bugzilla.opensuse.org/show_bug.cgi?id=1187195 Bug ID: 1187195 Summary: pulseaudio battery drain Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: x86-64 OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Basesystem Assignee: screening-team-bugs(a)suse.de Reporter: dpbasti(a)wp.pl QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- pulsaudio consumes half of total power needed by system powertow run on dell xps17 shows 17W drain of pulsaudio. If input is set to capture mode (enough to enable mic capture in alsamixer) pulsaudio then consumes even double of that. For reference the whole Fedora 34 desktop consumes about 6W on the same machine ! -- You are receiving this mail because: You are on the CC list for the bug.

1 13

[Bug 1123557] New: network:vpn/openvpn: Bug --suppress-timestamps unneeded in systemd unit file?
by bugzilla_noreply＠novell.com 09 Jan '23

09 Jan '23

http://bugzilla.opensuse.org/show_bug.cgi?id=1123557 Bug ID: 1123557 Summary: network:vpn/openvpn: Bug --suppress-timestamps unneeded in systemd unit file? Classification: openSUSE Product: openSUSE.org Version: unspecified Hardware: Other OS: Other Status: NEW Severity: Enhancement Priority: P5 - None Component: 3rd party software Assignee: max(a)suse.com Reporter: jon.brightwell(a)zpg.co.uk QA Contact: bnc-team-screening(a)forge.provo.novell.com CC: nirmoy.das(a)suse.com Found By: --- Blocker: --- It makes logging hard (no timestamps!) and doesn't seem to affect journalctl. I changed mine to ExecStart=/usr/sbin/openvpn --daemon --writepid /run/openvpn/%i.pid --cd /etc/openvpn/ --config %i.conf Does it also need a wait so it doesn't spit of these openvpn(a)lab.service: PID file /run/openvpn/lab.pid not readable (yet?) after start: No such file or directory -- You are receiving this mail because: You are on the CC list for the bug.

2 1

[Bug 1180649] New: amdgpu: [drm] Failed to updateMST allocation table forpipe idx:1
by bugzilla_noreply＠suse.com 09 Jan '23

09 Jan '23

https://bugzilla.suse.com/show_bug.cgi?id=1180649 Bug ID: 1180649 Summary: amdgpu: [drm] Failed to updateMST allocation table forpipe idx:1 Classification: openSUSE Product: openSUSE Distribution Version: Leap 15.2 Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Basesystem Assignee: screening-team-bugs(a)suse.de Reporter: abergmann(a)suse.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- My current openSUSE setup is running into problems with the connected displays via USB-C. From time to time the external monitors stop working and my keyboard and webcam LEDs are blinking irregular. I'm running openSUSE Leap 15.2: Main hardware components: - Lenovo ThinkPad T495 - Lenovo ThinkPad Dock Gen2 - 2 Dell monitors - external keyboard and mouse [ 6418.378375] [drm] Failed to updateMST allocation table forpipe idx:1 [ 6418.378378] ------------[ cut here ]------------ [ 6418.378590] WARNING: CPU: 2 PID: 3084 at ../drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_link.c:2539 core_link_enable_stream+0x820/0x8b0 [amdgpu] [ 6418.378591] Modules linked in: hid_plantronics snd_usb_audio snd_usbmidi_lib snd_rawmidi cdc_ether usbnet r8152 mii snd_seq_dummy snd_hrtimer snd_seq snd_seq_device fuse ccm af_packet xt_tcpudp ip6t_rpfilter ip6t_REJECT nf_reject_ipv6 ipt_REJECT nf_reject_ipv4 xt_conntrack ip_set nfnetlink ebtable_nat ebtable_broute ip6table_nat ip6table_mangle ip6table_raw ip6table_security iptable_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 iptable_mangle iptable_raw iptable_security ebtable_filter ebtables ip6table_filter ip6_tables iptable_filter ip_tables x_tables bpfilter dmi_sysfs bnep xfs uvcvideo v4l2_common videobuf2_vmalloc videobuf2_memops videobuf2_v4l2 videobuf2_common videodev mc btusb btrtl btbcm btintel bluetooth ecdh_generic ecc msr iwlmvm snd_hda_codec_realtek nls_iso8859_1 nls_cp437 edac_mce_amd mac80211 snd_hda_codec_generic vfat kvm_amd ccp fat snd_hda_codec_hdmi libarc4 kvm snd_hda_intel irqbypass snd_hda_codec iwlwifi snd_hda_core snd_hwdep snd_pcm r8169 rtsx_pci_ms [ 6418.378637] thinkpad_acpi cfg80211 joydev sp5100_tco efi_pstore snd_timer ledtrig_audio ipmi_devintf realtek wmi_bmof k10temp i2c_piix4 snd_pci_acp3x memstick mmc_block ipmi_msghandler libphy rfkill snd ucsi_acpi typec_ucsi soundcore typec battery ac i2c_scmi button acpi_cpufreq btrfs libcrc32c xor raid6_pq dm_crypt algif_skcipher af_alg hid_generic usbhid amdgpu rtsx_pci_sdmmc mmc_core crct10dif_pclmul crc32_pclmul amd_iommu_v2 crc32c_intel gpu_sched i2c_algo_bit ghash_clmulni_intel ttm aesni_intel drm_kms_helper syscopyarea aes_x86_64 glue_helper crypto_simd sysfillrect sysimgblt xhci_pci fb_sys_fops nvme xhci_hcd cryptd drm ehci_pci ehci_hcd serio_raw usbcore rtsx_pci nvme_core wmi video sg dm_multipath dm_mod scsi_dh_rdac scsi_dh_emc scsi_dh_alua efivarfs [ 6418.378688] CPU: 2 PID: 3084 Comm: X Not tainted 5.3.18-lp152.57-default #1 openSUSE Leap 15.2 [ 6418.378690] Hardware name: LENOVO 20NJS0KQ07/20NJS0KQ07, BIOS R12ET55W(1.25 ) 07/06/2020 [ 6418.378788] RIP: 0010:core_link_enable_stream+0x820/0x8b0 [amdgpu] [ 6418.378792] Code: 46 a4 00 00 e9 df fc ff ff 49 8b bd a8 00 00 00 e8 15 a5 00 00 48 8b 43 08 e9 2c fd ff ff 48 c7 c7 08 81 a2 c0 e8 7e 9c 7b ed <0f> 0b e9 fa fd ff ff 48 8b 83 10 01 00 00 48 8d 55 ac 88 4d a0 8b [ 6418.378794] RSP: 0018:ffffb0d90279b720 EFLAGS: 00010282 [ 6418.378796] RAX: 0000000000000024 RBX: ffff9831681a0648 RCX: 0000000000000006 [ 6418.378797] RDX: 0000000000000000 RSI: 0000000000000092 RDI: ffff983230899a10 [ 6418.378798] RBP: ffffb0d90279b790 R08: 0000000000000837 R09: 0000000000000001 [ 6418.378799] R10: ffffb0d90015fdc8 R11: 0000000000000001 R12: ffff983226420000 [ 6418.378800] R13: ffff983228ee75e0 R14: 0000000000000006 R15: ffff98321d5f5000 [ 6418.378802] FS: 00007f02153f3ec0(0000) GS:ffff983230880000(0000) knlGS:0000000000000000 [ 6418.378803] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 6418.378805] CR2: 00007f8058c40000 CR3: 00000003aad1a000 CR4: 00000000003406e0 [ 6418.378806] Call Trace: [ 6418.378912] ? dce110_apply_ctx_to_hw+0x48d/0x520 [amdgpu] [ 6418.379007] dce110_apply_ctx_to_hw+0x48d/0x520 [amdgpu] [ 6418.379112] ? dcn10_verify_allow_pstate_change_high+0x1d/0x2d0 [amdgpu] [ 6418.379216] dc_commit_state+0x2cc/0x5d0 [amdgpu] [ 6418.379324] amdgpu_dm_atomic_commit_tail+0x393/0x1e10 [amdgpu] [ 6418.379335] ? ktime_get_raw+0x34/0x90 [ 6418.379407] ? amdgpu_bo_pin_restricted+0x68/0x290 [amdgpu] [ 6418.379415] ? ttm_eu_backoff_reservation+0x5e/0x90 [ttm] [ 6418.379486] ? amdgpu_bo_gpu_offset+0x1f/0x90 [amdgpu] [ 6418.379589] ? dm_plane_helper_prepare_fb+0x158/0x2a0 [amdgpu] [ 6418.379596] ? _cond_resched+0x15/0x40 [ 6418.379599] ? wait_for_completion_timeout+0x35/0x150 [ 6418.379602] ? wait_for_completion_interruptible+0x32/0x190 [ 6418.379617] ? commit_tail+0x3d/0x80 [drm_kms_helper] [ 6418.379628] commit_tail+0x3d/0x80 [drm_kms_helper] [ 6418.379641] drm_atomic_helper_commit+0x107/0x130 [drm_kms_helper] [ 6418.379663] drm_atomic_connector_commit_dpms+0xe5/0xf0 [drm] [ 6418.379687] drm_mode_obj_set_property_ioctl+0x19f/0x2e0 [drm] [ 6418.379712] ? drm_connector_set_obj_prop+0x70/0x70 [drm] [ 6418.379734] drm_connector_property_set_ioctl+0x3e/0x60 [drm] [ 6418.379754] drm_ioctl_kernel+0xac/0xf0 [drm] [ 6418.379773] drm_ioctl+0x2eb/0x3b0 [drm] [ 6418.379796] ? drm_connector_set_obj_prop+0x70/0x70 [drm] [ 6418.379802] ? ___sys_recvmsg+0xa2/0xe0 [ 6418.379871] amdgpu_drm_ioctl+0x49/0x80 [amdgpu] [ 6418.379878] do_vfs_ioctl+0xa0/0x680 [ 6418.379883] ? ep_modify+0x6d/0x150 [ 6418.379886] ksys_ioctl+0x70/0x80 [ 6418.379889] __x64_sys_ioctl+0x16/0x20 [ 6418.379894] do_syscall_64+0x65/0x1f0 [ 6418.379897] entry_SYSCALL_64_after_hwframe+0x44/0xa9 [ 6418.379900] RIP: 0033:0x7f0212cd9ac7 [ 6418.379903] Code: b3 66 90 48 8b 05 d1 13 2c 00 64 c7 00 26 00 00 00 48 c7 c0 ff ff ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 b8 10 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d a1 13 2c 00 f7 d8 64 89 01 48 [ 6418.379904] RSP: 002b:00007fff1d436fd8 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 [ 6418.379906] RAX: ffffffffffffffda RBX: 0000563a09792310 RCX: 00007f0212cd9ac7 [ 6418.379907] RDX: 00007fff1d437010 RSI: 00000000c01064ab RDI: 000000000000000c [ 6418.379908] RBP: 00007fff1d437010 R08: 0000000000000001 R09: 0000000000000009 [ 6418.379909] R10: 0000563a09bdf8b0 R11: 0000000000000246 R12: 00000000c01064ab [ 6418.379910] R13: 000000000000000c R14: 0000563a09901f10 R15: 0000563a08a2ed00 -- You are receiving this mail because: You are on the CC list for the bug.

1 5

[Bug 1187796] New: Missing remote attestation system roles in the control.xml
by bugzilla_noreply＠suse.com 09 Jan '23

09 Jan '23

http://bugzilla.opensuse.org/show_bug.cgi?id=1187796 Bug ID: 1187796 Summary: Missing remote attestation system roles in the control.xml Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: MicroOS Assignee: kubic-bugs(a)opensuse.org Reporter: aplanas(a)suse.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- To integrate keylime and the remote attestation feature in MicroOS, we need two new system roles: one to add the verifier and another to add the agent. -- You are receiving this mail because: You are on the CC list for the bug.

1 3

[Bug 1167780] New: MicroOS images don't update grub if booted without EFI
by bugzilla_noreply＠novell.com 09 Jan '23

09 Jan '23

http://bugzilla.suse.com/show_bug.cgi?id=1167780 Bug ID: 1167780 Summary: MicroOS images don't update grub if booted without EFI Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: MicroOS Assignee: fvogt(a)suse.com Reporter: fvogt(a)suse.com QA Contact: qa-bugs(a)suse.de CC: kubic-bugs(a)opensuse.org Found By: --- Blocker: --- The .qcow2 images are meant to work fine on systems with EFI (optionally secure boot) and without, so they have both i386-pc and x86_64-efi targets of grub2 installed by kiwi during image building. Kiwi sets LOADER_TYPE="grub2-efi" for this. When booting the image without EFI though, this is not changed by anything and so update-bootloader only manages the x86_64-efi target of grub2. As the grub.cfg file is in the same location, there aren't any immediate issues, but it means that grub is never updated in those deployments. -- You are receiving this mail because: You are on the CC list for the bug.

2 13

[Bug 1190256] New: Keyboard not working on ASUS Zenbook 14 UM425UA
by bugzilla_noreply＠suse.com 09 Jan '23

09 Jan '23

https://bugzilla.suse.com/show_bug.cgi?id=1190256 Bug ID: 1190256 Summary: Keyboard not working on ASUS Zenbook 14 UM425UA Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: x86-64 OS: openSUSE Tumbleweed Status: NEW Severity: Normal Priority: P5 - None Component: Basesystem Assignee: screening-team-bugs(a)suse.de Reporter: mkrapp(a)suse.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- I got a new ASUS Zenbook 14 UM524UA. Unfortunately keyboard is not at all working in latest Tumbleweed with kernel 5.14.0-1-default. I: Bus=0018 Vendor=04f3 Product=3134 Version=0100 N: Name="ASUE140A:00 04F3:3134 Keyboard" P: Phys=i2c-ASUE140A:00 S: Sysfs=/devices/platform/AMDI0010:03/i2c-0/i2c-ASUE140A:00/0018:04F3:3134.0001/input/input8 U: Uniq= H: Handlers=sysrq kbd leds event5 B: PROP=0 B: EV=120013 B: KEY=1000000000007 ff800000000007ff febeffdfffefffff fffffffffffffffe B: MSC=10 B: LED=1f It's recognized during boot: > Aug 31 20:00:01 localhost kernel: input: ASUE140A:00 04F3:3134 Mouse as /devices/platform/AMDI0010:03/i2c-0/i2c-ASUE140A:00/0018:04F3:3134.0001/input/input3 > Aug 31 20:00:01 localhost kernel: input: ASUE140A:00 04F3:3134 Touchpad as /devices/platform/AMDI0010:03/i2c-0/i2c-ASUE140A:00/0018:04F3:3134.0001/input/input4 > Aug 31 20:00:01 localhost kernel: input: ASUE140A:00 04F3:3134 Keyboard as /devices/platform/AMDI0010:03/i2c-0/i2c-ASUE140A:00/0018:04F3:3134.0001/input/input5 > Aug 31 20:00:01 localhost kernel: hid-generic 0018:04F3:3134.0001: input,hidraw0: I2C HID v1.00 Mouse [ASUE140A:00 04F3:3134] on i2c-ASUE140A:00 but not working at all. no events created when pressing/releasing keys. The touchpad works fine, albeit I didn't try to get the extra function working (numpad on touchpad) yet. I'll attach hwinfo and journal in a minute. Any idea how I can get the keyboard working? -- You are receiving this mail because: You are on the CC list for the bug.

1 65

[Bug 1181974] New: Lenovo X1 Extreme Gen.3: suspend/hibernate to ram doesn't work properly
by bugzilla_noreply＠suse.com 08 Jan '23

08 Jan '23

http://bugzilla.opensuse.org/show_bug.cgi?id=1181974 Bug ID: 1181974 Summary: Lenovo X1 Extreme Gen.3: suspend/hibernate to ram doesn't work properly Classification: openSUSE Product: openSUSE Distribution Version: Leap 15.2 Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Basesystem Assignee: screening-team-bugs(a)suse.de Reporter: p.heinlein(a)heinlein-support.de QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- Created attachment 845928 --> http://bugzilla.opensuse.org/attachment.cgi?id=845928&action=edit output hwinfo On Lenovo X1 Extreme Gen.3 suspend/hibernate to RAM doesn't work properly. 5.3.18-lp152.63-default openSUSE Leap 15.2 If I close the cover it suspends/hibernates and starts sleeping, but when I re-open the cover it does not survive beeing awaked. Instead, it works $something for half a second and then it powers of completely. After pressing the power button, it does a complete cold boot. In rare cases it did survive a suspend and it did awake properly. But only in very rare cases. dmesg logs: systemd-logind: hibernation is restricted; see man kernel_lockdown.7 Lockdown: hwinfo: /dev/mem,kmem,port is restricted; see man kernel_lockdown.7 Lockdown: modprobe: unsafe module parameters is restricted; see man kernel_lockdown.7 -- You are receiving this mail because: You are on the CC list for the bug.

1 8

[Bug 1052765] New: net-snmp still use SysVinit boot scripts
by bugzilla_noreply＠novell.com 06 Jan '23

06 Jan '23

http://bugzilla.suse.com/show_bug.cgi?id=1052765 Bug ID: 1052765 Summary: net-snmp still use SysVinit boot scripts Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: All OS: openSUSE Factory Status: NEW Severity: Critical Priority: P5 - None Component: Network Assignee: bnc-team-screening(a)forge.provo.novell.com Reporter: werner(a)suse.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- Please port the boot script AFAP to systemd units: rpm -ql net-snmp | grep init\\.d /etc/init.d/snmpd /etc/init.d/snmptrapd this because as net-snmp will also reach SLES15 -- You are receiving this mail because: You are on the CC list for the bug.

2 4

[Bug 1199941] New: kmozillahelper uses up all X clients given enough logout/login cycles
by bugzilla_noreply＠suse.com 04 Jan '23

04 Jan '23

http://bugzilla.opensuse.org/show_bug.cgi?id=1199941 Bug ID: 1199941 Summary: kmozillahelper uses up all X clients given enough logout/login cycles Classification: openSUSE Product: openSUSE Distribution Version: Leap 15.4 Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Firefox Assignee: factory-mozilla(a)lists.opensuse.org Reporter: marix(a)marix.org QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- A couple days ago I ran into the issue of applications no longer starting reliably on my openSUSE Leap 15.4 system. Launching applications like "glxinfo" or "xlsclients" would fail with the error message `Maximum number of clients reached: unable to open display ":0"`. In searching for the error message I came across https://unix.stackexchange.com/questions/250920/debugging-maximum-number-of…. Using the method described there to get the application using up the most x client connections, I found that kmozillahelper was using up more than 170 of them. Closing Firefox and one `killall kmozillahelper` later I could reliably start applications again. While my immediate problem is gone, it seems that there seems to be a leak of kmozillahelper process instances when restoring a KDE session after having logged out with an open Firefox. I.e., on third login after the killall, a `ps aux | grep kmozillahelper` will produce the following: marix 5109 0.0 0.1 413872 44192 ? Sl 11:10 0:00 /usr/lib/mozilla/kmozillahelper -session 10ca646469000165348143300000027740024_1653489712_189016 marix 5144 0.0 0.1 413872 44184 ? Sl 11:10 0:00 /usr/lib/mozilla/kmozillahelper -session 10ca646469000165348930800000285810021_1653489712_189016 marix 6070 0.2 0.1 416140 46532 ? Sl 11:10 0:00 /usr/lib/mozilla/kmozillahelper Stopping Firefox will kill the process that does not have a -session argument. However, if I logout without closing Firefox first, the next login will show four kmozillahelper processes of which three have a with -session. The two already existing in the current session, and a third one with a new sessionid. As the session-id-less process instance is properly cleaned up if Firefox is closed during a session, the problem can be worked around by closing Firefox before logging out. However, this kind of contradicts the point of having resumable sessions. -- You are receiving this mail because: You are on the CC list for the bug.

1 2