June 2019 - openSUSE Bugs - openSUSE Mailing Lists

[Bug 1052150] New: ASIX ax88179 USB ethernet disconnects with error
by bugzilla_noreply＠novell.com 11 Aug '21

11 Aug '21

http://bugzilla.suse.com/show_bug.cgi?id=1052150 Bug ID: 1052150 Summary: ASIX ax88179 USB ethernet disconnects with error Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Kernel Assignee: kernel-maintainers(a)forge.provo.novell.com Reporter: tonyj(a)suse.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- Created attachment 735177 --> http://bugzilla.suse.com/attachment.cgi?id=735177&action=edit supportconfig Anker USB 3.0 ethernet adapter randomly disconnects. Seems a known issue but I don't see any fixes: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1333003 https://bugzilla.redhat.com/show_bug.cgi?id=1238617 link comes up after inserting adapter into USB3 port, generate some minor traffic (nature of traffic not relevant, ftp/scp/ssh all reproduce) and link drops. amount of time it takes varies. supposedly doesn't occur on USB2 but I've not tried this. latest 4.11.8-2-default kernel but it's been broken for a fair while. Hardware in question is a Macbook Pro (USB3) but I don't think it is on above redhat/ubuntu bugs. dmesg below, support config attached [11493.769864] usb 4-1: new SuperSpeed USB device number 3 using xhci_hcd [11493.796691] usb 4-1: New USB device found, idVendor=0b95, idProduct=1790 [11493.796696] usb 4-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [11493.796699] usb 4-1: Product: AX88179 [11493.796701] usb 4-1: Manufacturer: ASIX Elec. Corp. [11493.796703] usb 4-1: SerialNumber: 0000000000015E [11494.131928] ax88179_178a 4-1:1.0 eth0: register 'ax88179_178a' at usb-0000:00:14.0-1, ASIX AX88179 USB 3.0 Gigabit Ethernet, 00:00:0d:00:ee:30 [11494.153818] ax88179_178a 4-1:1.0 enp0s20u1: renamed from eth0 [11494.204082] IPv6: ADDRCONF(NETDEV_UP): enp0s20u1: link is not ready [11494.529718] IPv6: ADDRCONF(NETDEV_UP): enp0s20u1: link is not ready [11497.127891] ax88179_178a 4-1:1.0 enp0s20u1: ax88179 - Link status is: 1 [11497.133370] IPv6: ADDRCONF(NETDEV_CHANGE): enp0s20u1: link becomes ready [12021.041777] xhci_hcd 0000:00:14.0: Cannot set link state. [12021.041788] usb usb4-port1: cannot disable (err = -32) [12021.041793] usb 4-1: USB disconnect, device number 3 [12021.042026] ax88179_178a 4-1:1.0 enp0s20u1: unregister 'ax88179_178a' usb-0000:00:14.0-1, ASIX AX88179 USB 3.0 Gigabit Ethernet [12021.042053] ax88179_178a 4-1:1.0 enp0s20u1: Failed to read reg index 0x0002: -19 [12021.042056] ax88179_178a 4-1:1.0 enp0s20u1: Failed to write reg index 0x0002: -19 [12021.061697] ax88179_178a 4-1:1.0 enp0s20u1 (unregistered): Failed to write reg index 0x0002: -19 [12021.061699] ax88179_178a 4-1:1.0 enp0s20u1 (unregistered): Failed to write reg index 0x0001: -19 [12021.061700] ax88179_178a 4-1:1.0 enp0s20u1 (unregistered): Failed to write reg index 0x0002: -19 -- You are receiving this mail because: You are on the CC list for the bug.

2 5

[Bug 1139285] New: NetworkManager no longer saves VPN passwords
by bugzilla_noreply＠novell.com 11 Aug '21

11 Aug '21

http://bugzilla.suse.com/show_bug.cgi?id=1139285 Bug ID: 1139285 Summary: NetworkManager no longer saves VPN passwords Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Basesystem Assignee: bnc-team-screening(a)forge.provo.novell.com Reporter: msuchanek(a)suse.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- When connecting to VPN NM always asks for password. When opening the VPN properties there is no password shown. -- You are receiving this mail because: You are on the CC list for the bug.

2 4

[Bug 1130674] New: Download bar in chromium unreadable with dark theme
by bugzilla_noreply＠novell.com 11 Aug '21

11 Aug '21

http://bugzilla.suse.com/show_bug.cgi?id=1130674 Bug ID: 1130674 Summary: Download bar in chromium unreadable with dark theme Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: X11 Applications Assignee: bnc-team-screening(a)forge.provo.novell.com Reporter: msuchanek(a)suse.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- Created attachment 801344 --> http://bugzilla.suse.com/attachment.cgi?id=801344&action=edit screenshot Picture attached. easily reproducible with the Mate dark GTK theme shipped in openSUSE i+ | mate-themes | package | 3.22.18-1.2 | noarch | Tumbleweed -- You are receiving this mail because: You are on the CC list for the bug.

2 2

[Bug 1026449] New: vagrant fails configuring VM network
by bugzilla_noreply＠novell.com 09 Aug '21

09 Aug '21

http://bugzilla.opensuse.org/show_bug.cgi?id=1026449 Bug ID: 1026449 Summary: vagrant fails configuring VM network Classification: openSUSE Product: openSUSE Distribution Version: Leap 42.1 Hardware: Other OS: openSUSE 42.1 Status: NEW Severity: Normal Priority: P5 - None Component: Virtualization:Other Assignee: virt-bugs(a)suse.de Reporter: dennis.keck(a)rock5.de QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- Using 1.9.1-9.1-x86_64 from Virtualization When using vagrant up for a Ubuntu VM with configured "vm.network" this error occurs: /usr/share/vagrant/plugins/guests/debian/cap/configure_networks.rb:3:in `require_relative': cannot load such file -- /usr/share/vagrant/plugins/guests/debian/cap/vagrant/util/template_renderer (LoadError) This happens because of a wrongly set require_relative which is still just like it should be when using vagrant as a rubygem. See this bugreport on the Debian bug mailing list: https://www.mail-archive.com/debian-bugs-dist@lists.debian.org/msg1449666.h… This change should be applied to all distribution specific configure_networks.rb templates. Full error output: /usr/share/vagrant/plugins/guests/debian/cap/configure_networks.rb:3:in `require_relative': cannot load such file -- /usr/share/vagrant/plugins/guests/debian/cap/vagrant/util/template_renderer (LoadError) from /usr/share/vagrant/plugins/guests/debian/cap/configure_networks.rb:3:in `<top (required)>' from /usr/share/vagrant/plugins/guests/debian/plugin.rb:15:in `require_relative' from /usr/share/vagrant/plugins/guests/debian/plugin.rb:15:in `block in <class:Plugin>' from /usr/lib64/ruby/gems/2.1.0/gems/vagrant-1.9.1/lib/vagrant/registry.rb:27:in `call' from /usr/lib64/ruby/gems/2.1.0/gems/vagrant-1.9.1/lib/vagrant/registry.rb:27:in `get' from /usr/lib64/ruby/gems/2.1.0/gems/vagrant-1.9.1/lib/vagrant/capability_host.rb:170:in `block in capability_module' from /usr/lib64/ruby/gems/2.1.0/gems/vagrant-1.9.1/lib/vagrant/capability_host.rb:164:in `each' from /usr/lib64/ruby/gems/2.1.0/gems/vagrant-1.9.1/lib/vagrant/capability_host.rb:164:in `capability_module' from /usr/lib64/ruby/gems/2.1.0/gems/vagrant-1.9.1/lib/vagrant/capability_host.rb:92:in `capability' from /usr/lib64/ruby/gems/2.1.0/gems/vagrant-1.9.1/lib/vagrant/guest.rb:43:in `capability' from /usr/share/vagrant/plugins/providers/virtualbox/action/network.rb:133:in `call' from /usr/lib64/ruby/gems/2.1.0/gems/vagrant-1.9.1/lib/vagrant/action/warden.rb:34:in `call' from /usr/share/vagrant/plugins/providers/virtualbox/action/clear_network_interfaces.rb:26:in `call' from /usr/lib64/ruby/gems/2.1.0/gems/vagrant-1.9.1/lib/vagrant/action/warden.rb:34:in `call' from /usr/share/vagrant/plugins/providers/virtualbox/action/prepare_nfs_settings.rb:18:in `call' from /usr/lib64/ruby/gems/2.1.0/gems/vagrant-1.9.1/lib/vagrant/action/warden.rb:34:in `call' from /usr/lib64/ruby/gems/2.1.0/gems/vagrant-1.9.1/lib/vagrant/action/builtin/synced_folders.rb:87:in `call' from /usr/lib64/ruby/gems/2.1.0/gems/vagrant-1.9.1/lib/vagrant/action/warden.rb:34:in `call' from /usr/lib64/ruby/gems/2.1.0/gems/vagrant-1.9.1/lib/vagrant/action/builtin/synced_folder_cleanup.rb:28:in `call' from /usr/lib64/ruby/gems/2.1.0/gems/vagrant-1.9.1/lib/vagrant/action/warden.rb:34:in `call' from /usr/share/vagrant/plugins/synced_folders/nfs/action_cleanup.rb:25:in `call' from /usr/lib64/ruby/gems/2.1.0/gems/vagrant-1.9.1/lib/vagrant/action/warden.rb:34:in `call' from /usr/share/vagrant/plugins/providers/virtualbox/action/prepare_nfs_valid_ids.rb:12:in `call' from /usr/lib64/ruby/gems/2.1.0/gems/vagrant-1.9.1/lib/vagrant/action/warden.rb:34:in `call' from /usr/lib64/ruby/gems/2.1.0/gems/vagrant-1.9.1/lib/vagrant/action/builtin/handle_forwarded_port_collisions.rb:49:in `call' from /usr/lib64/ruby/gems/2.1.0/gems/vagrant-1.9.1/lib/vagrant/action/warden.rb:34:in `call' from /usr/share/vagrant/plugins/providers/virtualbox/action/prepare_forwarded_port_collision_params.rb:30:in `call' from /usr/lib64/ruby/gems/2.1.0/gems/vagrant-1.9.1/lib/vagrant/action/warden.rb:34:in `call' from /usr/lib64/ruby/gems/2.1.0/gems/vagrant-1.9.1/lib/vagrant/action/builtin/env_set.rb:19:in `call' from /usr/lib64/ruby/gems/2.1.0/gems/vagrant-1.9.1/lib/vagrant/action/warden.rb:34:in `call' from /usr/lib64/ruby/gems/2.1.0/gems/vagrant-1.9.1/lib/vagrant/action/builtin/provision.rb:80:in `call' from /usr/lib64/ruby/gems/2.1.0/gems/vagrant-1.9.1/lib/vagrant/action/warden.rb:34:in `call' from /usr/share/vagrant/plugins/providers/virtualbox/action/clear_forwarded_ports.rb:15:in `call' from /usr/lib64/ruby/gems/2.1.0/gems/vagrant-1.9.1/lib/vagrant/action/warden.rb:34:in `call' from /usr/share/vagrant/plugins/providers/virtualbox/action/set_name.rb:19:in `call' from /usr/lib64/ruby/gems/2.1.0/gems/vagrant-1.9.1/lib/vagrant/action/warden.rb:34:in `call' from /usr/share/vagrant/plugins/providers/virtualbox/action/clean_machine_folder.rb:17:in `call' from /usr/lib64/ruby/gems/2.1.0/gems/vagrant-1.9.1/lib/vagrant/action/warden.rb:34:in `call' from /usr/share/vagrant/plugins/providers/virtualbox/action/check_accessible.rb:18:in `call' from /usr/lib64/ruby/gems/2.1.0/gems/vagrant-1.9.1/lib/vagrant/action/warden.rb:34:in `call' from /usr/lib64/ruby/gems/2.1.0/gems/vagrant-1.9.1/lib/vagrant/action/warden.rb:95:in `block in finalize_action' from /usr/lib64/ruby/gems/2.1.0/gems/vagrant-1.9.1/lib/vagrant/action/warden.rb:34:in `call' from /usr/lib64/ruby/gems/2.1.0/gems/vagrant-1.9.1/lib/vagrant/action/warden.rb:34:in `call' from /usr/lib64/ruby/gems/2.1.0/gems/vagrant-1.9.1/lib/vagrant/action/builder.rb:116:in `call' from /usr/lib64/ruby/gems/2.1.0/gems/vagrant-1.9.1/lib/vagrant/action/runner.rb:66:in `block in run' from /usr/lib64/ruby/gems/2.1.0/gems/vagrant-1.9.1/lib/vagrant/util/busy.rb:19:in `busy' from /usr/lib64/ruby/gems/2.1.0/gems/vagrant-1.9.1/lib/vagrant/action/runner.rb:66:in `run' from /usr/lib64/ruby/gems/2.1.0/gems/vagrant-1.9.1/lib/vagrant/action/builtin/call.rb:53:in `call' from /usr/lib64/ruby/gems/2.1.0/gems/vagrant-1.9.1/lib/vagrant/action/warden.rb:34:in `call' from /usr/lib64/ruby/gems/2.1.0/gems/vagrant-1.9.1/lib/vagrant/action/warden.rb:95:in `block in finalize_action' from /usr/lib64/ruby/gems/2.1.0/gems/vagrant-1.9.1/lib/vagrant/action/warden.rb:34:in `call' from /usr/lib64/ruby/gems/2.1.0/gems/vagrant-1.9.1/lib/vagrant/action/warden.rb:34:in `call' from /usr/lib64/ruby/gems/2.1.0/gems/vagrant-1.9.1/lib/vagrant/action/builder.rb:116:in `call' from /usr/lib64/ruby/gems/2.1.0/gems/vagrant-1.9.1/lib/vagrant/action/runner.rb:66:in `block in run' from /usr/lib64/ruby/gems/2.1.0/gems/vagrant-1.9.1/lib/vagrant/util/busy.rb:19:in `busy' from /usr/lib64/ruby/gems/2.1.0/gems/vagrant-1.9.1/lib/vagrant/action/runner.rb:66:in `run' from /usr/lib64/ruby/gems/2.1.0/gems/vagrant-1.9.1/lib/vagrant/action/builtin/call.rb:53:in `call' from /usr/lib64/ruby/gems/2.1.0/gems/vagrant-1.9.1/lib/vagrant/action/warden.rb:34:in `call' from /usr/lib64/ruby/gems/2.1.0/gems/vagrant-1.9.1/lib/vagrant/action/warden.rb:95:in `block in finalize_action' from /usr/lib64/ruby/gems/2.1.0/gems/vagrant-1.9.1/lib/vagrant/action/warden.rb:34:in `call' from /usr/lib64/ruby/gems/2.1.0/gems/vagrant-1.9.1/lib/vagrant/action/warden.rb:34:in `call' from /usr/lib64/ruby/gems/2.1.0/gems/vagrant-1.9.1/lib/vagrant/action/builder.rb:116:in `call' from /usr/lib64/ruby/gems/2.1.0/gems/vagrant-1.9.1/lib/vagrant/action/runner.rb:66:in `block in run' from /usr/lib64/ruby/gems/2.1.0/gems/vagrant-1.9.1/lib/vagrant/util/busy.rb:19:in `busy' from /usr/lib64/ruby/gems/2.1.0/gems/vagrant-1.9.1/lib/vagrant/action/runner.rb:66:in `run' from /usr/lib64/ruby/gems/2.1.0/gems/vagrant-1.9.1/lib/vagrant/action/builtin/call.rb:53:in `call' from /usr/lib64/ruby/gems/2.1.0/gems/vagrant-1.9.1/lib/vagrant/action/warden.rb:34:in `call' from /usr/lib64/ruby/gems/2.1.0/gems/vagrant-1.9.1/lib/vagrant/action/builtin/box_check_outdated.rb:78:in `call' from /usr/lib64/ruby/gems/2.1.0/gems/vagrant-1.9.1/lib/vagrant/action/warden.rb:34:in `call' from /usr/lib64/ruby/gems/2.1.0/gems/vagrant-1.9.1/lib/vagrant/action/builtin/config_validate.rb:25:in `call' from /usr/lib64/ruby/gems/2.1.0/gems/vagrant-1.9.1/lib/vagrant/action/warden.rb:34:in `call' from /usr/share/vagrant/plugins/providers/virtualbox/action/check_virtualbox.rb:17:in `call' from /usr/lib64/ruby/gems/2.1.0/gems/vagrant-1.9.1/lib/vagrant/action/warden.rb:34:in `call' from /usr/lib64/ruby/gems/2.1.0/gems/vagrant-1.9.1/lib/vagrant/action/warden.rb:95:in `block in finalize_action' from /usr/lib64/ruby/gems/2.1.0/gems/vagrant-1.9.1/lib/vagrant/action/warden.rb:34:in `call' from /usr/lib64/ruby/gems/2.1.0/gems/vagrant-1.9.1/lib/vagrant/action/warden.rb:34:in `call' from /usr/lib64/ruby/gems/2.1.0/gems/vagrant-1.9.1/lib/vagrant/action/warden.rb:95:in `block in finalize_action' from /usr/lib64/ruby/gems/2.1.0/gems/vagrant-1.9.1/lib/vagrant/action/warden.rb:34:in `call' from /usr/lib64/ruby/gems/2.1.0/gems/vagrant-1.9.1/lib/vagrant/action/warden.rb:34:in `call' from /usr/lib64/ruby/gems/2.1.0/gems/vagrant-1.9.1/lib/vagrant/action/builder.rb:116:in `call' from /usr/lib64/ruby/gems/2.1.0/gems/vagrant-1.9.1/lib/vagrant/action/runner.rb:66:in `block in run' from /usr/lib64/ruby/gems/2.1.0/gems/vagrant-1.9.1/lib/vagrant/util/busy.rb:19:in `busy' from /usr/lib64/ruby/gems/2.1.0/gems/vagrant-1.9.1/lib/vagrant/action/runner.rb:66:in `run' from /usr/lib64/ruby/gems/2.1.0/gems/vagrant-1.9.1/lib/vagrant/action/builtin/call.rb:53:in `call' from /usr/lib64/ruby/gems/2.1.0/gems/vagrant-1.9.1/lib/vagrant/action/warden.rb:34:in `call' from /usr/lib64/ruby/gems/2.1.0/gems/vagrant-1.9.1/lib/vagrant/action/builtin/config_validate.rb:25:in `call' from /usr/lib64/ruby/gems/2.1.0/gems/vagrant-1.9.1/lib/vagrant/action/warden.rb:34:in `call' from /usr/lib64/ruby/gems/2.1.0/gems/vagrant-1.9.1/lib/vagrant/action/warden.rb:95:in `block in finalize_action' from /usr/lib64/ruby/gems/2.1.0/gems/vagrant-1.9.1/lib/vagrant/action/warden.rb:34:in `call' from /usr/lib64/ruby/gems/2.1.0/gems/vagrant-1.9.1/lib/vagrant/action/warden.rb:34:in `call' from /usr/lib64/ruby/gems/2.1.0/gems/vagrant-1.9.1/lib/vagrant/action/warden.rb:95:in `block in finalize_action' from /usr/lib64/ruby/gems/2.1.0/gems/vagrant-1.9.1/lib/vagrant/action/warden.rb:34:in `call' from /usr/lib64/ruby/gems/2.1.0/gems/vagrant-1.9.1/lib/vagrant/action/warden.rb:34:in `call' from /usr/lib64/ruby/gems/2.1.0/gems/vagrant-1.9.1/lib/vagrant/action/builder.rb:116:in `call' from /usr/lib64/ruby/gems/2.1.0/gems/vagrant-1.9.1/lib/vagrant/action/runner.rb:66:in `block in run' from /usr/lib64/ruby/gems/2.1.0/gems/vagrant-1.9.1/lib/vagrant/util/busy.rb:19:in `busy' from /usr/lib64/ruby/gems/2.1.0/gems/vagrant-1.9.1/lib/vagrant/action/runner.rb:66:in `run' from /usr/lib64/ruby/gems/2.1.0/gems/vagrant-1.9.1/lib/vagrant/action/builtin/call.rb:53:in `call' from /usr/lib64/ruby/gems/2.1.0/gems/vagrant-1.9.1/lib/vagrant/action/warden.rb:34:in `call' from /usr/share/vagrant/plugins/providers/virtualbox/action/check_virtualbox.rb:17:in `call' from /usr/lib64/ruby/gems/2.1.0/gems/vagrant-1.9.1/lib/vagrant/action/warden.rb:34:in `call' from /usr/lib64/ruby/gems/2.1.0/gems/vagrant-1.9.1/lib/vagrant/action/builder.rb:116:in `call' from /usr/lib64/ruby/gems/2.1.0/gems/vagrant-1.9.1/lib/vagrant/action/runner.rb:66:in `block in run' from /usr/lib64/ruby/gems/2.1.0/gems/vagrant-1.9.1/lib/vagrant/util/busy.rb:19:in `busy' from /usr/lib64/ruby/gems/2.1.0/gems/vagrant-1.9.1/lib/vagrant/action/runner.rb:66:in `run' from /usr/lib64/ruby/gems/2.1.0/gems/vagrant-1.9.1/lib/vagrant/machine.rb:225:in `action_raw' from /usr/lib64/ruby/gems/2.1.0/gems/vagrant-1.9.1/lib/vagrant/machine.rb:200:in `block in action' from /usr/lib64/ruby/gems/2.1.0/gems/vagrant-1.9.1/lib/vagrant/environment.rb:533:in `lock' from /usr/lib64/ruby/gems/2.1.0/gems/vagrant-1.9.1/lib/vagrant/machine.rb:186:in `call' from /usr/lib64/ruby/gems/2.1.0/gems/vagrant-1.9.1/lib/vagrant/machine.rb:186:in `action' from /usr/lib64/ruby/gems/2.1.0/gems/vagrant-1.9.1/lib/vagrant/batch_action.rb:82:in `block (2 levels) in run' -- You are receiving this mail because: You are on the CC list for the bug.

2 1

[Bug 977987] New: Kernel NULL pointer dereference crash from "t-daemon"
by bugzilla_noreply＠novell.com 03 Aug '21

03 Aug '21

http://bugzilla.suse.com/show_bug.cgi?id=977987 Bug ID: 977987 Summary: Kernel NULL pointer dereference crash from "t-daemon" Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: x86-64 OS: Other Status: NEW Severity: Critical Priority: P5 - None Component: Kernel Assignee: kernel-maintainers(a)forge.provo.novell.com Reporter: lmb(a)suse.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- The current tumbleweed kernel crashes for me on boot - it continues to run, but the OS hangs in random places. Going back to 4.4.3 and system is stable. Kernel details: kernel-default-4.5.0-3.3.x86_64 Source Timestamp: 2016-03-28 09:27:57 +0200 GIT Revision: 8cf0ce6b84d58647e9ee955bc81db84023542f5f GIT Branch: stable Distribution: openSUSE Factory Logs with a bit of context: -- Logs begin at Wed 2014-10-01 14:53:05 CEST, end at Mon 2016-05-02 09:54:42 CEST. -- May 02 09:41:16 hermes dbus[1569]: [system] Activating via systemd: service name='org.freedesktop.RealtimeKit1' unit='rtkit-daemon.service' May 02 09:41:16 hermes systemd[1]: Starting RealtimeKit Scheduling Policy Service... May 02 09:41:16 hermes audit: NETFILTER_CFG table=filter family=10 entries=0 May 02 09:41:16 hermes audit: NETFILTER_CFG table=mangle family=10 entries=0 May 02 09:41:16 hermes audit: NETFILTER_CFG table=filter family=2 entries=0 May 02 09:41:16 hermes audit: NETFILTER_CFG table=raw family=2 entries=0 May 02 09:41:16 hermes audit: NETFILTER_CFG table=raw family=10 entries=0 May 02 09:41:16 hermes audit: NETFILTER_CFG table=nat family=2 entries=0 May 02 09:41:16 hermes audit[3200]: SYSCALL arch=c000003e syscall=272 success=yes exit=0 a0=40000000 a1=7ffcc5e4ed20 a2=fffffffffffffff5 a3=7fcebc3088c0 items=0 ppid=1 pid=3200 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="(t-daemon)" exe="/usr/lib/systemd/systemd" key=(null) May 02 09:41:16 hermes audit: PROCTITLE proctitle="(t-daemon)" May 02 09:41:16 hermes kernel: audit: type=1325 audit(1462174876.310:161): table=filter family=10 entries=0 May 02 09:41:16 hermes kernel: audit: type=1325 audit(1462174876.310:161): table=mangle family=10 entries=0 May 02 09:41:16 hermes kernel: audit: type=1325 audit(1462174876.310:161): table=filter family=2 entries=0 May 02 09:41:16 hermes kernel: audit: type=1325 audit(1462174876.310:161): table=raw family=2 entries=0 May 02 09:41:16 hermes kernel: audit: type=1325 audit(1462174876.310:161): table=raw family=10 entries=0 May 02 09:41:16 hermes kernel: audit: type=1325 audit(1462174876.310:161): table=nat family=2 entries=0 May 02 09:41:16 hermes kernel: audit: type=1300 audit(1462174876.310:161): arch=c000003e syscall=272 success=yes exit=0 a0=40000000 a1=7ffcc5e4ed20 a2=fffffffffffffff5 a3=7fcebc3088c0 items=0 ppid=1 pid=3200 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="(t-daemon)" exe="/usr/lib/systemd/systemd" key=(null) May 02 09:41:16 hermes kernel: audit: type=1327 audit(1462174876.310:161): proctitle="(t-daemon)" May 02 09:41:16 hermes kernel: BUG: unable to handle kernel NULL pointer dereference at 0000000000000060 May 02 09:41:16 hermes kernel: IP: [<ffffffff8122c06a>] copy_tree+0x13a/0x370 May 02 09:41:16 hermes kernel: PGD 0 May 02 09:41:16 hermes kernel: Oops: 0000 [#1] PREEMPT SMP May 02 09:41:16 hermes kernel: Modules linked in: fuse ebtable_filter ebtables nf_log_ipv6 ipt_MASQUERADE nf_nat_masquerade_ipv4 xt_pkttype xt_physdev br_netfilter xt_TCPMSS nf_log_ipv4 nf_log_common xt_LOG xt_limit iptable_nat nf_nat_ipv4 nf_nat af_packet bridge stp llc iscsi_ibft iscsi_boot_sysfs uvcvideo btusb videobuf2_vmalloc videobuf2_memops btrtl btbcm videobuf2_v4l2 videobuf2_core btintel videodev bluetooth arc4 msr iTCO_wdt iTCO_vendor_support snd_hda_codec_realtek snd_hda_codec_generic intel_rapl x86_pkg_temp_thermal intel_powerclamp coretemp kvm_intel kvm irqbypass iwlmvm mac80211 snd_hda_intel ghash_clmulni_intel snd_hda_codec rtsx_pci_ms pcspkr snd_hda_core iwlwifi snd_hwdep joydev snd_pcm i2c_i801 e1000e lpc_ich mei_me memstick snd_timer cfg80211 ptp mei pps_core thinkpad_acpi shpchp rfkill battery ac May 02 09:41:16 hermes kernel: snd fjes wmi soundcore thermal tpm_tis tpm ip6t_REJECT nf_reject_ipv6 xt_tcpudp nf_conntrack_ipv6 nf_defrag_ipv6 ip6table_raw ipt_REJECT nf_reject_ipv4 iptable_raw xt_CT iptable_filter ip6table_mangle nf_conntrack_netbios_ns nf_conntrack_broadcast nf_conntrack_ipv4 nf_defrag_ipv4 ip_tables xt_conntrack nf_conntrack ip6table_filter ip6_tables x_tables xfs libcrc32c drbg ansi_cprng dm_crypt algif_skcipher af_alg hid_generic usbhid rtsx_pci_sdmmc mmc_core crct10dif_pclmul crc32_pclmul crc32c_intel aesni_intel aes_x86_64 glue_helper lrw gf128mul ablk_helper cryptd serio_raw i915 i2c_algo_bit drm_kms_helper syscopyarea sysfillrect sysimgblt ehci_pci fb_sys_fops ehci_hcd xhci_pci xhci_hcd rtsx_pci mfd_core usbcore drm usb_common video button dm_mirror dm_region_hash dm_log dm_mod sg May 02 09:41:16 hermes kernel: CPU: 1 PID: 3200 Comm: (t-daemon) Not tainted 4.5.0-3-default #1 May 02 09:41:16 hermes kernel: Hardware name: LENOVO 20AR000YAT/20AR000YAT, BIOS GJET78WW (2.28 ) 07/29/2014 May 02 09:41:16 hermes kernel: task: ffff8802feb92080 ti: ffff8803046b4000 task.ti: ffff8803046b4000 May 02 09:41:16 hermes kernel: RIP: 0010:[<ffffffff8122c06a>] [<ffffffff8122c06a>] copy_tree+0x13a/0x370 May 02 09:41:16 hermes kernel: RSP: 0018:ffff8803046b7e00 EFLAGS: 00010246 May 02 09:41:16 hermes kernel: RAX: 0000000000000000 RBX: ffff88032f6cc3c0 RCX: 000000000000000f May 02 09:41:16 hermes kernel: RDX: 0000000000000004 RSI: 0000000000000000 RDI: ffffffff81e0a4c4 May 02 09:41:16 hermes kernel: RBP: ffff8803046b7e50 R08: 0000000000000000 R09: 00000000000000ff May 02 09:41:16 hermes kernel: R10: 0000000000001494 R11: 0000000000015789 R12: ffff88009ecf2b00 May 02 09:41:16 hermes kernel: R13: ffff88031fae2540 R14: ffff88032e6ecfa0 R15: ffff88032f24b800 May 02 09:41:16 hermes kernel: FS: 00007fcebc3088c0(0000) GS:ffff88033e240000(0000) knlGS:0000000000000000 May 02 09:41:16 hermes kernel: CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 May 02 09:41:16 hermes kernel: CR2: 0000000000000060 CR3: 00000002ff7f8000 CR4: 00000000001406e0 May 02 09:41:16 hermes kernel: Stack: May 02 09:41:16 hermes kernel: ffff88017e1bfe10 ffff88017f802b58 ffff88009ecf2b88 0000000500000000 May 02 09:41:16 hermes kernel: ffffffff00000004 ffff88017e1bfdc0 ffff88033055b700 ffff8803304ea5c0 May 02 09:41:16 hermes kernel: ffffffff81e44760 ffff88017e917a40 ffff8803046b7e90 ffffffff8122d549 May 02 09:41:16 hermes kernel: Call Trace: May 02 09:41:16 hermes kernel: [<ffffffff8122d549>] copy_mnt_ns+0x79/0x290 May 02 09:41:16 hermes kernel: [<ffffffff8109c742>] create_new_namespaces+0x62/0x190 May 02 09:41:16 hermes kernel: [<ffffffff8109c9ea>] unshare_nsproxy_namespaces+0x5a/0xb0 May 02 09:41:16 hermes kernel: [<ffffffff8107d1a1>] SyS_unshare+0x1a1/0x330 May 02 09:41:16 hermes kernel: [<ffffffff816cc0b2>] entry_SYSCALL_64_fastpath+0x16/0x71 May 02 09:41:16 hermes kernel: DWARF2 unwinder stuck at entry_SYSCALL_64_fastpath+0x16/0x71 May 02 09:41:16 hermes kernel: May 02 09:41:16 hermes kernel: Leftover inexact backtrace: May 02 09:41:16 hermes kernel: Code: 48 8b 43 60 48 39 45 b0 48 8d 58 a0 75 8c 4c 89 e0 48 83 c4 28 5b 41 5c 41 5d 41 5e 41 5f 5d c3 8b 45 c8 49 8b 76 20 85 c0 75 0e <48> 81 7e 60 80 31 83 81 0f 84 c8 01 00 00 49 8b 46 10 4c 39 e8 May 02 09:41:16 hermes kernel: RIP [<ffffffff8122c06a>] copy_tree+0x13a/0x370 May 02 09:41:16 hermes kernel: RSP <ffff8803046b7e00> May 02 09:41:16 hermes kernel: CR2: 0000000000000060 May 02 09:41:16 hermes kernel: ---[ end trace f848a64a7ccebe9d ]--- May 02 09:41:16 hermes kernel: audit: type=1130 audit(1462174876.354:162): pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=rtkit-daemon comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=failed' May 02 09:41:16 hermes audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=rtkit-daemon comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=failed' May 02 09:41:16 hermes systemd[1]: rtkit-daemon.service: Main process exited, code=killed, status=9/KILL May 02 09:41:16 hermes systemd[1]: Failed to start RealtimeKit Scheduling Policy Service. May 02 09:41:16 hermes systemd[1]: rtkit-daemon.service: Unit entered failed state. May 02 09:41:16 hermes systemd[1]: rtkit-daemon.service: Failed with result 'signal'. -- You are receiving this mail because: You are on the CC list for the bug.

2 3

[Bug 899501] New: Only one display wakes up after powersave
by bugzilla_noreply＠novell.com 03 Aug '21

03 Aug '21

http://bugzilla.suse.com/show_bug.cgi?id=899501 Bug ID: 899501 Summary: Only one display wakes up after powersave Classification: openSUSE Product: openSUSE Factory Version: 201409* Hardware: x86-64 OS: Other Status: NEW Severity: Major Priority: P5 - None Component: X.Org Assignee: bnc-team-xorg-bugs(a)forge.provo.novell.com Reporter: lmb(a)suse.com QA Contact: xorg-maintainer-bugs(a)forge.provo.novell.com Found By: --- Blocker: --- Created attachment 608781 --> http://bugzilla.suse.com/attachment.cgi?id=608781&action=edit Xorg.0.log I have a Lenovo Thinkpad T440s with Intel graphics. I'm using a dual monitor setup - the internal 1920x1080 display on eDP1 and a 1920x1200 screen (HP ZR24w on DP4 via the docking station). (Running Factory as of now, but tried 13.2b1 yesterday and had the same effect.) Leaving the system alone for a bit leads to the screens being turned off (powersave). However, only the internal display wakes up again; the external output remains in power-save mode. (e.g., the monitor doesn't find any signal on any port.) I tried using xrandr --output --off and turning it on with --auto again, turning off the monitor itself, etc. No change; the only apparent way to resolve this and get my external monitor back is to reboot, which seems a bit harsh. Any suggestions? 00:02.0 VGA compatible controller: Intel Corporation Haswell-ULT Integrated Graphics Controller (rev 0b) Screen 0: minimum 8 x 8, current 1920 x 1200, maximum 32767 x 32767 eDP1 connected 1920x1080+0+0 (normal left inverted right x axis y axis) 309mm x 175mm 1920x1080 60.01*+ 1400x1050 59.98 1280x1024 60.02 1280x960 60.00 1024x768 60.00 800x600 60.32 56.25 640x480 59.94 DP1 disconnected (normal left inverted right x axis y axis) DP2 disconnected (normal left inverted right x axis y axis) DP3 disconnected (normal left inverted right x axis y axis) DP4 connected 1920x1200+0+0 (normal left inverted right x axis y axis) 546mm x 352mm 1920x1200 59.95*+ 1920x1080 59.99 1600x1200 60.00 1680x1050 59.95 1280x1024 60.02 1440x900 59.89 1280x960 60.00 1024x768 60.00 800x600 60.32 640x480 60.00 DP5 disconnected (normal left inverted right x axis y axis) HDMI1 disconnected (normal left inverted right x axis y axis) HDMI2 disconnected (normal left inverted right x axis y axis) VIRTUAL1 disconnected (normal left inverted right x axis y axis) Pl -- You are receiving this mail because: You are on the CC list for the bug.

2 4

[Bug 901887] New: Lenovo t440s / Intel 4400: External display non-functional
by bugzilla_noreply＠novell.com 03 Aug '21

03 Aug '21

http://bugzilla.suse.com/show_bug.cgi?id=901887 Bug ID: 901887 Summary: Lenovo t440s / Intel 4400: External display non-functional Classification: openSUSE Product: openSUSE Factory Version: 201410* Hardware: x86-64 OS: Other Status: NEW Severity: Major Priority: P5 - None Component: X.Org Assignee: bnc-team-xorg-bugs(a)forge.provo.novell.com Reporter: lmb(a)suse.com QA Contact: xorg-maintainer-bugs(a)forge.provo.novell.com Found By: --- Blocker: --- Created attachment 610633 --> http://bugzilla.suse.com/attachment.cgi?id=610633&action=edit Xorg.0.log On the same system where I experienced bug 899501, I've updated the system to a later Factory build and can now no longer activate my external display at all. Though xrandr reports: Screen 0: minimum 8 x 8, current 1920 x 1200, maximum 32767 x 32767 eDP1 connected 1920x1080+0+0 (normal left inverted right x axis y axis) 309mm x 175mm 1920x1080 60.01*+ 1400x1050 59.98 1280x1024 60.02 1280x960 60.00 1024x768 60.00 800x600 60.32 56.25 640x480 59.94 DP1 disconnected (normal left inverted right x axis y axis) DP2 disconnected (normal left inverted right x axis y axis) DP3 disconnected (normal left inverted right x axis y axis) DP4 connected 1920x1200+0+0 (normal left inverted right x axis y axis) 546mm x 352mm 1920x1200 59.95*+ 1920x1080 59.99 1600x1200 60.00 1680x1050 59.95 1280x1024 60.02 1440x900 59.89 1280x960 60.00 1024x768 60.00 800x600 60.32 640x480 60.00 DP5 disconnected (normal left inverted right x axis y axis) The output on DP4 is black, and the monitor does not detect a signal. -- You are receiving this mail because: You are on the CC list for the bug.

2 6

[Bug 903189] New: USB trackball not detected on reboot
by bugzilla_noreply＠novell.com 03 Aug '21

03 Aug '21

http://bugzilla.suse.com/show_bug.cgi?id=903189 Bug ID: 903189 Summary: USB trackball not detected on reboot Classification: openSUSE Product: openSUSE Factory Version: 201410* Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Kernel Assignee: kernel-maintainers(a)forge.provo.novell.com Reporter: lmb(a)suse.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- Created attachment 611775 --> http://bugzilla.suse.com/attachment.cgi?id=611775&action=edit lsusb -v directly after reboot After a reboot, the kernel doesn't detect the USB attached trackball automatically. I have to unplug and plug it in again. I'm attaching lsusb output directly after a reboot and after the unplug/plug step (to the same USB port). Note that it is attached to a port on the docking station. -- You are receiving this mail because: You are on the CC list for the bug.

2 2

[Bug 922992] New: Enable GNU Terry Pratchett in default Apache configuration
by bugzilla_noreply＠novell.com 03 Aug '21

03 Aug '21

http://bugzilla.suse.com/show_bug.cgi?id=922992 Bug ID: 922992 Summary: Enable GNU Terry Pratchett in default Apache configuration Classification: openSUSE Product: openSUSE Factory Version: 201502* Hardware: Other OS: Other Status: NEW Severity: Enhancement Priority: P5 - None Component: Basesystem Assignee: bnc-team-screening(a)forge.provo.novell.com Reporter: lmb(a)suse.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- As per http://www.gnuterrypratchett.com/#apache, I suggest to enable this in the default apache configuration on openSUSE. -- You are receiving this mail because: You are on the CC list for the bug.

2 2

[Bug 1101735] New: 40grub2: debug messages
by bugzilla_noreply＠novell.com 31 Jul '21

31 Jul '21

http://bugzilla.opensuse.org/show_bug.cgi?id=1101735 Bug ID: 1101735 Summary: 40grub2: debug messages Classification: openSUSE Product: openSUSE Distribution Version: Leap 15.0 Hardware: x86-64 OS: Other Status: NEW Severity: Minor Priority: P5 - None Component: Bootloader Assignee: jsrain(a)suse.com Reporter: novell(a)howorth.org.uk QA Contact: jsrain(a)suse.com Found By: --- Blocker: --- there are a lot of messages in /var/log/messages that start with 40grub2: debug: parsing: Why are they there and how do I get them to stop? PS Why is openSUSE Leap 15.0 not in the list of OS? -- You are receiving this mail because: You are on the CC list for the bug.

2 6