[Bug 1575867] [NEW] unity-settings-daemon crashes on start with SIGABRT if xrandr provides two displays with the same name
Public bug reported: -- Symptoms -- I am experiencing this bug after a recent upgrade to Ubuntu 16.04, with unity-settings-daemon 15.04.1+16.04.20160209. unity-settings-daemon always fails to start (leaving me with a quasi- functional desktop); when run from a command-line, it simply outputs: ** ERROR:gsd-rr-config.c:661:gsd_rr_config_load_current: assertion failed: (gsd_rr_config_match (config, config)) Aborted and crashes with SIGABRT. This is 100% reproducible on my system. I have investigated the cause of this crash, and I can provide a patch that solves this bug. I do not know whether I shall help fixing this bug here, or if should I work with the upstream directly, a word of advice in this matter would be very appreciated. -- Bug analysis and proposed solution -- The mentioned assertion fails even though it compares the same configuration with itself. What gsd_rr_config_match does internally is that it takes each output from a configuration one by one, and searches - by name - for a matching output in the other config. If the search fails, or the found output does not match the one from first config, the gsd_rr_config_match check fails. Because of that, this check should never fail when comparing a configuration to itself, with the exception of one (presumably rare) care. It happens that, for my multi-monitor setup, libxrandr reports that there are two different outputs that share the same name "DP-1". In this case, the gsd_rr_config_match fails, because when searching for a matching output named "DP-1", it will return the same output both times, and therefore one pair will be not matching (the find_output function returns the first output that matches requested name). Therefore it appears that comparing configurations by checking whether outputs with matching names are equivalent may be wrong, because the output names are not guaranteed to be unique. I propose to modify both configuration comparing procedures (gsd_rr_config_match and gsd_rr_config_equal) so that they compare outputs matching them by their ids, which will always be unique due to their nature. Since the find_output function (which takes an output name as an argument) is only used by these two comparing functions, it makes sense to modify it so that it takes an output id as an argument instead. This is a valid solution, because in this case even if output names happen to repeat, the output ids will be used to distinguish between them, and gsd_rr_config_match will no longer incorrectly fail. Also, the proposed change will never cause a configuration comparing function to return true where it would otherwise not, because each two outputs with a different name will always have a different id as well. I attach to this bug report a patch that implements the proposed changes. Applying this patch entirely fixed the described symptoms on my machine. ** Affects: unity-settings-daemon (Ubuntu) Importance: Undecided Status: New ** Patch added: "A patch that implements the proposed fix." https://bugs.launchpad.net/bugs/1575867/+attachment/4649396/+files/fix_config_matching.patch -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1575867 Title: unity-settings-daemon crashes on start with SIGABRT if xrandr provides two displays with the same name To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/unity-settings-daemon/+bug/1575867/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1575960] [NEW] gpu-manager: get_alternative_link() NEVER checks for a correct alternative
Public bug reported: I suppose this is a fairly significant bug, since it renders gpu-manager virtually useless. I found it in ubuntu-drivers-common 0.4.17 (which is the current version in Ubuntu 16.04), and I do not know whether it is also present in other versions. -- Symptoms -- For some reason, on my machine I frequently insert and remove my nvidia graphics adapter. My processor has an intel HD graphics adapter as well, so I rely on gpu-manager to detect my hardware configuration during boot, and update alternatives appropriately. However, since I upgraded to Ubuntu 16.04, reconfiguring my hardware makes me unable to boot to desktop. However, reverting to previous hardware configuration solves the issue. -- Analysis and proposed solution -- A quick check of symbolic links at /etc/ld.so.conf.d/x86_64-linux- gnu_GL.conf and similar confirms that when I change my hardware configuration, no changes are done to the targets of these links. Reading through gpu-manager.log I can see that it detects my hardware correctly, but it fails to configure alternatives, because: Error: no alternative found for nvidia Warning: no EGL alternative found for nvidia Further investigation shows that the problem is with the get_alternative_link() function, as it always returns NULL, regardless of my current hardware configuration, and function arguments. The get_alternative_link() function works by querying the list of available alternatives by running `update-alternatives` command with `--list` argument. The command is prepared by: snprintf(command, sizeof(command), "update-alternatives --list %s_%s_conf", alternative_pattern, arch_path); For example, when looking for "gl" alternatives for architecture "x86_64 -linux-gnu", the resulting command will be: update-alternatives --list gl_x86_64-linux-gnu_conf This command always returns an empty list, and that is correct. The command is clearly malformed, the intention was to run another command, namely: update-alternatives --list x86_64-linux-gnu_gl_conf (note the order of "gl" vs "x86_64_linux_gnu") Indeed the `snprintf` used to prepare the command has it's arguments swapped. Therefore I propose to substitute the mentioned source code with: snprintf(command, sizeof(command), "update-alternatives --list %s_%s_conf", arch_path, alternative_pattern); Applying the proposed change reliably fixes the bug symptoms I experienced. -- Additional comment -- For your convenience, I attached to this bug report a patch file that applies the proposed solution; the patch is intended for ubuntu-drivers-common 0.4.17 source. As far as I can tell, due to these swapped arguments gpu-manager always looks for unexisting alternatives, and therefore there is no scenario in which it would correctly configure alternatives. I suppose in this case gpu-manager always fails to serve its purpose. I find it astonishing that nobody noticed this issue yet. ** Affects: ubuntu-drivers-common (Ubuntu) Importance: Undecided Status: New ** Patch added: "fix_alternative_argument_order.patch" https://bugs.launchpad.net/bugs/1575960/+attachment/4649621/+files/fix_alternative_argument_order.patch -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1575960 Title: gpu-manager: get_alternative_link() NEVER checks for a correct alternative To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/ubuntu-drivers-common/+bug/1575960/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1575960] Re: gpu-manager: get_alternative_link() NEVER checks for a correct alternative
I confirm that installing 1:0.4.17.1 from -proposed fixes this bug for me. ** Tags removed: verification-needed ** Tags added: verification-done -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1575960 Title: gpu-manager: get_alternative_link() NEVER checks for a correct alternative To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/ubuntu-drivers-common/+bug/1575960/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1485236] [NEW] gpu-manager generates an invalid xorg.conf file
Public bug reported: I use Ubuntu 15.04. I have both a nvidia graphics card and an integrated intel one. Sometimes, I boot my system without nvidia card, and sometimes with both. Until recently this setup worked correctly, so that when the nvidia card was enabled, the system would boot up using nvidia drivers, and in the other case it would use intel card. Now I am unable to boot up without nvidia card. Booting with it removes the xorg.conf file (it is empty). When I reboot with intel card only, Xorg fails to start because of the following error: Data incomplete in file /etc/X11/xorg.conf Undefined Screen "nvidia" referenced by ServerLayout "layout". I check gpu-manager's logs, and indeed it claims to have generated the xorg.conf file: ==gpu-manager.log== log_file: /var/log/gpu-manager.log last_boot_file: /var/lib/ubuntu-drivers-common/last_gfx_boot new_boot_file: /var/lib/ubuntu-drivers-common/last_gfx_boot grep dmesg status 0 dmesg status 0 == 0? Yes grep dmesg status 256 dmesg status 256 == 0? No Is nvidia loaded? no Was nvidia unloaded? yes Is nvidia blacklisted? no Is fglrx loaded? no Was fglrx unloaded? no Is fglrx blacklisted? no Is intel loaded? yes Is radeon loaded? no Is radeon blacklisted? no Is nouveau loaded? no Is nouveau blacklisted? yes Is fglrx kernel module available? no Is nvidia kernel module available? yes Vendor/Device Id: 8086:412 BusID "PCI:0@0:2:0" Is boot vga? yes Vendor/Device Id: 10de:1184 BusID "PCI:1@0:0:0" Is boot vga? no The device is a pci passthrough. Skipping... Skipping "/dev/dri/card0", driven by "i915" Skipping "/dev/dri/card0", driven by "i915" Found "/dev/dri/card0", driven by "i915" output 0: DisplayPort connector Number of connected outputs for /dev/dri/card0: 1 Does it require offloading? yes last cards number = 1 Has amd? no Has intel? yes Has nvidia? no How many cards? 1 Has the system changed? No main_arch_path x86_64-linux-gnu, other_arch_path i386-linux-gnu Current alternative: /usr/lib/x86_64-linux-gnu/mesa/ld.so.conf Current core alternative: (null) Is nvidia enabled? no Is fglrx enabled? no Is mesa enabled? yes Is pxpress enabled? no Is prime enabled? no Is nvidia available? no Is fglrx available? no Is fglrx-core available? no Is mesa available? yes Is pxpress available? no Is prime available? no Single card detected PRIME detected pci bus from dmesg status 0 can't open /sys/module/nvidia/version /sys/class/dmi/id/product_version="To Be Filled By O.E.M." /sys/class/dmi/id/product_name="To Be Filled By O.E.M." 1st try: bbswitch without quirks Loading bbswitch with "load_state=-1 unload_state=1" parameters 2nd try: bbswitch with quirks Loading bbswitch with "load_state=-1 unload_state=1 skip_optimus_dsm=1" parameters Warning: can't load bbswitch, switching between GPUs won't work Selecting nvidia Error: no alternative found for nvidia Error: failed to enable the driver Selecting mesa /usr/bin/update-alternatives --set x86_64-linux-gnu_gl_conf /usr/lib/x86_64-linux-gnu/mesa/ld.so.conf update-alternatives status 0 Calling ldconfig ldconfig status 0 /usr/bin/update-alternatives --set i386-linux-gnu_gl_conf /usr/lib/i386-linux-gnu/mesa/ld.so.conf update-alternatives status 0 Calling ldconfig ldconfig status 0 Error: no alternative found for unblacklist Removing xorg.conf. Path: /etc/X11/xorg.conf can't access /etc/X11/xorg.conf Check failed Removing xorg.conf. Path: /etc/X11/xorg.conf Moved /etc/X11/xorg.conf to /etc/X11/xorg.conf.08152015 Regenerating xorg.conf. Path: /etc/X11/xorg.conf No need to change the current bbswitch status === However, the generated xorg.conf file is clearly invalid: =xorg.conf= Section "ServerLayout" Identifier "layout" Screen 0 "nvidia" Inactive "intel" EndSection Section "Device" Identifier "intel" Driver "intel" BusID "PCI:0@0:2:0" Option "AccelMethod" "SNA" EndSection Section "Screen" Identifier "intel" Device "intel" EndSection === So Xorg is right to report the error that screen "nvidia" is undefined. Apparently the xorg.conf file that gpu-manager generated is incorrect, and this issue prevents me from booting my system correctly, and this makes me believe this bug may be considered significant. ** Affects: ubuntu-drivers-common (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1485236 Title: gpu-manager generates an invalid xorg.conf file To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/ubuntu-drivers-common/+bug/1485236/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1485236] Re: gpu-manager generates an invalid xorg.conf file
Thanks for your reply. Indeed, this might have been my fault, apparently this happened when my nvidia driver was broken. Now that I fixed the driver it seems the issue is resolved, but I will test it further and reopen this bug if I am able to reproduce the problem. ** Changed in: ubuntu-drivers-common (Ubuntu) Status: New => Invalid -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1485236 Title: gpu-manager generates an invalid xorg.conf file To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/ubuntu-drivers-common/+bug/1485236/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 822224] Re: Messaging menu icon should indicate when someone is typing a message to me (but didn't send it yet))
Hey mpt, thanks for this explanation. I really appreciate the fact that you got to review my old idea, even though 4 years have passed since I reported it! And I honestly mean it. Keep up the good work! :-) -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/84 Title: Messaging menu icon should indicate when someone is typing a message to me (but didn't send it yet)) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/indicator-messages/+bug/84/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1467131] Re: systmd-tmpfiles-setup sometimes not run on boot
Hello Martin, here are the requested outputs: systemctl status -l systemd-tmpfiles-setup.service http://paste.ubuntu.com/11795241/ journalctl -b http://paste.ubuntu.com/11795245/ This log does not include network-manager complaining about the missing directory (because it was not selected to start in this boot - recovery mode), but a manual check confirmed that the directory /run/sendsigs.omit.d was indeed missing. Apparently, the tmpfiles service was run, but it chose to not create the needed files. Clearly, the "Entry does not match any include prefix, skipping" messages seem interesting. ** Changed in: systemd (Ubuntu) Status: Incomplete => New -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1467131 Title: systmd-tmpfiles-setup sometimes not run on boot To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1467131/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1467131] Re: systmd-tmpfiles-setup sometimes not run on boot
Here are the requested logs: Normal boot: journal http://paste.ubuntu.com/11801096/ jobs.txt http://paste.ubuntu.com/11801103/ failed.txt http://paste.ubuntu.com/11801107/ During a normal boot, I observe no issues. The directory is created as it should, and network-manager starts successfully. You noticed that the logs I sent previously (from recovery mode) claim that systemd-tpmfiles is not started, because it waits for local-fs, which makes perfect sense, as [usually] filesystems are not mounted in recovery mode. However, my original problem was that I was not able to start network-manager in recovery mode. When enabling networking from the recovery menu, file systems get mounted, so systemd-tmpfiles should start afterwards. The logs I have attached to my previous comment are from a boot into recovery mode *without* networking, which is why fs are not mounted. I have repeated the procedure when booting into recovery mode *with* networking enabled from the recovery menu (in such case the /run/sendsigs.omit.d directory is still missing, even though filesystems should be mounted) - below I attach logs from such boot. Recovery mode with networking enabled: systemctl status -l systemd-tmpfiles-setup.service http://paste.ubuntu.com/11801094/ journalctl -b http://paste.ubuntu.com/11801088/ I hope this makes a bit more sense now. ** Changed in: systemd (Ubuntu) Status: Incomplete => New -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1467131 Title: systmd-tmpfiles-setup sometimes not run on boot To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1467131/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1467131] [NEW] Directory /run/sendsigs.omit.d is somestimes not created on boot
Public bug reported: This is happening on an up-to-date 15.04,with systemd=219-7ubuntu6. Ocasionally, when booting up the system, network-manager service fails to start, reporting in logs that it is missing /run/sendsigs.omit.d directory. That file is indeed missing, although it is listed in /usr/lib/tmpiles.d/debian.conf The issue is reproducible when starting the system in recovery mode; in normal mode it happens occasionally (about 50%). Output of "journalctl -b": http://paste.ubuntu.com/11745993/ Contents of /usr/lib/tempfiles.d/debian.conf: http://paste.ubuntu.com/11746045/ Running "systemd-tmpfiles --create" after such unsuccesfull boot creates the missing directory (and some other too). The problem is similar to #1431110, but that bug was found to be a duplicate of another problem that is now fixed. Even with that fix, I am experiencing a correlated issue. I considered commenting on that bug, but marking it as non-incomplete (so that it would gain any attention) would require unlinking the duplicate, which wouldn't be right. ** Affects: systemd (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1467131 Title: Directory /run/sendsigs.omit.d is somestimes not created on boot To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1467131/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1337357] [NEW] gpu-manager searches for a wrong string when checking if nvidia was unloaded
Public bug reported: I am using Ubuntu 14.04 with an Intel 4000HD and Nvidia GTX 770. I have noticed that my gpu-manager claims that: Was nvidia unloaded? yes even though the nvidia module is loaded and was never unloaded (and lsmod displays it). Quick investigation showed that gpu-manager checks whether that module was unloaded by running: dmesg | grep -q "nvidia: module" I assume that the intention was to detect any "nvidia: module unloaded" or similar messages. However, my dmesg contains several other messages that match this pattern: nvidia: module license 'NVIDIA' taints kernel. nvidia: module verification failed: signature and/or required key missing - tainting kernel These messages are not realated to unloading the module, it sucessfully keeps running afterwards. Therefore I believe the pattern used by gpu-manager is incorrect. Possible solution is to correct that search string. The only message that appears in my dmesg when I unload nvidia module is: [drm] Module unloaded The dmesg output never explicitly names `nvidia` when it is unloaded. Another possible solution would be to grep lsmod instead of dmesg, to check if the driver is currently loaded. ** Affects: ubuntu-drivers-common (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1337357 Title: gpu-manager searches for a wrong string when checking if nvidia was unloaded To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/ubuntu-drivers-common/+bug/1337357/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 534662] Re: [RV635] No hardware acceleration on ATI Radeon 3650 HD using 'radeon' driver
Right at this moment, using 13.10, I can no longer observe this bug. I am using the `radeon` driver on exactly the same hardware, and apparently things work quite well. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/534662 Title: [RV635] No hardware acceleration on ATI Radeon 3650 HD using 'radeon' driver To manage notifications about this bug go to: https://bugs.launchpad.net/xserver-xorg-driver-ati/+bug/534662/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1048335] Re: integrate in message-indicator
I can confirm this bug persists in Ubuntu 13.04. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1048335 Title: integrate in message-indicator To manage notifications about this bug go to: https://bugs.launchpad.net/quantal-backports/+bug/1048335/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1846445] Re: 19.10 gnome tweaks flashing and unusable
I am affected too. While the window flashes, the console prints out a lot of: gtk_widget_size_allocate(): attempt to allocate widget with width -5 and height 15 about once per flash. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1846445 Title: 19.10 gnome tweaks flashing and unusable To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/zulucrypt/+bug/1846445/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
