Bug#1051681: Hangs trying to boot from /boot on LVM+LUKS
On 2024-03-08 11:44, Michel Dänzer wrote: > > My working theory is that it's due to some kernel build configuration change > in my self-built kernels compared to Debian ones. My second guess was a winner: CONFIG_EFI_DISABLE_PCI_DMA breaks booting with GRUB 2.12 on this machine. It works fine on two other (desktop) machines though, so the UEFI firmware seems to be a factor. OTOH it worked with GRUB 2.06 on this machine as well, so something changed in GRUB. Don't know if it's a bug though. -- Earthling Michel Dänzer| https://redhat.com Libre software enthusiast | Mesa and Xwayland developer
Bug#1051681: Hangs trying to boot from /boot on LVM+LUKS
Hi Mate, thanks for your follow-up. On 2024-02-19 08:31, Mate Kukri wrote: > > There are a rather high number of variables to isolate here. If you > could provide the following information, it might help provide a > better guess at what's going on: > - Computer (or mainboard if white box desktop) model It's a Lenovo Thinkpad E595. > - Firmware revision I upgraded to the latest 1.29, no change regarding this issue. > - Is Secure Boot enabled? It's disabled. > - Description of your disk layout It's a 512GB NVMe SSD. There are two partitions: 1. The EFI system partition (289MB) 2. A LUKS encrypted volume (rest) The LUKS volume contains an LVM2 PV, with LVs for the root filesystem (which includes /boot) and swap. > Also if you could just try using the grub 2.12-1 binary to boot a > kernel+initrd from an ext4 volume directly (e.g. using a usb drive or > spare disk), that would also be very helpful, I wonder if this > regression has something to do with LVM. Before this I tried booting a Debian kernel image instead of a self-built one, and that booted fine. That seems to rule out an LVM or LUKS related issue. Should have tried this earlier. :( My working theory is that it's due to some kernel build configuration change in my self-built kernels compared to Debian ones. I'll try narrowing it down, though if you happen to know of any kernel build configuration no longer supported with GRUB 2.12, that might be helpful. -- Earthling Michel Dänzer| https://redhat.com Libre software enthusiast | Mesa and Xwayland developer
Bug#1051681: Hangs trying to boot from /boot on LVM+LUKS
On 2023-09-11 11:28, Michel Dänzer wrote: > Package: grub-efi > Version: 2.12~rc1-9 > Severity: important > > > After upgrading to 2.12~rc1, any boot entry hangs after 'Loading initial > ramdisk ...'. I'll attach a photo showing the debug=all output when it hangs. > > Downgrading to 2.06-13 avoids the issue. Still the same issue with 2.12-1. Is there any more information I can provide to help solve this? For the time being I can keep the system booting with 2.06-14, I suspect that won't be a reasonable option forever though. -- Earthling Michel Dänzer| https://redhat.com Libre software enthusiast | Mesa and Xwayland developer
Bug#1051993: gdm3: System suspends after 15(!) minutes at login screen
Package: gdm3 Version: 45~beta-1 Severity: normal Dear Maintainer, After upgrading to 45~beta-1, the system suspends after 15 minutes at the login screen. This did not happen with older versions up to and including 44.1-2. This is a desktop machine which is always connected to AC. Setting both sleep-inactive-ac-timeout & sleep-inactive-battery-timeout (which default to 20 minutes though, not 15) to 0, and both sleep-inactive-ac-type & sleep-inactive-battery-type to 'nothing' in /etc/gdm3/greeter.dconf-defaults doesn't help. -- System Information: Debian Release: trixie/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'stable-security'), (500, 'buildd-unstable'), (500, 'unstable'), (102, 'experimental'), (1, 'experimental-debug') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.5.3+ (SMP w/16 CPU threads; PREEMPT) Kernel taint flags: TAINT_UNSIGNED_MODULE Locale: LANG=de_CH.UTF-8, LC_CTYPE=de_CH.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages gdm3 depends on: ii accountsservice 23.13.9-4 ii adduser 3.137 ii alacritty [x-terminal-emulator] 0.12.2-2 ii dbus [default-dbus-system-bus]1.14.10-1 ii dbus-bin 1.14.10-1 ii dbus-daemon 1.14.10-1 ii dconf-cli 0.40.0-4 ii dconf-gsettings-backend 0.40.0-4 ii debconf [debconf-2.0] 1.5.82 ii gir1.2-gdm-1.045~beta-1 ii gnome-console [x-terminal-emulator] 45~beta-2 ii gnome-session [x-session-manager] 44.0-4 ii gnome-session-bin 44.0-4 ii gnome-session-common 44.0-4 ii gnome-settings-daemon 45~rc-1 ii gnome-shell 44.4-1 ii gsettings-desktop-schemas 45~rc-1 ii kitty [x-terminal-emulator] 0.26.5-5 ii kwin-x11 [x-window-manager] 4:5.27.8-1 ii libaccountsservice0 23.13.9-4 ii libaudit1 1:3.1.1-1 ii libc6 2.37-9 ii libcanberra-gtk3-00.30-10 ii libcanberra0 0.30-10 ii libgdk-pixbuf-2.0-0 2.42.10+dfsg-1+b1 ii libgdm1 45~beta-1 ii libglib2.0-0 2.78.0-1 ii libglib2.0-bin2.78.0-1 ii libgtk-3-03.24.38-5 ii libgudev-1.0-0238-2 ii libkeyutils1 1.6.3-2 ii libpam-modules1.5.2-7 ii libpam-runtime1.5.2-7 ii libpam-systemd [logind] 254.1-3 ii libpam0g 1.5.2-7 ii librsvg2-common 2.54.7+dfsg-2 ii libselinux1 3.5-1 ii libsystemd0 254.1-3 ii libx11-6 2:1.8.6-1 ii libxau6 1:1.0.9-1 ii libxcb1 1.15-1 ii libxdmcp6 1:1.1.2-3 ii mutter [x-window-manager] 44.4-3 ii plasma-workspace [x-session-manager] 4:5.27.8-1 ii polkitd 123-1 ii procps2:4.0.3-1 ii systemd-sysv 254.1-3 ii ucf 3.0043+nmu1 ii x11-common1:7.7+23 ii x11-xserver-utils 7.7+9+b1 ii xfce4-session [x-session-manager] 4.18.3-1 ii xfce4-terminal [x-terminal-emulator] 1.1.0-1 ii xfwm4 [x-window-manager] 4.18.0-1 ii xterm [x-terminal-emulator] 384-1 Versions of packages gdm3 recommends: ii at-spi2-core 2.49.91-2 ii desktop-base 12.0.6+nmu1 ii gnome-session [x-session-manager] 44.0-4 ii plasma-workspace [x-session-manager] 4:5.27.8-1 ii x11-xkb-utils 7.7+7 ii xfce4-session [x-session-manager] 4.18.3-1 ii xserver-xephyr2:21.1.8-1 ii xserver-xorg 1:7.7+23 ii zenity3.44.2-1 Versions of packages gdm3 suggests: pn libpam-fprintd ii libpam-gnome-keyring 42.1-1+b2 pn libpam-pkcs11 pn libpam-sss pn orca -- debconf information: gdm3/daemon_name: /usr/sbin/gdm3 * shared/default-x-display-manager: gdm3
Bug#1051681: Hangs trying to boot from /boot on LVM+LUKS
On 9/11/23 11:28, Michel Dänzer wrote: > > After upgrading to 2.12~rc1, any boot entry hangs after 'Loading initial > ramdisk ...'. I'll attach a photo showing the debug=all output when it hangs. > > Downgrading to 2.06-13 avoids the issue. 2.06-14 works fine as well. -- Earthling Michel Dänzer| https://redhat.com Libre software enthusiast | Mesa and Xwayland developer
Bug#1040056: spirv-tools breaks spirv-llvm-translator-15 autopkgtest: exactly one input file must be specified.
On 7/10/23 10:36, Sebastien Bacher wrote: > The issue needs to be fixed in piglit and there is a patch upstream, I've > reported that as https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1039592 The spirv-llvm-translator build doesn't use piglit though, does it? > https://gitlab.freedesktop.org/mesa/piglit/-/merge_requests/821 However, 'spirv-as -h' still says: 'If no file is specified, [...] then the assembly text is read from standard input.' So this does seem like a spirv-tools bug, and my piglit change is a workaround. -- Earthling Michel Dänzer| https://redhat.com Libre software enthusiast | Mesa and Xwayland developer
Bug#985769: xwayland: 100% of CPU, The system gets stuck.
On 6/22/23 12:47, Alberto Garcia wrote: > On Tue, Mar 23, 2021 at 03:57:41PM +0800, john wrote: > >> The xwayland cpu utilization rate reaches 100%, which often happens. > > I have actually had this problem a few times since I upgraded from > bullseye to bookworm. The UI becomes unresponsive and the only > alternative is to ssh into the machine and kill Xwayland. > > I don't think I ever had this problem in bullseye. I think this tends > to happen when I am using Steam (and I don't mean playing a game but > simply browsing the store or the library). Could be https://gitlab.freedesktop.org/xorg/xserver/-/issues/1442 fixed by https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1086 . -- Earthling Michel Dänzer| https://redhat.com Libre software enthusiast | Mesa and Xwayland developer
Bug#1033230: webkit2gtk: version 2.39.90-1 lost its libgles2 runtime dependency
On 3/21/23 17:27, Alberto Garcia wrote: > On Mon, Mar 20, 2023 at 01:29:51PM +0100, Gianfranco Costamagna wrote: > >> Hello, for some reasons, now webkit2gtk is not linking anymore >> libGLESv2.so.2 causing surf to fail autopkgtests on arm64 and armhf > > Hmmm... the reason is that this is now handled via libepoxy, which > opens libGLESv2.so.2 on runtime using dlopen(). > > I think that I'll add the dependencies manually for now, but I wonder > if libepoxy should depend on those libraries instead? My understanding is that libepoxy requires its user to set up the EGL/GLX context, and the latter should not rely on libepoxy pulling in the corresponding libraries. -- Earthling Michel Dänzer| https://redhat.com Libre software enthusiast | Mesa and Xwayland developer
Bug#1016741: Not quite fixed yet
reopen 1016741
kthxbye
Thanks for attempting to fix this bug!
However, it's not quite fixed yet, because
/usr/lib/dracut/modules.d/35network-manager/nm-lib.sh checks the wrong path.
This fixes it:
--- /usr/lib/dracut/modules.d/35network-manager/nm-lib.sh.dpkg-dist
2022-11-20 08:56:26.0 +0100
+++ /usr/lib/dracut/modules.d/35network-manager/nm-lib.sh 2022-12-10
10:56:08.785448157 +0100
@@ -10,7 +10,7 @@ nm_generate_connections() {
elif [ -x /usr/lib/nm-initrd-generator ]; then
# shellcheck disable=SC2046
/usr/lib/nm-initrd-generator -- $(getcmdline)
-elif [ -x /usr/lib/nm-initrd-generator ]; then
+elif [ -x /usr/lib/NetworkManager/nm-initrd-generator ]; then
# shellcheck disable=SC2046
/usr/lib/NetworkManager/nm-initrd-generator -- $(getcmdline)
else
BTW, in the meantime I also noticed that
/usr/lib/dracut/modules.d/40network/module-setup.sh doesn't check the proper
nm-initrd-generator path either. This fixes it:
--- /usr/lib/dracut/modules.d/40network/module-setup.sh.dpkg-dist
2022-11-15 17:49:58.0 +0100
+++ /usr/lib/dracut/modules.d/40network/module-setup.sh 2022-12-10
11:35:04.612714382 +0100
@@ -21,7 +21,7 @@ depends() {
network_handler="network-wicked"
elif [[ -e $dracutsysrootdir$systemdsystemunitdir/connman.service ]];
then
network_handler="connman"
-elif [[ -x $dracutsysrootdir/usr/libexec/nm-initrd-generator ]] || [[
-x $dracutsysrootdir/usr/lib/nm-initrd-generator ]]; then
+elif [[ -x $dracutsysrootdir/usr/libexec/nm-initrd-generator ]] || [[
-x $dracutsysrootdir/usr/lib/nm-initrd-generator ]] || [[ -x
$dracutsysrootdir/usr/lib/NetworkManager/nm-initrd-generator ]]; then
network_handler="network-manager"
elif [[ -x $dracutsysrootdir$systemdutildir/systemd-networkd ]]; then
network_handler="systemd-networkd"
With this, I no longer need to explicitly add the network-manager module in a
/etc/dracut.conf.d/*.conf file.
--
Earthling Michel Dänzer| https://redhat.com
Libre software enthusiast | Mesa and Xwayland developer
Bug#1016741: Wrong paths to nm-initrd-generator
Package: dracut-network Version: 056-3 Severity: normal -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 /usr/lib/dracut/modules.d/35network-manager/module-setup.sh and /usr/lib/dracut/modules.d/35network-manager/nm-lib.sh look for nm-initrd-generator in /usr/libexec and /usr/lib. However, network-manager actually ships it in /usr/lib/NetworkManager/. This prevents the network-manager module from working in the initrd. - -- System Information: Debian Release: bookworm/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'stable-security'), (500, 'buildd-unstable'), (500, 'unstable'), (102, 'experimental-debug'), (102, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.19.0+ (SMP w/8 CPU threads; PREEMPT) Kernel taint flags: TAINT_WARN, TAINT_UNSIGNED_MODULE Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8), LANGUAGE=en_CA:en Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages dracut-network depends on: pn dracut-core ii iputils-arping 3:20211215-1 ii isc-dhcp-client 4.4.3-2 Versions of packages dracut-network recommends: ii curl7.84.0-2 pn nbd-client pn nfs-common pn open-iscsi dracut-network suggests no packages. -BEGIN PGP SIGNATURE- iHEEARECADEWIQSwn681vpFFIZgJURRaga+OatuyAAUCYu5tbhMcbWljaGVsQGRh ZW56ZXIubmV0AAoJEFqBr45q27IA8YQAnRTdZ0xH9LqUxjWrucgjVyoCCopQAJ9e RmC2sgy9r9egd531hAZwopf0FA== =lxbV -END PGP SIGNATURE-
Bug#998298: mesa-vulkan-drivers overrides nvidia driver
On 2021-11-02 00:25, Andrzej Zięba wrote: > Package: mesa-vulkan-drivers > Version: 21.2.4-1 > Severity: important > X-Debbugs-Cc: a-zi...@go2.pl > > Dear Maintainer, > Upgrade of mesa-vulkan-drivers overrides the Nvidia Vulcan driver. > > * What led up to the situation? > I have upgraded the package and noticed that Warthuner stopped working due to > reported freeze. > > * What exactly did you do (or not do) that was effective (or ineffective)? > WT uses Vulkan so I figured out that this package is probably to blame and > indeed downgrading it was fixing the problem. Can you provide the output of vulkaninfo (without setting VK_ICD_FILENAMES) for both cases? > To circumvent the problem with the mesa-vulkan-drivers upgraded I had to set > VK_ICD_FILENAMES=/usr/share/vulkan/icd.d/nvidia_icd.json > in my Xession init scripts to force Nvidia Vulkan driver. It's rather doubtful that there's a bug here. Without setting VK_ICD_FILENAMES, there's no well-defined order in which Vulkan devices are enumerated. Most Vulkan applications just use the first enumerated device, so if the enumeration order changes, they'll end up using a different one. -- Earthling Michel Dänzer| https://redhat.com Libre software enthusiast | Mesa and Xwayland developer
Bug#995869: New upstream releases available
Package: stgit Version: 0.19-1 Severity: wishlist Tags: upstream -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 See https://github.com/stacked-git/stgit . Current upstream release as of this writing is 1.3. - -- System Information: Debian Release: bookworm/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'testing-security'), (500, 'stable-security'), (500, 'buildd-unstable'), (500, 'unstable'), (102, 'experimental-debug'), (102, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.14.9+ (SMP w/8 CPU threads; PREEMPT) Kernel taint flags: TAINT_UNSIGNED_MODULE Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8), LANGUAGE=en_CA:en Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages stgit depends on: ii git 1:2.33.0-1 ii python3 3.9.2-3 stgit recommends no packages. stgit suggests no packages. - -- no debconf information -BEGIN PGP SIGNATURE- iHEEARECADEWIQSwn681vpFFIZgJURRaga+OatuyAAUCYV7O7hMcbWljaGVsQGRh ZW56ZXIubmV0AAoJEFqBr45q27IAOaYAnA7+wVOig/VdhHLWswn2AP0YSVYTAKCt 5Hj4uaN5AfrvTKTlGifXu5KOyQ== =kLQb -END PGP SIGNATURE-
Bug#990994: llvm-12-tools cannot be installed for a foreign architecture
On 2021-09-18 14:41, Helmut Grohne wrote: > > So the real goal is cross building using clang I guess. Please correct > me if that's wrong. My main motivation for this bug report is only installing llvm-*-dev for foreign architectures, for cross building Mesa (in its upstream CI). That said, cross building using clang might be useful for Mesa's CI in the future as well. > I can immediately identify two problems with foreign installation of > llvm-V-dev. That's certainly not exhaustive, but each of them is a > show-stopper. It's the dependencies on llvm-V-tools and on llvm-V. The > former was already evident from the bug report. The latter is an issue, > because a foreign llvm-V-dev will pull a foreign llvm-V, which contains > all the /usr/bin/llvm-*-V tools for a foreign architecture and we'll be > unable to run them. So it might become installable, but in a useless > way. Not always useless. In particular, consider cases like installing llvm-*-dev:i386 on an amd64 host. In Mesa's CI, it even works with ppc64el & s390x packages on amd64 hosts, by transparently running foreign binaries via qemu-user-static. > Given the length of this mail, I guess nobody makes it to the end. I can > write arbitrary nonsense here and nobody will notice. Nice try. :) -- Earthling Michel Dänzer| https://redhat.com Libre software enthusiast | Mesa and Xwayland developer
Bug#992617: xserver-xorg-video-radeon: Screen rotate doesn't work
On 2021-08-21 4:58 p.m., Kari Pahula wrote: > On Sat, Aug 21, 2021 at 12:17:02PM +0200, Michel Dänzer wrote: >>> DRM Information from dmesg: >>> --- >>> >>> >> >> Since there are no DRM driver related messages in dmesg, looks like >> something is preventing the radeon kernel driver from loading at >> all. If you're passing nomodeset on the kernel command line, remove >> that. Otherwise, full dmesg output would be needed to diagnose. > > I'm not using nomodeset. I've attached a dump from dmesg after a > reboot. That "ring 0 stalled" message doesn't look promising at all. Yeah, that's a GPU hang. > Actually, when I first tried running startx it just stopped after > showing the initial log messages to tty, while occasionally blinking > my screens black. I did a kill -9 on the Xorg process and then startx > worked when I tried it again, but I guess it gave up on any > acceleration at that point. Indeed. > I tried booting the last kernel I had (linux-image-5.10.0-4) and the > one from Buster but those didn't solve anything. What else changed on the system since it was last working? E.g. if Mesa packages were upgraded, it's worth trying to downgrade those. Or maybe xserver-xorg-video-radeon. -- Earthling Michel Dänzer | https://redhat.com Libre software enthusiast | Mesa and X developer
Bug#992617: xserver-xorg-video-radeon: Screen rotate doesn't work
On 2021-08-21 11:01 a.m., Kari Pahula wrote: > Package: xserver-xorg-video-radeon > Version: 1:19.1.0-2 > Severity: normal > > $ xrandr --output DVI-0 --rotate left > xrandr: output DVI-0 cannot use rotation "left" reflection "none" > $ xrandr -o left > X Error of failed request: BadMatch (invalid parameter attributes) > Major opcode of failed request: 140 (RANDR) > Minor opcode of failed request: 2 (RRSetScreenConfig) > Serial number of failed request: 14 > Current serial number in output stream: 14 [...] > [ 33984.302] (II) RADEON(0): GPU accel disabled or not working, using > shadowfb for KMS This is why. Rotation requires working HW acceleration. > DRM Information from dmesg: > --- > > Since there are no DRM driver related messages in dmesg, looks like something is preventing the radeon kernel driver from loading at all. If you're passing nomodeset on the kernel command line, remove that. Otherwise, full dmesg output would be needed to diagnose. -- Earthling Michel Dänzer | https://redhat.com Libre software enthusiast | Mesa and X developer
Bug#992551: Fixed upstream in 20210818
By reverting the following files to the versions from 20210315: amdgpu/picasso_sdma.bin amdgpu/raven_sdma.bin amdgpu/raven2_sdma.bin -- Earthling Michel Dänzer | https://redhat.com Libre software enthusiast | Mesa and X developer
Bug#990994: llvm-12-tools cannot be installed for a foreign architecture
Package: llvm-12-tools Version: 1:12.0.1~+rc4-1 Severity: normal -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 llvm-12-tools requires python3 packages from the same architecture. This prevents installing llvm-12-tools (and by extension llvm-12-dev) for a foreign architecture. E.g. trying to install llvm-12-tools:i386 with aptitude gives: llvm-12-tools:i386 : Depends: python3:i386 but it is not going to be installed Depends: python3-yaml:i386 but it is not going to be installed See https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9833/diffs?commit_id=af0fde955c518447ccd92134517b4e69308e10b2#3f46a9fa9651371b76f0894b75d719a4c5659642_44_45 for how I had to work around this in Mesa's upstream CI. (In buster it was still possible to install llvm-*-dev packages for foreign architectures) - -- System Information: Debian Release: 11.0 APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'testing-security'), (500, 'buildd-unstable'), (500, 'unstable'), (500, 'stable'), (102, 'experimental-debug'), (102, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.13.1+ (SMP w/8 CPU threads; PREEMPT) Kernel taint flags: TAINT_UNSIGNED_MODULE Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8), LANGUAGE=en_CA:en Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages llvm-12-tools depends on: ii libc6 2.31-13 ii libgcc-s1 10.2.1-6 ii libllvm12 1:12.0.1~+rc4-1 ii libstdc++610.2.1-6 ii libtinfo6 6.2+20201114-2 ii libz3-4 4.8.10-1 ii python3 3.9.2-3 ii python3-pygments 2.7.1+dfsg-2.1 ii python3-yaml 5.3.1-5 ii zlib1g1:1.2.11.dfsg-2 llvm-12-tools recommends no packages. llvm-12-tools suggests no packages. - -- no debconf information -BEGIN PGP SIGNATURE- iHEEARECADEWIQSwn681vpFFIZgJURRaga+OatuyAAUCYOxDRhMcbWljaGVsQGRh ZW56ZXIubmV0AAoJEFqBr45q27IAGFAAoIUdPNt92u+hcU+aFc4pFwSKnuy5AJ9G I2VP7ODKfQnk4YVZAXsjgqInBA== =fC9k -END PGP SIGNATURE-
Bug#985769: xwayland: 100% of CPU, The system gets stuck.
On 2021-03-23 8:57 a.m., john wrote: > Package: xwayland > Version: 2:1.20.10-3 > Severity: important > X-Debbugs-Cc: guoke.z...@gmail.com > > Dear Maintainer, > > The xwayland cpu utilization rate reaches 100%, which often happens.One of the > reproduction process is as follows: Is this using GNOME, or a different Wayland environment? > 1. System boot, open terminal window. Which terminal emulator application? > 2. Drag the window so that the mouse pointer touches the right edge of the > screen, >The xwayland cpu usage rate will reach 100% (Especially when the system is > just started): > > 进程号 USER PR NIVIRTRESSHR%CPU %MEM TIME+ COMMAND >1413 john 20 0 1071740 59244 39136 R 100.0 1.5 0:06.20 > Xwayland > > At this point, the mouse is still available, and the terminal is also > available. So the terminal window's contents are still updating at this point? Is the window still at the original size? > 3. Ctrl+D exit the terminal program and the GUI will be completely stuck and > unusable, but ssh still works. > > In addition, many other operations may also cause this problem. I'd be interested in more examples, I've been unable to reproduce this so far. -- Earthling Michel Dänzer | https://redhat.com Libre software enthusiast | Mesa and X developer
Bug#982083: dracut: Should not automatically update initramfs for all installed kernels on upgrade
Package: dracut Version: 051-1 Severity: normal Dear Maintainer, when the dracut package is upgraded, its postinst script currently automatically updates initramfs for all installed kernel versions. If there's an issue in the newly generated initramfs, this can result in all installed kernel versions becoming unbootable. For comparison, initramfs-tools automatically updates only the initramfs for the newest kernel version installed. This should leave older versions bootable as before the upgrade. -- System Information: Debian Release: bullseye/sid APT prefers testing-debug APT policy: (500, 'testing-debug'), (500, 'testing'), (500, 'stable'), (103, 'unstable-debug'), (103, 'unstable'), (102, 'experimental-debug'), (102, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.10+ (SMP w/12 CPU threads; PREEMPT) Kernel taint flags: TAINT_UNSIGNED_MODULE Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8), LANGUAGE=en_CA:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages dracut depends on: ii dracut-core 051-1 dracut recommends no packages. Versions of packages dracut suggests: ii dracut-network 051-1 -- no debconf information
Bug#980148: mesa-vulkan-drivers: file content conflict in Multi-Arch:same package
On 2021-01-15 12:02 p.m., Thorsten Glaser wrote:
Package: mesa-vulkan-drivers
Version: 20.3.2-1
Severity: important
X-Debbugs-Cc: t...@mirbsd.de
Package: mesa-vulkan-drivers
[…]
Multi-Arch: same
The file /usr/share/vulkan/icd.d/intel_icd.x86_64.json differs.
amd64:
{
"ICD": {
"api_version": "1.2.145",
"library_path": "/usr/lib/x86_64-linux-gnu/libvulkan_intel.so"
},
"file_format_version": "1.0.0"
}
x32:
{
"ICD": {
"api_version": "1.2.145",
"library_path": "/usr/lib/x86_64-linux-gnux32/libvulkan_intel.so"
},
"file_format_version": "1.0.0"
}
This file must be moved out of /usr/share and into a multiarch library
path.
Looks to me like the filename is wrong on x32.
--
Earthling Michel Dänzer | https://redhat.com
Libre software enthusiast | Mesa and X developer
Bug#979711: clevis-systemd: /usr/libexec/clevis-luks-askpass lacks execute permissions
Package: clevis-systemd Version: 15-4 Severity: important The clevis-luks-askpass script is shipped without execute permissions: -rw-r--r-- root/root 2343 2021-01-04 22:50 ./usr/libexec/clevis-luks-askpass This breaks the clevis-luks-askpass.service systemd unit, and by extension automatic unlocking of an encrypted root filesystem in the initrd: Jan 10 14:53:56 simula systemd[677]: clevis-luks-askpass.service: Failed to locate executable /usr/libexec/clevis-luks-askpass: Permission denied Jan 10 14:53:56 simula systemd[677]: clevis-luks-askpass.service: Failed at step EXEC spawning /usr/libexec/clevis-luks-askpass: Permission denied Jan 10 14:53:56 simula systemd[1]: clevis-luks-askpass.service: Main process exited, code=exited, status=203/EXEC Jan 10 14:53:56 simula systemd[1]: clevis-luks-askpass.service: Failed with result 'exit-code'. After manually running sudo chmod +x /usr/libexec/clevis-luks-askpass it's working. -- System Information: Debian Release: bullseye/sid APT prefers testing-debug APT policy: (500, 'testing-debug'), (500, 'testing'), (500, 'stable'), (103, 'unstable-debug'), (103, 'unstable'), (102, 'experimental-debug'), (102, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.5+ (SMP w/12 CPU threads; PREEMPT) Kernel taint flags: TAINT_UNSIGNED_MODULE Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8), LANGUAGE=en_CA:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages clevis-systemd depends on: ii clevis-luks 15-4 ii systemd 247.2-4 clevis-systemd recommends no packages. clevis-systemd suggests no packages. -- no debconf information
Bug#971675: x11-xserver-utils: xhost don't work anymore in Gnome+wayland
On 2020-10-04 10:32 p.m., Davide Prina wrote: Package: x11-xserver-utils Version: 7.7+8 Severity: normal Dear Maintainer, I used to do the following: $ xhost +si:localuser:$USER $ su - $USER and then run some GUI programs. From today I get the following error: Unable to init server: Could not connect: Connection refused Error: cannot open display: :0 AFAICT it's due to libmutter-7-0, specifically https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1424 I suspect. Presumably it previously worked using the abstract socket, but now there's only /tmp/.X11-unix/X0, which is only writable by the user running the session. I suggest filing an issue upstream at https://gitlab.gnome.org/GNOME/mutter/-/issues . -- Earthling Michel Dänzer | https://redhat.com Libre software enthusiast | Mesa and X developer
Bug#971088: xserver-xorg-core: Backtraces print wrong instruction pointers
On 2020-09-27 6:37 p.m., Bernhard Übelacker wrote: Package: xserver-xorg-core Version: 2:1.20.8-2 Severity: wishlist Dear Maintainer, in the past I was trying to make sense of some backtraces written by Xorg, but failed, e.g. in #969739. I did now some debugging and found that in function xorg_backtrace the function begin retrieved by unw_get_proc_info in "pip.start_ip" cannot always be used for calculations with "off". This is because this "off" offset is calculated in unw_get_proc_name from the nearest symbol, which does not necessarily match pip.start_ip. Attached patch separately retrieves the instruction pointer by unw_get_reg and uses that value for the output. A short in gdb wrote with this patch applied the same addresses as the bt command. What do you think? Can you create an upstream merge request at https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests ? -- Earthling Michel Dänzer | https://redhat.com Libre software enthusiast | Mesa and X developer
Bug#969739: Segmentation fault on startup
On 2020-09-23 10:38 p.m., Bernhard Übelacker wrote: Dear Maintainer, I could not reproduce the crash, but I could modify the process under gdb to reach a point of execution, which prints a similar backtrace. Therefore I guess the crash described in Christophe's first message is really located in [1], caused by "xf86_platform_devices[i].pdev" containing a null pointer. [1] https://sources.debian.org/src/xorg-server/2:1.20.9-1/hw/xfree86/common/xf86platformBus.c/#L367 https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/508 should help then. -- Earthling Michel Dänzer | https://redhat.com Libre software enthusiast | Mesa and X developer
Bug#965099: XWayland: Won't startup session with my specific GNOME configuration
On 2020-07-16 7:34 a.m., Adrian Immanuel Kiess wrote: > Package: xwayland > Version: 2:1.20.8-2 > Severity: normal > > [...] > > I have a good one year old GNOME configuration for my own user account I am > using on this system. > > I can't login to XWayland using GNOME (on Wayland) using the GDM3 login > manager. After the password got accepted it loads services like tracker fine, > but then halts and also the mouse pointer gets to an hold. Unless there's specific evidence pointing to Xwayland, e.g. in the output of journalctl -b0 --user-unit=gnome-shell-wayland.service this is more likely an issue in a GNOME component, e.g. libmutter-6-0 or gnome-shell. -- Earthling Michel Dänzer | https://redhat.com Libre software enthusiast | Mesa and X developer
Bug#964453: please reenable libkms
On 2020-07-07 2:45 p.m., Dmitry Baryshkov wrote: > Source: libdrm > Version: 2.4.102-1 > Severity: normal > > libkms is usefull for other packages outside Debian (e.g. for VK-GL-CTS > test suite). Could you please reenable it (disabled in 2.4.46-3). AFAIK VK-GL-CTS never actually used libkms, it erroneously claims to require it. Upstream Mesa's GitLab CI pipeline uses this to modify the VK-GL-CTS source tree so it can be built without libkms: # surfaceless links against libkms and such despite not using it. sed -i '/gbm/d' targets/surfaceless/surfaceless.cmake sed -i '/libkms/d' targets/surfaceless/surfaceless.cmake sed -i '/libgbm/d' targets/surfaceless/surfaceless.cmake -- Earthling Michel Dänzer | https://redhat.com Libre software enthusiast | Mesa and X developer
Bug#962658: libwayland-cursor0: Cursor image left on screen after cursor moved on. Can only be removed by logging out.
On 2020-06-11 2:27 p.m., Alan Chandler wrote: > Package: libwayland-cursor0 > Version: 1.18.0-1 > Severity: normal > > Dear Maintainer, > > > I was editing some code in vscode, when, randomly, I though the cursor had > frozen. However I soon realised that it was elsewhere on the screen and what > I > was seeing was a frozen image of it. > > Despite closing vscode and switching to different workspaces on my (gnome) > desktop, the cursor remained in the same place on the screen. It seemed to > always be in the foreground - ie opening a new window over the top of where it > was would still show the cursor image, it was not displaced by the new pixels > from the overlaying window. > > In the end the only way I was able to get it to disappear was to log out and > then log back in. The frozen image was removed from the screen on logout. > > My computer is running a AMD graphics card (I think its a RX580) and I need to > load Linux Non Free Firmware to have a working system at all. I presume that > could be part of the issue. This has nothing to do with libwayland-cursor, it's between libmutter and the amdgpu kernel driver. Basically, due to unfortunate interaction between mutter and the amdgpu kernel driver, the former can stop using the HW cursor and start drawing the cursor in software instead. But in your case, the HW cursor remains visible, in front of everything else. I submitted https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1240 to prevent something like this from happening in mutter when transitioning from monitors disabled via DPMS to enabled. However, from your description I'm not sure this will help for you as well. The fact that the HW cursor stays on is most likely an amdgpu kernel driver issue and should be reported at https://gitlab.freedesktop.org/drm/amd/-/issues . -- Earthling Michel Dänzer | https://redhat.com Libre software enthusiast | Mesa and X developer
Bug#943664: Solution for PowerMac11,2
On 2020-04-30 9:40 p.m., Ralf P. wrote: > > Note: For me this triggers another bug: If I run my AMD Radeon > hardware accelerated the X11 internal font server shows garbled > (sometimes looking like reversed) characters. > Client side font rendering (Firefox, LibreOffice, Emacs, sakura) > works. > My Nvidia card is affected too. Until now I have no soultion for this. Sounds like https://gitlab.freedesktop.org/xorg/xserver/-/issues/1011 . -- Earthling Michel Dänzer | https://redhat.com Libre software enthusiast | Mesa and X developer
Bug#950890: xserver-xorg-core: X segfaults when displaying a big image with xzgv
On 2020-02-07 9:33 p.m., Frédéric Brière wrote: > Package: xserver-xorg-core > Version: 2:1.20.7-2 > Severity: important > > I can (reliably) get X to segfault when displaying a big image (say, > over 1x1) with xzgv. And since that viewer allows doubling the > scale of an image with a single keystroke, this can easily be triggered > with any image (which is how I accidentally ran into it in the first > place). > > Steps to reproduce: > > - View any image (the bigger the better) with xzgv > - Repeatedly press "d" until the server segfaults > > The error message is identical to #912325, although I am using the > radeon driver: > > [ 94509.215] (EE) glamor0: GL error: GL_OUT_OF_MEMORY in glBufferData > [ 94509.215] (EE) glamor0: GL error: GL_INVALID_OPERATION in > glReadPixels(out of bounds PBO access) > [ 94509.215] (EE) glamor0: GL error: GL_INVALID_OPERATION in > glMapBuffer(length = 0) > > This was encountered with 2:1.20.7-2, and confirmed to be still present > in -3. > > Full log and backtrace with symbols are attached. Can't see the backtrace, but the log excerpt above looks like the fixes from https://gitlab.freedesktop.org/xorg/xserver/merge_requests/135 might help, so I added them to https://gitlab.freedesktop.org/xorg/xserver/merge_requests/391 and they will hopefully be in the upcoming 1.20.8 release. -- Earthling Michel Dänzer | https://redhat.com Libre software enthusiast | Mesa and X developer
Bug#912325: glamor0: GL error: GL_OUT_OF_MEMORY in glBufferData, GL_INVALID_OPERATION, X server crashes
On 2020-01-24 2:45 p.m., Thorsten Glaser wrote: > Package: xserver-xorg-core > Version: 2:1.20.7-2 > Followup-For: Bug #912325 > Control: affects 912325 xserver-xorg-video-nouveau > Control: forcemerge 912325 943893 > Control: retitle 912325 xserver-xorg-core: SIGSEGV with glamor0: GL error: > GL_OUT_OF_MEMORY with xserver-xorg-video-nouveau > > This issue is still pertinent, although reportbug suggested #943893 > to me which points out that this might be due to nouveau, which is, > indeed, the driver in use on this particular system. > > What can I do, besides switch to the proprietary driver? Perhaps with > fbdev or modesetting? (That would probably lose me OpenGL performance?) You're probably using the modesetting driver already, since the Xorg nouveau driver doesn't support glamor. The fundamental problem is in the kernel and/or Mesa nouveau drivers. -- Earthling Michel Dänzer | https://redhat.com Libre software enthusiast | Mesa and X developer
Bug#947813: SIGSEGV resulting from mesa dri2_add_config dealing poorly with invalid attrib
On 2019-12-31 2:04 p.m., Martin von Gagern wrote: > My issue appears to be largely due to a version mismatch, and I have > been able to resolve this. > > I had tried to get a specific version from unstable to test a fix for > a different bug, but apparently I misunderstood how pinning works and > got updates to mesa packages from the unstable release even after the > version for which I intended this. Once I downgraded mesa packages to > testing version, I was able to start X again. > > I'll leave it to you whether you believe this kind of issue is worth > addressing at the distro level (perhaps via more strict version > dependencies?) or forwarding to the upstream maintainers I suspect the problem was due to libegl-mesa0 being a different version than libglapi-mesa. The ABI between libglapi and other Mesa libraries isn't stable upstream, so all dependencies on libglapi-mesa should probably be restricted to the same version. > (so that unexpected behavior from a module library gets detected in a nicer > fashion than by crashing the X server). xserver code can't protect itself against memory corruption like this. > $ dpkg -l '*mesa*' > Desired=Unknown/Install/Remove/Purge/Hold > | Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend > |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad) > ||/ NameVersion Architecture Description > +++-===---=> > ii libegl-mesa0:amd64 19.2.6-1 amd64free > implementation of the EGL API -- Mesa vendor library > [...] > ii libglapi-mesa:amd64 19.3.1-3 amd64 free > implementation of the GL API -- shared library -- Earthling Michel Dänzer | https://redhat.com Libre software enthusiast | Mesa and X developer
Bug#943664: xserver-xorg-video-radeon: Same behaviour on Thinkpad T41
On 2019-11-01 5:25 p.m., Petra R.-P. wrote: > > Section "Device" > Identifier "Configured Video Device" > Driver "modesetting" > EndSection [...] > [ 455.569] Require OpenGL version 2.1 or later. > [ 455.570] (EE) modeset(0): Failed to initialize glamor at ScreenInit() > time. > [ 455.570] (EE) > Fatal server error: > [ 455.570] (EE) AddScreen/ScreenInit failed for driver 0 On this machine, you need to add Option "AccelMethod" "none" to Section "Device". -- Earthling Michel Dänzer | https://redhat.com Libre software enthusiast | Mesa and X developer
Bug#943664: xserver-xorg-video-radeon: Same behaviour on Thinkpad T41
On 2019-10-31 8:36 p.m., Petra R.-P. wrote: > Am Do., 31. Okt. 2019, um 18:01 +0100 schrieb Michel Dänzer > : >> On 2019-10-30 2:15 p.m., Petra R.-P. wrote: > >> This happens when HW acceleration is disabled. If you can't or don't >> want to enable HW acceleration, > I can't because I don't know how to do this. >> I recommend using the Xorg modesetting >> driver for the time being, by either uninstalling >> xserver-xorg-video-radeon or explicitly setting the driver in >> /etc/X11/xorg.conf, see below. Without HW acceleration, the radeon >> driver doesn't really provide much if any benefit over modesetting. >> >> >> Section "Device" >> >> Identifier "whateveryoulike" >> >> Driver "modesetting" >> >> EndSection > > I tried both variants without success. > > Both resulted in something like > > Server terminated with error (1). > xinit: giving up > xinit: unable to connect to X server: Conncection refused > xinit: server error We'd again need to see the corresponding Xorg log file. -- Earthling Michel Dänzer | https://redhat.com Libre software enthusiast | Mesa and X developer
Bug#943664: xserver-xorg-video-radeon: Same behaviour on Thinkpad T41
On 2019-10-30 2:15 p.m., Petra R.-P. wrote: > Package: xserver-xorg-video-radeon > Version: 1:19.1.0-1 > Followup-For: Bug #943664 > > Dear Maintainer, > > I can confirm every detail of the original report, > except that this happens here on an old IBM Thinkpad T 41. This happens when HW acceleration is disabled. If you can't or don't want to enable HW acceleration, I recommend using the Xorg modesetting driver for the time being, by either uninstalling xserver-xorg-video-radeon or explicitly setting the driver in /etc/X11/xorg.conf, see below. Without HW acceleration, the radeon driver doesn't really provide much if any benefit over modesetting. Section "Device" Identifier "whateveryoulike" Driver "modesetting" EndSection -- Earthling Michel Dänzer | https://redhat.com Libre software enthusiast | Mesa and X developer
Bug#943893: glamor0: GL error: GL_OUT_OF_MEMORY in glTexSubImage
On 2019-10-31 3:11 p.m., Agustin Martin Domingo wrote: > Package: xserver-xorg-core > Version: 2:1.20.4-1 > Severity: important > > Dear Maintainer, > > X session crashes randomly, losing unsaved information. > > Xorg.0.log (attached below) shows that a segfault is aborting the server. > > Error starts with > > glamor0: GL error: GL_OUT_OF_MEMORY in glTexSubImage > > Browsing for that error I found > > [Bug 110500 - X-Server crashes - GL error: GL_OUT_OF_MEMORY in > glTexSubImage ] > https://bugs.freedesktop.org/show_bug.cgi?id=110500 > > with a similar backtrace. > > Very similar backtraces (but for /usr/bin/Xwayland instead of > /usr/lib/xorg/modules/libglamoregl.so) are reported in > > [Sometimes my Ubuntu Log me out and close all applications] > https://gitlab.freedesktop.org/xorg/xserver/issues/833. > > and > > [https://gitlab.freedesktop.org/xorg/xserver/issues/647] > https://gitlab.freedesktop.org/xorg/xserver/issues/647 > > This last one seems already fixed upstream, and there is a suggestion that > Xwayland 1.20.5 contains the fix. Since I see libglamoregl.so in my > backtrace I am setting xserver-xorg-core as affected package. Please > reassign if aprppriate. The root cause seems to be a memory leak in the nouveau drivers. While glamor can be made more robust against not being able to allocate/update OpenGL textures, at some point it won't be able to continue if no memory can be allocated, so it's better to address the leak. -- Earthling Michel Dänzer | https://redhat.com Libre software enthusiast | Mesa and X developer
Bug#942318: xserver-xorg-video-amdgpu: VGA output is not detected in Radeon R7 (Carrizo) only the HDMI works. Motherboard MSI A68HM-E33 v2
On 2019-10-14 4:00 p.m., Julian M. wrote: > Package: xserver-xorg-video-amdgpu > Version: 1.2.0-1+b1 > Severity: important > > We have a PC with motherboard MSI A68HM-E33 V2. > It has an HDMI and a VGA output connectors on board. > On Linux, the VGA port doesn't work. > randr lists an HDMI output (works OK) and a DVI output, marked as > disconnected. > We tried forcing video output on this DVI interface, but we get no video on > the VGA port. > We tried different monitors and cables, with no success. > We installed windows 7 on another disc, and after installing the official amd > windows driver, it works fine, dual head with video in both connectors; so, > it's not a hardware issue (i.e. a burned vga port) > We are running Debian Stretch with 4.19.0-0.bpo.6-amd64 kernel. > The HDMI output works fine. This is a kernel amdgpu driver issue, not an xserver-xorg-video-amdgpu one. -- Earthling Michel Dänzer | https://redhat.com Libre software enthusiast | Mesa and X developer
Bug#941863: XDamage events are intermingled with GetImage response
ge event got inserted between GetImage response header, and image data. Note that drawable returned by XDamage (1001) is same drawable on which client issued XGetImage. So 32 bytes of XDamage event is interpreted as image data, and last 32 bytes of image data are interpreted as X server response - resulting in instant crash as image data interpreted as X11 sequence will almost never match. So problem is not in vino-server, nor libx11 nor libxcb, but in X server itself. And indeed, with little instrumentation added there is a code path that generates XDamage event for drawable X from GetImage call for drawable X, inserting XDamage header between GetImage response header and its body, or between two parts of the body if GetImage could not be completed in one response: Thread 1 "Xorg" hit Breakpoint 1, DamageInsideGetImage () at ../../../../damageext/damageext.c:121 121 ../../../../damageext/damageext.c: No such file or directory. (gdb) bt #0 0x56203f7405cf in DamageInsideGetImage () at ../../../../damageext/damageext.c:121 #1 0x56203f7405cf in DamageExtNotify (pDamageExt=0x562040e766f0, pBoxes=0x7fff2a10fc20, nBoxes=1) at ../../../../damageext/damageext.c:121 #2 0x56203f74811b in DamageReportDamage (pDamage=pDamage@entry=0x562040e77540, pDamageRegion=0x562040e77598) at ../../../../../miext/damage/damage.c:1950 #3 0x56203f7488f8 in damageRegionProcessPending (pDrawable=) at ../../../../../miext/damage/damage.c:294 #4 0x56203f748f9d in damageComposite (op=, pSrc=, pMask=, pDst=0x562040adc6a0, xSrc=, ySrc=, xMask=0, yMask=0, xDst=0, yDst=1161, width=1600, height=39) at ../../../../../miext/damage/damage.c:518 #5 0x56203f6f2d7b in compWindowUpdateAutomatic (pWin=) at ../../../../composite/compwindow.c:705 #6 0x56203f6f2d7b in compPaintWindowToParent (pWin=pWin@entry=0x562040ce7790) at ../../../../composite/compwindow.c:729 #7 0x56203f6f3c48 in compPaintChildrenToWindow (pWin=0x562040771b30) at ../../../../composite/compwindow.c:744 #8 0x56203f6f3c48 in compPaintChildrenToWindow (pWin=pWin@entry=0x562040771b30) at ../../../../composite/compwindow.c:736 #9 0x56203f6f14ef in compGetImage (pDrawable=0x562040771b30, sx=1465, sy=1162, w=26, h=38, format=2, planemask=4294967295, pdstLine=0x562040e82980 "") at ../../../../composite/compinit.c:153 #10 0x56203f6667ab in DoGetImage (planemask=, height=, width=, y=, x=, drawable=, format=, client=0x562040cc5f80) at ../../../../dix/dispatch.c:2214 #11 0x56203f6667ab in ProcGetImage (client=0x562040cc5f80) at ../../../../dix/dispatch.c:2276 #12 0x56203f669944 in Dispatch () at ../../../../dix/dispatch.c:478 #13 0x56203f66d914 in dix_main (argc=6, argv=0x7fff2a110078, envp=) at ../../../../dix/main.c:276 #14 0x7fbfcefeabbb in __libc_start_main (main=0x56203f657700 , argc=6, argv=0x7fff2a110078, init=, fini=, rtld_fini=, stack_end=0x7fff2a110068) at ../csu/libc-start.c:308 #15 0x56203f65773a in _start () at ../../../../dix/gc.c:814 Unfortunately that's where my expertise ends. Thanks for tracking down the problem. Can you file an upstream issue at https://gitlab.freedesktop.org/xorg/xserver/issues ? -- Earthling Michel Dänzer | https://redhat.com Libre software enthusiast | Mesa and X developer
Bug#941161: libgl1-mesa-dri: SIGSEGV on starting X server with libgl1-mesa-dri >18.3.6-2, <=19.1.6-1
On 2019-09-25 9:01 p.m., Jim Joyce wrote: > > [47.836] (EE) Backtrace: > [47.836] (EE) 0: /usr/lib/xorg/Xorg (OsLookupColor+0x139) [0x55ffadbdc2c9] > [47.837] (EE) 1: /lib/x86_64-linux-gnu/libpthread.so.0 (funlockfile+0x50) > [0x7f52f52db55f] > [47.837] (EE) 2: /usr/lib/xorg/Xorg (xf86ScreenToScrn+0x4) > [0x55ffadac62c4] > [47.838] (EE) unw_get_proc_name failed: no unwind info found [-10] > [47.838] (EE) 3: /usr/lib/xorg/modules/drivers/amdgpu_drv.so (?+0x0) > [0x7f52f4bd6850] > [47.839] (EE) unw_get_proc_name failed: no unwind info found [-10] > [47.839] (EE) 4: /usr/lib/xorg/modules/drivers/amdgpu_drv.so (?+0x0) > [0x7f52f4bd9540] > [47.839] (EE) 5: /usr/lib/xorg/Xorg (xorgGetVersion+0x267c) > [0x55ffadad135c] > [47.839] (EE) 6: /usr/lib/xorg/Xorg (AbortDDX+0x82) [0x55ffadabcb62] > [47.840] (EE) 7: /usr/lib/xorg/Xorg (LogSetParameter+0x92) > [0x55ffadbe4952] > [47.840] (EE) 8: /usr/lib/xorg/Xorg (FatalError+0x119) [0x55ffadbe5769] > [47.840] (EE) 9: /usr/lib/xorg/Xorg (OsLookupColor+0x181) [0x55ffadbdc311] > [47.841] (EE) 10: /lib/x86_64-linux-gnu/libpthread.so.0 > (funlockfile+0x50) [0x7f52f52db55f] > [47.842] (EE) 11: /lib/x86_64-linux-gnu/libc.so.6 (gsignal+0x141) > [0x7f52f5142081] > [47.843] (EE) 12: /lib/x86_64-linux-gnu/libc.so.6 (abort+0x121) > [0x7f52f512d535] > [47.843] (EE) unw_get_proc_name failed: no unwind info found [-10] > [47.843] (EE) 13: /lib/x86_64-linux-gnu/libc.so.6 (?+0x0) [0x7f52f512d400] > [47.843] (EE) 14: /lib/x86_64-linux-gnu/libc.so.6 (__assert_fail+0x42) > [0x7f52f513ab92] > [47.844] (EE) 15: /usr/local/lib/x86_64-linux-gnu/dri/radeonsi_dri.so > (u_pipe_screen_get_param_defaults+0x176) [0x7f52f39b46e6] /usr/local/lib/x86_64-linux-gnu/dri/radeonsi_dri.so presumably isn't from a Debian package, does moving that away help? -- Earthling Michel Dänzer | https://redhat.com Libre software enthusiast | Mesa and X developer
Bug#931430: Update (X Server in PowerPC Debian SID Xorg is Unusably Slow on Wallstreet)
On 2019-07-13 2:25 a.m., Finn Thain wrote: > > Michel, since this is fbdev not mach64, the bug you found cannot have > caused this. Is this problem confined to powerpc or does it also appear in > other Xorg regression tests? I don't know, but I don't think it matters too much; the goal should be to enable HW acceleration again. -- Earthling Michel Dänzer | https://www.amd.com Libre software enthusiast | Mesa and X developer
Bug#931430: Update (X Server in PowerPC Debian SID Xorg is Unusably Slow on Wallstreet)
On 2019-07-12 12:07 p.m., Finn Thain wrote: > On Fri, 12 Jul 2019, Michel D?nzer wrote: >> On 2019-07-11 6:49 p.m., user...@yahoo.com wrote: >>> >>> b) I was not able to install Michel's patch -- I wasn't sure what >>> compile or other options to use. It looks like I could build a new >>> kernel with that (patched) module; would that be the best way to >>> include the patch? I see that a commit was made yesterday (Jul 10) >>> related to the patch, so I can just wait and test it when it's >>> available in Debian sid, or I can build a new kernel with the patch >>> included. Please advise. >> >> It's an xf86-video-mach64 / xserver-xorg-video-mach64 patch, not a >> kernel one. And yes, it's been merged to upstream Git master: >> https://gitlab.freedesktop.org/xorg/driver/xf86-video-mach64/commit/37498721a520cd1cff367bc36b1ac74b343826ca >> > > Do you plan to backport this commit for Debian's packages? I'm not involved in Debian packaging. -- Earthling Michel Dänzer | https://www.amd.com Libre software enthusiast | Mesa and X developer
Bug#931430: Update (X Server in PowerPC Debian SID Xorg is Unusably Slow on Wallstreet)
On 2019-07-11 6:49 p.m., user...@yahoo.com wrote: > > b) I was not able to install Michel's patch -- I wasn't sure what > compile or other options to use. It looks like I could build a new > kernel with that (patched) module; would that be the best way to include > the patch? I see that a commit was made yesterday (Jul 10) related to > the patch, so I can just wait and test it when it's available in Debian > sid, or I can build a new kernel with the patch included. Please advise. It's an xf86-video-mach64 / xserver-xorg-video-mach64 patch, not a kernel one. And yes, it's been merged to upstream Git master: https://gitlab.freedesktop.org/xorg/driver/xf86-video-mach64/commit/37498721a520cd1cff367bc36b1ac74b343826ca -- Earthling Michel Dänzer | https://www.amd.com Libre software enthusiast | Mesa and X developer
Bug#931430: X Server in PowerPC Debian SID Xorg is Unusably Slow on Wallstreet
On 2019-07-04 8:56 p.m., user...@yahoo.com wrote: > Package: xorg-server > Version: 1.20 > > After installing Debian sid on a PowerBook G3 Wallstreet > (292 MHz, 512 MB memory) and selecting the default Debian > desktop and Xfce, I noticed that the desktop is unusably > slow. Just moving or resizing windows on the desktop is > painfully slow compared to Debian 7.8 (which is usable) and > Debian 8.11 (which is still usable but slower than 7.8). > > It is difficult to quantify the subjective slowness of > the graphics performance in Debian sid on the Wallstreet. > In an attempt to quantify the slowness, X11 performance > was tested and compared in Debian 7.8, Debian 8.11 and > Debian sid using the x11perf program. > > Each x11perf test was run by booting to single-user mode. > > For each test (Debian 7.8, Debian 8.11 and Debian sid), > there are four files: > > 1) Serial console log. > 2) dmesg output. > 3) Xorg log from /var/log/Xorg.0.log. > 4) "x11perf -all" output. One obvious issue is that xserver-xorg-video-mach64 was built without any hardware acceleration support, because the check for EXA support spuriously failed. https://gitlab.freedesktop.org/xorg/driver/xf86-video-mach64/merge_requests/1 fixes this. Meanwhile, you can try enabling Option "shadow_fb", or using xserver-xorg-video-fbdev instead of xserver-xorg-video-mach64 (as was the case with Debian 8). -- Earthling Michel Dänzer | https://www.amd.com Libre software enthusiast | Mesa and X developer
Bug#930552: xserver-xorg-video-radeon: X-server regularily fails to start while booting
On 2019-06-15 2:04 p.m., Bert Schlumwig wrote: > Package: xserver-xorg-video-radeon > Version: 1:19.0.1-1 > Severity: important > > X-server fails to start while booting > > In 30% of all reboots, X-server fails to start. When the time comes to start > x-server it fails and leaves me with a backtrace at the CLI login. If I login > as root and try to reboot the machine cleanly, it will get stuck and I have to > poweroff. My only option is to hit the magic-sysrq keys (ctrl + shift + print > + > B) to force an immediate reboot. > > My hardware is AMD-A10-5750M APU with Radeon(tm) HD Graphics and a AMD-HD8970 > dedicated graphics in a MSI Laptop. > > Below, I added two kerneltraces from two different crashes: > > Kerneltrace 1: > > Jun 15 12:08:56 mymachine kernel: [ cut here ] > Jun 15 12:08:56 mymachine kernel: kernel BUG at > drivers/gpu/drm/radeon/radeon_asic.c:55! This is a kernel issue, not a Xorg driver one. -- Earthling Michel Dänzer | https://www.amd.com Libre software enthusiast | Mesa and X developer
Bug#930011: xserver-xorg-video-radeon: Can not login to X
On 2019-06-05 6:55 a.m., Costas Ganis wrote: > Package: xserver-xorg-video-radeon > Version: 1:19.0.1-1 > Severity: important > > Dear Maintainer, > > Couldn't login to X after buster apt upgrade. > > Solution was to log in as root and do: > #nano /etc/X11/Xwrapper.config > > Replace: > needs_root_rights=yesallowed_users=anybody > > With: > needs_root_rights=yes > allowed_users=anybody > > And press CTRL+ O to save. > > After rebooting all was fine. This isn't a driver bug. If there's a bug at all, it's in whatever wrote the mangled /etc/X11/Xwrapper.config file. -- Earthling Michel Dänzer | https://www.amd.com Libre software enthusiast | Mesa and X developer
Bug#927852: Info received (Bug#927852: Acknowledgement (xwayland: GNOME Shell crashes after connecting ThinkPad Thunderbolt 3 Dock Gen 2 via Thunderbolt to a Lenovo T470))
On 2019-05-07 7:13 a.m., - wrote: > This morning GNOME Shell crashed again, see attached logs. > Connecting/disconecting the Thunderbolt Gen2 Dock was working fine for > 1-2 weeks, now it crashed again. > > Hope the logs help to narrow down the issue finally. It looks like it could be (related to) https://gitlab.freedesktop.org/xorg/xserver/issues/11 , which is said to be fixed with Xwayland 1.20.4. Have you tried that? -- Earthling Michel Dänzer | https://www.amd.com Libre software enthusiast | Mesa and X developer
Bug#927852: Info received (Bug#927852: Acknowledgement (xwayland: GNOME Shell crashes after connecting ThinkPad Thunderbolt 3 Dock Gen 2 via Thunderbolt to a Lenovo T470))
On 2019-04-25 5:06 p.m., - wrote: > > So what would be your suggestion on how to proceed? Are there any > promising paths I could follow to narrow down the issues? You should probably file a separate report against the chromium package about the chromium crash. -- Earthling Michel Dänzer | https://www.amd.com Libre software enthusiast | Mesa and X developer
Bug#927852: Info received (Bug#927852: Acknowledgement (xwayland: GNOME Shell crashes after connecting ThinkPad Thunderbolt 3 Dock Gen 2 via Thunderbolt to a Lenovo T470))
On 2019-04-25 1:26 p.m., - wrote: >> >> Signal 15 is SIGTERM, so this looks like something terminates a lot >> (most / all?) of processes in your session. Maybe Xwayland is another >> victim of that. There is no evidence here of anything going wrong in >> Xwayland itself. >> > > I installed auditd and added the following rule: > > -a always,exit -F arch=b64 -S kill > > Now there are more detailed log entries in journalctl. > Do they help to narrow down who is terminating the processes? I am not > able to interpret them, therefore I am asking. Looks like that was a red herring, in the form of GDM terminating its own GNOME session for the login screen while another VT is active. -- Earthling Michel Dänzer | https://www.amd.com Libre software enthusiast | Mesa and X developer
Bug#897993: random black flickering
On 2019-04-25 1:35 a.m., Eduard Bloch wrote: > On Mon, 7 May 2018 12:15:37 +0200 =?UTF-8?Q?Michel_D=c3=a4nzer?= > wrote: >> On 2018-05-05 04:20 PM, Eduard Bloch wrote: >>> Package: xserver-xorg-video-amdgpu >>> Version: 18.0.1-1 >>> Severity: normal >>> >>> Hello, >>> >>> my card (cheaper version of Rx560) has been working quite well for months. >>> But I made a dist-upgrade a few weeks ago and since then I see strange >>> flickering happening every few minutes, sometimes even multiple times >>> per minute. Feels like a quick insertion of a black frame. Maybe a >>> silent GPU reset or something? >>> >>> It seems to happen more often when mouse is moving and/or Firefox is >>> active. First I suspected the application where I saw it most in the >>> first days (another web browser) but now I see this happen from time to >>> time with other applications, like the gvim window I see in front of me >>> right now. >>> >>> First I attribute this to the amdgpu.dc=1 kernel option which I have set >>> for testing purposes before, but removing it did not change the >>> behavior. >> >> That's because DC is enabled by default for you, you need amdgpu.dc=0 to >> disable it. This is a DC issue which is fixed in current 4.16.y upstream. > > Hi, > > not sure this was the issue or maybe the root cause is somewhere else. > I got my graphics card replaced in the meantime (now a RX580) and the > problem still appears, although less frequent. I can reproduce it well > when screen config is set to 2560x1440 and 75Hz, latest Sid version of > xserver-xorg-video-amdgpu. Which kernel version? Have you tried disabling DC? > And the temporarily visible overlay looks more like garbage (i.e. it > feels like a quick GPU restart). A GPU reset would take more time, and would likely leave your session unusable without at least restarting Xorg. > The flickering is much less disturbing if the moved window is a simple > one, like xterm, so it might have some connection to the drawing > performance? It might be related to GPU load, e.g. to the GPU memory clock being changed dynamically. You could try if forcing the clock to a certain value avoids the problem. -- Earthling Michel Dänzer | https://www.amd.com Libre software enthusiast | Mesa and X developer
Bug#927852: Info received (Bug#927852: Acknowledgement (xwayland: GNOME Shell crashes after connecting ThinkPad Thunderbolt 3 Dock Gen 2 via Thunderbolt to a Lenovo T470))
On 2019-04-25 9:16 a.m., - wrote: > This morning I applied all available updates, did a reboot, waited ~10 > sec and then connected the dock. Monitor arrangement was fine and GNOME > Shell did not crash. > But this time Chromium was not responding correctly (e.g. right click > to open a folder from the bookmarks in incognito window) and then > finally just crashed and closed. > > There are two interesting parts in the log I think. > > First one is after bolt started > > " > ... > Apr 25 08:46:11 debian-t470 boltd[1708]: bolt 0.7 starting up. > Apr 25 08:46:11 debian-t470 boltd[1708]: config: loading user config > Apr 25 08:46:11 debian-t470 boltd[1708]: bouncer: initializing polkit > Apr 25 08:46:11 debian-t470 boltd[1708]: udev: initializing udev > ... > Apr 25 08:46:16 debian-t470 gnome-session-binary[837]: WARNING: > Application 'org.gnome.SettingsDaemon.A11ySettings.desktop' killed by > signal 15 > [...] Signal 15 is SIGTERM, so this looks like something terminates a lot (most / all?) of processes in your session. Maybe Xwayland is another victim of that. There is no evidence here of anything going wrong in Xwayland itself. -- Earthling Michel Dänzer | https://www.amd.com Libre software enthusiast | Mesa and X developer
Bug#927852: Acknowledgement (xwayland: GNOME Shell crashes after connecting ThinkPad Thunderbolt 3 Dock Gen 2 via Thunderbolt to a Lenovo T470)
On 2019-04-24 4:25 p.m., - wrote: > This seems to be a serious bug, because now GNOME Shell also has > crashed when disconnecting the thunderbolt device. Does it still happen with xwayland 2:1.20.4-1 from sid? If yes: > I also added a journalctl log. > > [...] > > Apr 24 16:08:24 debian-t470 org.gnome.Shell.desktop[1387]: (EE) 2: > /usr/bin/Xwayland (present_extension_init+0xcd2) [0x560ec4ee0542] > Apr 24 16:08:24 debian-t470 org.gnome.Shell.desktop[1387]: (EE) 3: > /usr/bin/Xwayland (present_extension_init+0xf14) [0x560ec4ee0b04] > Apr 24 16:08:24 debian-t470 org.gnome.Shell.desktop[1387]: (EE) 4: > /usr/bin/Xwayland (glamor_egl_fd_from_pixmap+0x637) [0x560ec4e22a67] FWIW, these symbols are probably bogus, as glamor_egl_fd_from_pixmap in Xwayland is a stub which just returns -1, no way it ends up calling present_* functions. -- Earthling Michel Dänzer | https://www.amd.com Libre software enthusiast | Mesa and X developer
Bug#926859: X Server Does Not Start
On 2019-04-11 1:03 p.m., Toni wrote: > Package: xserver-xorg > Version: 1:7.7+19 > Severity: grave > > > > Hi, > > I am not sure whether this is the correct package to report the bug > against, since several drivers are involved, and X stopped working for > every setup simultanously. > > On my laptop with an Optimus graphics, X does no longer start after > recent upgrades from two days ago until now. The symptom is that the X > server briefly starts to draw the desktop, but then immediatly exits > "successfully". The X server exiting successfully means the problem most likely isn't on the X server side but on the client side, e.g. the session manager client disconnects. > The error messages vary, depending on whether I am loading the nouveau > driver or not. With the intel driver, I get: > > > xf86EnableIOPorts: failed to setIOPL for I/O (Operation not permitted) > > > With the nouveau driver, I get: > > > Error allocating PGRAPH context for M2MF These are thus likely red herrings. -- Earthling Michel Dänzer | https://www.amd.com Libre software enthusiast | Mesa and X developer
Bug#878170: Problem elsewhere, you can close it
On 2019-04-03 2:26 p.m., Anton Ivanov wrote: > I found the underlying root cause and the fix by chance when trawling > the web for something else. > > The issue is compositing in the window manager. > > If compositing is enabled the video WILL tear. If compositing is > disabled the videos display correctly. > > Definitely the case for xfce4. It's an xfwm4 (configuration) issue then. -- Earthling Michel Dänzer | https://www.amd.com Libre software enthusiast | Mesa and X developer
Bug#924540: xserver-xorg-video-radeon: undefined symbol: glamor_finish when AccelMethod is EXA and TearFree is on
On 2019-03-13 11:28 p.m., Antonio Ospite wrote: > Package: xserver-xorg-video-radeon > Version: 1:19.0.0-1 > Severity: minor > > Dear Maintainer, > > when upgrading from 18.1.0-1 to 18.1.99+git20190207-1 (or 19.0.0-1) Xorg > failed to start on my system with the following error in the logs: > > mar 13 23:06:44 jcn /usr/lib/gdm3/gdm-x-session[12568]: /usr/lib/xorg/Xorg: > symbol lookup error: /usr/lib/xorg/modules/drivers/radeon_drv.so: undefined > symbol: glamor_finish > > at first I worked around the problem by downgrading the package. > > However upon further investigation it turned out I had some old custom > config in /usr/share/X11/xorg.conf.d/ which breaks new versions of the > driver. > > In particular, having both the settngs below in > /usr/share/X11/xorg.conf.d/10-radeon.conf makes Xorg fail to start when > using the xserver-xorg-video-radeon driver: > > Option "AccelMethod" "EXA" > Option "TearFree" "on" > > Anyway, removing these options fixes the issue for me. > > Not sure if this is a regression [...] It is, thanks for the report. Fixed by https://gitlab.freedesktop.org/xorg/driver/xf86-video-ati/commit/79bc0e054f37026377d54cac6cd8127d4aa9baca . That said, I recommend against forcing EXA, unless there's a good reason for it. glamor generally works better these days. Also, FWIW, TearFree no longer needs to be enabled in xorg.conf but can be configured dynamically with xrandr. See the radeon manpage on TearFree. -- Earthling Michel Dänzer | https://www.amd.com Libre software enthusiast | Mesa and X developer
Bug#920862: xorg: Input doesn't work on LTSP clients while X is running, works otherwise
On 2019-01-30 10:34 a.m., Michel Dänzer wrote: > On 2019-01-29 10:39 p.m., Lasse Flygenring-Harrsen wrote: >> Package: xorg >> Version: 1:7.7+19 >> Severity: critical >> Justification: breaks the whole system >> >> Dear Maintainer, >> >> I have been running a Fat-client LTSP (pxe network booted clients getting >> their software from NBD on a server) system at the school were i work >> for a couple of months, however recently input stopped working an all >> physical hardware, the system boots fine and the Displaymanager (LDM in >> my case) works fine except for the fact that keyboard and mouse input >> doesn't work. I have managed to get to a shell on the machines and in >> text mode TTY's keyboard input works fine and i have confirmed that >> both mouse and keyboard is being detected with lsusb. I also tried >> starting KDE with startkde, and X seems to work fine there as well except >> for the lack of keyboard input, same with xinit and xterm. I have also tried >> PS/2 input on the >> machines with the same results. The weirdest >> thing however is that virtual machines that boot from the same server do >> work, both with KVM and VirtualBox that are configured to simulate USB >> inputs. I have >> included the contents of /var/log/Xorg.0.log from one of the affected >> physical computers below. The problem seems to affect both the stable >> and testing branch, I have tried reinstallintg with both. With the same >> results. >> >> [...] >> >> [ 1357.201] (II) config/udev: Adding input device Logitech USB Optical >> Mouse (/dev/input/mouse0) >> [ 1357.201] (II) No input driver specified, ignoring this device. >> [ 1357.201] (II) This device may have been added with another device file. >> [ 1357.201] (II) config/udev: Adding input device ImPS/2 Logitech Wheel >> Mouse (/dev/input/mouse1) >> [ 1357.202] (II) No input driver specified, ignoring this device. >> [ 1357.202] (II) This device may have been added with another device file. >> [ 1361.133] (II) Server terminated successfully (0). Closing log file. > > Looks like there are no input drivers that Xorg can use. Is either > xserver-xorg-input-libinput or xserver-xorg-input-evdev installed? Actually, I misinterpreted that. Your system seems to only have /dev/input/mouse* devices, but the xserver-xorg-input-libinput/evdev drivers only work with /dev/input/event*. This isn't an X bug but probably some kind of issue between the kernel and udev. -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Mesa and X developer
Bug#920862: xorg: Input doesn't work on LTSP clients while X is running, works otherwise
On 2019-01-29 10:39 p.m., Lasse Flygenring-Harrsen wrote: > Package: xorg > Version: 1:7.7+19 > Severity: critical > Justification: breaks the whole system > > Dear Maintainer, > > I have been running a Fat-client LTSP (pxe network booted clients getting > their software from NBD on a server) system at the school were i work > for a couple of months, however recently input stopped working an all > physical hardware, the system boots fine and the Displaymanager (LDM in > my case) works fine except for the fact that keyboard and mouse input > doesn't work. I have managed to get to a shell on the machines and in > text mode TTY's keyboard input works fine and i have confirmed that > both mouse and keyboard is being detected with lsusb. I also tried > starting KDE with startkde, and X seems to work fine there as well except > for the lack of keyboard input, same with xinit and xterm. I have also tried > PS/2 input on the > machines with the same results. The weirdest > thing however is that virtual machines that boot from the same server do > work, both with KVM and VirtualBox that are configured to simulate USB > inputs. I have > included the contents of /var/log/Xorg.0.log from one of the affected > physical computers below. The problem seems to affect both the stable > and testing branch, I have tried reinstallintg with both. With the same > results. > > [...] > > [ 1357.201] (II) config/udev: Adding input device Logitech USB Optical Mouse > (/dev/input/mouse0) > [ 1357.201] (II) No input driver specified, ignoring this device. > [ 1357.201] (II) This device may have been added with another device file. > [ 1357.201] (II) config/udev: Adding input device ImPS/2 Logitech Wheel > Mouse (/dev/input/mouse1) > [ 1357.202] (II) No input driver specified, ignoring this device. > [ 1357.202] (II) This device may have been added with another device file. > [ 1361.133] (II) Server terminated successfully (0). Closing log file. Looks like there are no input drivers that Xorg can use. Is either xserver-xorg-input-libinput or xserver-xorg-input-evdev installed? -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Mesa and X developer
Bug#918457: xserver-xephyr: multi-screen setup with xinerama and RANDR extensions: extra screens not directly usable
On 2019-01-08 11:32 a.m., Ondřej Grover wrote: > In that case I suppose this bug can be closed as invalid. > > Would you have any suggestion on how to achieve this using some other > virtual nesting server? I'm afraid not. What you're looking for requires integration between RandR and Xinerama which just doesn't exist (yet, assuming it's possible at all), at least not in the X.org reference implementation. I do suspect Xephyr should also disable RandR when Xinerama is enabled, maybe this bug report can be re-purposed for that. -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Mesa and X developer
Bug#918457: xserver-xephyr: multi-screen setup with xinerama and RANDR extensions: extra screens not directly usable
On 2019-01-07 4:37 p.m., Ondřej Grover wrote: > Thank you for the clarification. > Perhaps the tutorials and information on the internet misrepresent this > setup. But it seemed like it worked for other people, xinerama connects the > two screens and RANDR advertises the 2 "physical" outputs. Using Xephyr? Not sure how it could ever have worked like that. -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Mesa and X developer
Bug#918457: xserver-xephyr: multi-screen setup with xinerama and RANDR extensions: extra screens not directly usable
On 2019-01-06 11:29 a.m., Ondřej Grover wrote: > Package: xserver-xephyr > Version: 2:1.19.2-1+deb9u5 > Severity: normal > > Dear Maintainer, > > I'm trying to use Xephyr to test my awesome (WM) multi-screen setup. > As per instructions found on the Internet I spawned a Xephyr server with 2 > screens and the Xinerama and RANDR extensions activated: > > Xephyr -screen 960x540+0+0 -screen 960x540+960+0 +extension RANDR +xinerama > :1 & > > This spawns 2 windows side-by-side (due to the +X+Y panning information, but > also works without it and has the same issue), labeled :1.0 and :1.1 > However, when I ask xrandr about the screens, it sees only one screen/output > > DISPLAY=:1 xrandr > xrandr: Failed to get size of gamma for output default > Screen 0: minimum 160 x 160, current 1920 x 540, maximum 1600 x 1200 > default connected 960x540+0+0 (normal left inverted right x axis y axis) 0mm > x 0mm >1600x1200 0.00 >1400x1050 0.00 >1280x960 0.00 >1280x1024 0.00 >1152x864 0.00 >1024x768 0.00 >832x6240.00 >800x6000.00 >720x4000.00 >480x6400.00 >640x4800.00 >640x4000.00 >320x2400.00 >240x3200.00 >160x1600.00 >960x5400.00* > > So when I start awesome (WM) on this display, it detects only the first > screen/output > > DISPLAY=:1 awesome & > > Now if I attempt to start an xterm on the first screen, it works correctly > > DISPLAY=:1.0 xterm & > > I can even move this terminal toward the right screen and it becomes visible > on the second (:1.1) screen, so perhaps Xinerama is working. > > However, If I attempt to start an xterm on the second screen directly, it > fails (even without awesome) > > DISPLAY=:1.1 xterm & > xterm: Xt error: Can't open display: :1.1 That's the point of Xinerama. :) It combines the "physical" screens to a single logical one. You can see the information about the "physical" screens provided by the Xinerama extension via xdpyinfo -ext XINERAMA > My feeling so far is that the second (possibly any extra) display is not > properly advertised or registered. Perhaps the RANDR extension is not working > properly? Xinerama and RandR are generally incompatible. The Xorg server completely disables RandR when Xinerama is enabled. I suspect Xephyr leaves it enabled by accident, not intentionally. -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Mesa and X developer
Bug#914203: Checked pattern appears on X clients
On 2018-11-20 5:00 p.m., Stéphane Glondu wrote: > Package: xwayland > Version: 2:1.20.3-1 > Severity: important > > Dear Maintainers, > > Under a GNOME session with Wayland, a checked pattern appears on X > clients when calling the "View split on left/right" feature > (Super+Left/Right)... not always, but usually after a few back and > forth. Attached is a screenshot showing the problem with Firefox, but > I see the problem also with emacs, wish, xterm, gitk, git-gui... the > pattern doesn't always cover the whole window, but it seems the title > bar is always affected. >From the screenshot, it looks more likely to be a driver issue than an Xwayland one. Please provide the corresponding output of glxinfo. -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Mesa and X developer
Bug#912397: xserver-xorg-video-amdgpu: Running web browser performance test crashes whole system on AMD RX 460
On 2018-10-31 6:32 a.m., Will Brokenbourgh wrote: > Package: xserver-xorg-video-amdgpu > Version: 1.2.0-1+b1 > Severity: serious > > Dear Maintainer, > > When a web browser performance test was performed using the latest git > version of the surf browser > it appears the 'xserver-xorg-vide-amdgpu' driver crashes the whole system, > [...] This is more likely an issue in Mesa or the kernel. The Xorg driver doesn't have any GPU specific code which could cause something like this anymore. -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Mesa and X developer
Bug#910846: User error.
On 2018-10-15 5:48 p.m., Gong S. wrote: > Using "glamor" instead of "EXA" works. However, the manpage says "EXA > (for pre-TAHITI GPUs) and glamor (for R300 or higher)". TURKS GPUs > are pre-TAHITI ones. They're also post-R300. :) The next sentence (with side note which doesn't apply here elided) in the manpage is: The default is glamor with R600 or newer [...], otherwise EXA. > I cannot test the patch for you. No problem. I'll send out the patch for review anyway, it's pretty likely it'll fix the crash. -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Mesa and X developer signature.asc Description: OpenPGP digital signature
Bug#910846: User error.
On 2018-10-15 1:43 p.m., Gong S. wrote:
> Sorry, I have found the problem. If I remove this line from
> "/etc/X11/xorg.conf", X would not crash:
> Option "DRI" "3"
If removing
Option "AccelMethod" "EXA"
as well also works, that would be the best solution for you.
> So it is my fault. Sorry.
The crash is still a bug, even though EXA & DRI3 isn't recommended,
because it can't work correctly in some cases.
Any chance you can test if the attached patch fixes the crash?
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Mesa and X developer
From e64500c35c3c4b233d12358837a18dcf362ba8f8 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Michel=20D=C3=A4nzer?=
Date: Mon, 15 Oct 2018 17:14:41 +0200
Subject: [PATCH xf86-video-ati] dri3: Handle radeon_get_pixmap_bo returning
NULL
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Fixes: b85b7b11f5b5 "Add struct radeon_buffer"
Signed-off-by: Michel Dänzer
---
src/radeon_dri3.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/src/radeon_dri3.c b/src/radeon_dri3.c
index 7e89a2f0b..25078bae1 100644
--- a/src/radeon_dri3.c
+++ b/src/radeon_dri3.c
@@ -212,7 +212,7 @@ static int radeon_dri3_fd_from_pixmap(ScreenPtr screen,
CARD16 *stride,
CARD32 *size)
{
- struct radeon_bo *bo;
+ struct radeon_buffer *bo;
int fd;
#ifdef USE_GLAMOR
ScrnInfoPtr scrn = xf86ScreenToScrn(screen);
@@ -222,10 +222,10 @@ static int radeon_dri3_fd_from_pixmap(ScreenPtr screen,
return glamor_fd_from_pixmap(screen, pixmap, stride, size);
#endif
- bo = radeon_get_pixmap_bo(pixmap)->bo.radeon;
+ bo = radeon_get_pixmap_bo(pixmap);
if (!bo) {
exaMoveInPixmap(pixmap);
- bo = radeon_get_pixmap_bo(pixmap)->bo.radeon;
+ bo = radeon_get_pixmap_bo(pixmap);
if (!bo)
return -1;
}
@@ -233,11 +233,11 @@ static int radeon_dri3_fd_from_pixmap(ScreenPtr screen,
if (pixmap->devKind > UINT16_MAX)
return -1;
- if (radeon_gem_prime_share_bo(bo, ) < 0)
+ if (radeon_gem_prime_share_bo(bo->bo.radeon, ) < 0)
return -1;
*stride = pixmap->devKind;
- *size = bo->size;
+ *size = bo->bo.radeon->size;
return fd;
}
--
2.19.1
signature.asc
Description: OpenPGP digital signature
Bug#910846: No packages.
On 2018-10-14 6:53 a.m., Gong S. wrote: > There is no "xserver-xorg-video-radeon-dbgsym" or > "xserver-xorg-core-dbgsym" in the repo. They're in a separate repository: deb https://deb.debian.org/debian-debug/-debug main contrib non-free Replace with the name of the suite you're using in your main repository entry. -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Mesa and X developer signature.asc Description: OpenPGP digital signature
Bug#910846: X server "Segmentation fault at address 0x0" when using about:support in Firefox-based browsers.
On 2018-10-12 6:40 a.m., Gong S. wrote: > Package: xserver-xorg-video-radeon > Version: 1:18.1.0-1 > > I am using a standalone AMD HD 7670. "firmware-amd-graphics" is installed and > loaded during boot. > It seems that whenever I tries to query information about hardware > acceleration, X segfaults. > "dmesg" does not show any error or warning after segfault. > Sometimes other programs or games trigger it as well, with the same problem > described in the file Xorg.0.log. [...] > [ 324.504] (EE) Backtrace: > [ 324.505] (EE) 0: /usr/lib/xorg/Xorg (OsLookupColor+0x139) [0x562764468de9] > [ 324.505] (EE) 1: /lib/x86_64-linux-gnu/libpthread.so.0 (funlockfile+0x50) > [0x7f100883292f] > [ 324.506] (EE) 2: /usr/lib/xorg/modules/drivers/radeon_drv.so > (_init+0x1592) [0x7f10073d4b24] > [ 324.506] (EE) 3: /usr/lib/xorg/Xorg (dri3_send_open_reply+0x55d) > [0x562764438b4d] > [ 324.506] (EE) 4: /usr/lib/xorg/Xorg (drm_format_for_depth+0x93b) > [0x56276443827b] > [ 324.506] (EE) 5: /usr/lib/xorg/Xorg (SendErrorToClient+0x35e) > [0x56276430a97e] > [ 324.506] (EE) 6: /usr/lib/xorg/Xorg (InitFonts+0x3b6) [0x56276430e906] > [ 324.506] (EE) 7: /lib/x86_64-linux-gnu/libc.so.6 (__libc_start_main+0xe7) > [0x7f1008683b17] > [ 324.506] (EE) 8: /usr/lib/xorg/Xorg (_start+0x2a) [0x5627642f867a] > [ 324.506] (EE) > [ 324.506] (EE) Segmentation fault at address 0x0 Please make sure the xserver-xorg-video-radeon-dbgsym and xserver-xorg-core-dbgsym packages are installed, and either get a backtrace with gdb or another log file. Does the problem also happen without Option "AccelMethod" "EXA"? That's the default and recommended configuration for your GPU. -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Mesa and X developer
Bug#904995: xserver-common: black screen with mouse on screen rotate.
On 2018-08-16 10:27 AM, Simon Polack wrote: > The issue seems to be not limited to ATI/AMD graphics, as i face it on > intel aswell. That's probably a separate bug in the modesetting driver, which might indeed be fixed in upstream xserver 1.20.1. -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Mesa and X developer
Bug#905960: amdgpu: After login the screen is corrupted, it is unusable in this state
On 2018-08-12 02:01 PM, Andrew Goodbody wrote: > Package: xserver-xorg-video-amdgpu > Version: 18.0.1-1+b1 > Severity: critical > File: amdgpu > Justification: breaks the whole system No it doesn't, so the severity is inflated. The package is wrong as well, should be xserver-xorg-video-radeon. Anyway, this looks like another instance of https://bugs.freedesktop.org/105381 , fixed in upstream xf86-video-ati Git master. Meanwhile, you can avoid the problem with Option "AccelMethod" "EXA" or the modesetting driver. -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Mesa and X developer
Bug#902617: gnome-maps, totem: Cannot move map, play video without allow_rgb10_configs=false
On 2018-08-14 10:33 AM, Simon McVittie wrote: > Control: reassign 902617 libgl1-mesa-dri 18.1.2-1 > Control: retitle 902617 gnome-maps, totem: Cannot move map, play video > without allow_rgb10_configs=false > Control: tags 902617 + moreinfo > > On Thu, 28 Jun 2018 at 17:15:12 +0200, Onno Leerink wrote: >> Since installing Debian buster it is not possible to move the map using the >> mouse in gnome-maps. Before this, moving the map was no problem. >> >> I found the following temporary solution in Redhat bug 1560481, start gnome- >> maps with: >> >> allow_rgb10_configs=false gnome-maps >> >> This causes to gnome-maps to function normally again. >> >> This same solution also solves a bug concerning Totem not playing videos >> anymore. >> >> I have a amd graphics card. > > This sounds like a bug in your graphics driver rather than gnome-maps, so > I'm reassigning it to the libgl1-mesa-dri package. The allow_rgb10_configs > environment variable that you're using to work around this is a Mesa > feature. While the allow_rgb10_configs environment variable is a Mesa feature, it's usually only needed to work around application / framework issues. In this particular case, it's probably a known issue with the way clutter does hit testing, which needs to be adapted to work with 10 bits per component colour formats. This has been fixed in the current upstream version of clutter used by mutter / gnome-shell, not sure about the standalone clutter. -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Mesa and X developer
Bug#904995: xserver-common: black screen with mouse on screen rotate.
On 2018-08-14 11:34 AM, Simon Polack wrote: > Package: xserver-common > Version: 2:1.20.0-3 > Followup-For: Bug #904995 > > Dear Maintainer, > > please upgrade to current upstream bugfix release 1.20.1. Thank you a > lot. It probably won't make a difference for this particular bug, though, as it's an xf86-video-ati bug. -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Mesa and X developer
Bug#905395: xserver-xorg-video-ati: only mouse cursor is visible and movable, distorted screen, restarting monitor on RV630
On 2018-08-04 05:23 AM, Martin Kovařík wrote: > Package: xserver-xorg-video-ati > Version: 1:18.0.1-1+b1 > Severity: critical > Justification: breaks the whole system > > Dear Maintainer, > > the system is usable only in Wayland. Login menu is all right too. > > But > in case I run gnome xorg environment is displayed distorted screen. First at > the boot I shortly see some random rest of framebuffer?? of last gnome > session, > after while is displayed normal screen of my gnome desktop but keyboard is in > non reaction state, mouse cursor is more or less movable bat non interactive. > During start of gnome several times the monitor is restarted. > > In case I run gnome metacity the system is interactive but screen is cover of > some partly transparent layer in segmented triangle patern. Running some > application from menu seem not influented by the transparent layer > > The problem occur after recent actualization of xserver-xorg. This should be fixed in upstream xf86-video-ati Git master. In the meantime, you should be able to avoid the problem with Option "AccelMethod" "EXA" in /etc/X11/xorg.conf . -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Mesa and X developer
Bug#904995: [xserver-xorg-core] upgrading to 2:1.20.0-3 results in mouse and blank screen
On 2018-07-31 10:55 AM, Thorsten Ehlers wrote: > Package: xserver-xorg-core > Version: 2:1.20.0-3 > Followup-For: Bug #904995 > > Dear Maintainer, > > same here but only in Gnome X11 sessions not in Gnome (Wayland) sessions. Looks like https://bugs.freedesktop.org/105381 , fixed in upstream xf86-video-ati Git master. Meanwhile, you can try Option "AccelMethod" "EXA" as a workaround. -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Mesa and X developer
Bug#701480: Valgrind does not show the source file with line numbers for some programs, but GDB does
Package: valgrind Version: 1:3.13.0-2+b1 Followup-For: Bug #701480 -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 This has gotten worse with current binutils, now valgrind seems unable to make use of even uncompressed debugging symbols. Is there a solution in sight? - -- System Information: Debian Release: buster/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'stable'), (102, 'experimental'), (1, 'experimental-debug') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.17.5+ (SMP w/4 CPU cores) Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8), LANGUAGE=en_CA.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages valgrind depends on: ii libc6 2.27-4 ii libc6-dbg 2.27-4 Versions of packages valgrind recommends: ii gdb 7.12-6+b2 ii valgrind-dbg 1:3.13.0-2+b1 Versions of packages valgrind suggests: pn alleyoop ii kcachegrind 4:17.08.3-2 pn valgrind-mpi pn valkyrie - -- no debconf information -BEGIN PGP SIGNATURE- iHEEARECADEWIQSwn681vpFFIZgJURRaga+OatuyAAUCW0SLaBMcbWljaGVsQGRh ZW56ZXIubmV0AAoJEFqBr45q27IAGBQAnjyZEEjrGsdhHoWGwVWDbPxmSmAuAJ4q 7wpHBPR/dOKJ8oGhURidaND3ng== =jOhS -END PGP SIGNATURE-
Bug#902965: xserver-xorg-core: lxdm fails to start xserver with 2:1.20.0-3
On 2018-07-07 11:56 AM, Arthur Marsh wrote: > Package: xserver-xorg-core > Version: 2:1.20.0-3 > Followup-For: Bug #902965 > > Dear Maintainer, > > *** Reporter, please consider answering these questions, where appropriate *** > > As another data point, with current Linux git head kernel, xserver-xorg-core > 2:1.20.0-3 and radeon driver, I don't get lxdm starting on boot up, but > running: > > service lxdm restart > > I get a working X session. As I said, it's just luck when you don't hit the issue. This patch series fixes it: https://patchwork.freedesktop.org/series/45979/ I'm planing to merge it upstream next week. -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Mesa and X developer
Bug#902555: radeon.4: Some fixes in the manual
On 2018-07-05 02:04 AM, Bjarni Ingi Gislason wrote: > On Fri, Jun 29, 2018 at 10:56:39AM +0200, Michel Dänzer wrote: >> >> Every item listed in Bjarni's report is logically a separate change. >> Mixing up logically separate changes (especially such a large number) >> makes for a hard to review patch. Hard to review patches are less likely >> to be applied. >> >> Anyway, Bjarni, if you can send a proper patch generated by git >> format-patch, I'm willing to make an exception this time. > > I do not work that way with a text in a single file. I'm not going to argue with you over this. As I said, I'm willing to make an exception this one time, under the condition above. -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Mesa and X developer
Bug#902965: xserver-xorg-core: lxdm fails to start xserver with 2:1.20.0-3
On 2018-07-04 04:39 PM, Arthur Marsh wrote: > > radeon: Failed to deallocate virtual address for buffer: > radeon:size : 8355840 bytes > radeon:va: 0x10090 Looks like maybe you're running into https://bugs.freedesktop.org/105381 . In which case it's not specific to 2:1.20.0-3, you're just lucky when not hitting this issue with any Xorg 1.20. -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Mesa and X developer
Bug#902555: radeon.4: Some fixes in the manual
On 2018-06-28 03:58 PM, G. Branden Robinson wrote: > At 2018-06-28T11:31:30+0200, Michel Dänzer wrote: >> >> Please send this kind of change directly upstream to the >> amd-...@lists.freedesktop.org list for review, split up into one patch >> per logical change. > > Well, a lot of these changes aren't "logical", they're stylistic. Funny. :) I'm sure you know what I meant though: Every item listed in Bjarni's report is logically a separate change. Mixing up logically separate changes (especially such a large number) makes for a hard to review patch. Hard to review patches are less likely to be applied. Anyway, Bjarni, if you can send a proper patch generated by git format-patch, I'm willing to make an exception this time. -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Mesa and X developer signature.asc Description: OpenPGP digital signature
Bug#902555: radeon.4: Some fixes in the manual
Please send this kind of change directly upstream to the amd-...@lists.freedesktop.org list for review, split up into one patch per logical change. On 2018-06-27 09:07 PM, Bjarni Ingi Gislason wrote: > > Don't begin a sentence with a digit. Why not? What's the problem with that? > Add a comma after "e.g.". That looks odd to me. -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Mesa and X developer
Bug#900550: xserver-xorg-core: X server segfaults for xfce4+nouveau after 2:1.19.6-1 -> 2:1.20.0-2 upgrade
On 2018-06-04 02:11 PM, Agustin Martin wrote: > On Fri, Jun 01, 2018 at 12:00:37PM +0200, Michel Dänzer wrote: >> On 2018-06-01 10:10 AM, Agustin Martin Domingo wrote: >>> Package: xserver-xorg-core >>> Version: 2:1.20.0-2 >>> Severity: important >>> >>> Dear Maintainer, >>> >>> After 2:1.19.6-1 -> 2:1.20.0-2 xfce4-session+nouveau segfaults on startup >>> and cannot start sesion. Trying to start it manually with startxfce4 >>> fails giving >>> they suggests that it may be the real cause, with a a fatal interaction >>> between the "compositor" option of xfwm4 and xorg-server-1.20.0. It is also >>> noted that this may be a problem not only with the nouveau driver, but also >>> with radeon driver, both with xfce4. >> >> It would happen with anything using EXA. >> >> https://patchwork.freedesktop.org/patch/226573/ fixes it. > > Patch tested, problem gone with xfce4 composer enabled. Thanks. Great, thanks for testing. The fix has now landed on xserver upstream Git master. -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Mesa and X developer
Bug#896979: xserver-xorg-video-nouveau: Crash when undocking Lenovo P50
On 2018-06-06 03:05 PM, Sam Morris wrote:
> Source: xserver-xorg-video-nouveau
> Followup-For: Bug #896979
>
> I'm still seeing this with Xorg 1.20 (which is not unexpected). Here's a
> better backtrace:
>
> #0 0x7fd90edb5e7b in __GI_raise (sig=sig@entry=6) at
> ../sysdeps/unix/sysv/linux/raise.c:51
> #1 0x7fd90edb7231 in __GI_abort () at abort.c:79
> #2 0x557576dc55ca in OsAbort () at ../../../../os/utils.c:1350
> #3 0x557576dcb163 in AbortServer () at ../../../../os/log.c:877
> #4 0x557576dcbf85 in FatalError (f=f@entry=0x557576dfec30 "Caught
> signal %d (%s). Server aborting\n") at ../../../../os/log.c:1015
> #5 0x557576dc26b3 in OsSigHandler (signo=11, sip=,
> unused=) at ../../../../os/osinit.c:156
> #6 0x7fd90f14cf50 in () at
> /lib/x86_64-linux-gnu/libpthread.so.0
> #7 0x7fd90c027f29 in drmmode_output_dpms (output=0x557578bfaf20,
> mode=3) at ../../src/drmmode_display.c:921
> #8 0x557576cd8813 in xf86DisableUnusedFunctions
> (pScrn=0x557578a6a120) at ../../../../../../hw/xfree86/modes/xf86Crtc.c:3021
> #9 0x557576ce0980 in xf86RandR12CrtcSet (pScreen=,
> randr_crtc=0x557578c33220, randr_mode=0x0, x=0, y=0, rotation= out>, num_randr_outputs=0, randr_outputs=0x0) at
> ../../../../../../hw/xfree86/modes/xf86RandR12.c:1241
> #10 0x557576d20122 in RRCrtcSet (crtc=, mode=0x0, x=0,
> y=0, rotation=rotation@entry=1, numOutputs=numOutputs@entry=0, outputs=0x0)
> at ../../../../randr/rrcrtc.c:774
> #11 0x557576d219fe in ProcRRSetCrtcConfig (client=0x557578a598f0) at
> ../../../../randr/rrcrtc.c:1401
> #12 0x557576c660b8 in Dispatch () at ../../../../dix/dispatch.c:478
> #13 0x557576c6a0b8 in dix_main (argc=13, argv=0x7ffd47296448,
> envp=) at ../../../../dix/main.c:276
> #14 0x7fd90eda2a87 in __libc_start_main (main=0x557576c53d80 ,
> argc=13, argv=0x7ffd47296448, init=, fini=,
> rtld_fini=, stack_end=0x7ffd47296438) at
> ../csu/libc-start.c:310
> #15 0x557576c53dba in _start ()
>
> (gdb) frame 7
> #7 drmmode_output_dpms (output=0x557578bfaf20, mode=3) at
> ../../src/drmmode_display.c:921
> 921 in ../../src/drmmode_display.c
>
> Looking at that file in nouveau's source code:
>
> static void
> drmmode_output_dpms(xf86OutputPtr output, int mode)
> {
> drmmode_output_private_ptr drmmode_output = output->driver_private;
> drmModeConnectorPtr koutput = drmmode_output->mode_output;
> drmModePropertyPtr props;
> drmmode_ptr drmmode = drmmode_output->drmmode;
> int mode_id = -1, i;
>
> for (i = 0; i < koutput->count_props; i++) { // <-- this line!
> props = drmModeGetProperty(drmmode->fd, koutput->props[i]);
> if (props && (props->flags & DRM_MODE_PROP_ENUM)) {
> if (!strcmp(props->name, "DPMS")) {
> mode_id = koutput->props[i];
> drmModeFreeProperty(props);
> break;
> }
> drmModeFreeProperty(props);
> }
> }
>
> Examining some variables:
>
> (gdb) p i
> $7 = 0
>
> (gdb) p koutput
> $8 = (struct _drmModeConnector *) 0x0
Looks like the nouveau driver needs something like
https://cgit.freedesktop.org/xorg/driver/xf86-video-amdgpu/commit/?id=f4107f67f147e2500582fc36cf0f0f76bc1ef098
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Mesa and X developer
Bug#900550: xserver-xorg-core: X server segfaults for xfce4+nouveau after 2:1.19.6-1 -> 2:1.20.0-2 upgrade
On 2018-06-01 10:10 AM, Agustin Martin Domingo wrote: > Package: xserver-xorg-core > Version: 2:1.20.0-2 > Severity: important > > Dear Maintainer, > > After 2:1.19.6-1 -> 2:1.20.0-2 xfce4-session+nouveau segfaults on startup > and cannot start sesion. Trying to start it manually with startxfce4 > fails giving > > > (EE) > (EE) Backtrace: > (EE) 0: /usr/lib/xorg/Xorg (xorg_backtrace+0x4d) [0x555e574106fd] > (EE) 1: /usr/lib/xorg/Xorg (0x555e5725d000+0x1b73b9) [0x555e574143b9] > (EE) 2: /lib/x86_64-linux-gnu/libpthread.so.0 (0x7fc78ff7+0x11f50) > [0x7fc78ff81f50] > (EE) 3: /usr/lib/xorg/Xorg (miRenderColorToPixel+0xe) [0x555e57384a9e] > (EE) 4: /usr/lib/xorg/modules/libexa.so (0x7fc78c9e+0xf12b) > [0x7fc78c9ef12b] > (EE) 5: /usr/lib/xorg/Xorg (0x555e5725d000+0x13a786) [0x555e57397786] > (EE) 6: /usr/lib/xorg/Xorg (0x555e5725d000+0x12eaec) [0x555e5738baec] > (EE) 7: /usr/lib/xorg/Xorg (0x555e5725d000+0x5b008) [0x555e572b8008] > (EE) 8: /usr/lib/xorg/Xorg (0x555e5725d000+0x5f008) [0x555e572bc008] > (EE) 9: /lib/x86_64-linux-gnu/libc.so.6 (__libc_start_main+0xe7) > [0x7fc78fbd1a87] > (EE) 10: /usr/lib/xorg/Xorg (_start+0x2a) [0x555e572a5d0a] > (EE) > (EE) Segmentation fault at address 0x8 > (EE) > Fatal server error: > (EE) Caught signal 11 (Segmentation fault). Server aborting > (EE) > (EE) > Please consult the The X.Org Foundation support > at http://wiki.x.org > for help. > (EE) Please also check the log file at "/var/log/Xorg.2.log" for additional > information. > (EE) > (II) AIGLX: Suspending AIGLX clients for VT switch > (EE) Server terminated with error (1). Closing log file. > > > No problem with icewm and probably other windows managers. > > I have googled a bit about this problem and found a recent message in > debian-user about this very same problem, > > [upgrade to X 1.20.0 broken] > https://lists.debian.org/debian-user/2018/05/msg01008.html > > Problem has been confirmed by some people in that thread and it is suggested > to be triggered by the Xfce compositor > > https://lists.debian.org/debian-user/2018/05/msg01035.html > > As a matter of fact, if I disable the compositor, problem goes away. > > I am filing this bug report against xserver-xorg-core because in other > reference about this problem in slackware, > > https://www.linuxquestions.org/questions/slackware-14/slackware-current-xorg-server-1-20-0-with-xf86-video-nouveau-segfaults-4175629581/ > > they suggests that it may be the real cause, with a a fatal interaction > between the "compositor" option of xfwm4 and xorg-server-1.20.0. It is also > noted that this may be a problem not only with the nouveau driver, but also > with radeon driver, both with xfce4. It would happen with anything using EXA. https://patchwork.freedesktop.org/patch/226573/ fixes it. -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Mesa and X developer
Bug#900352: new xorg-server version causes a random freezes in plasmashell
On 2018-05-29 02:18 PM, Maximiliano Curia wrote: > Package: src:xorg-server > Version: 2:1.20.0-2 > Severity: critical > Tags: upstream > > Hi, > > The severity is set as it breaks "unrelated programs" although I'm not > sure a desktop environment can be called "unrelated" to x, but in any > case, it would be better if this version of xorg does not migrate to > testing till this is fixed. > > The new xorg-server version seems to be causing plasmashell to freeze. > This was first reported in #900145, and it's also seen in other distros: > https://bugs.archlinux.org/task/58549 > > Upstream seems to have a patch for this (actually two patches that fix > this with two different aproaches), that I havent tested: > https://lists.x.org/archives/xorg-devel/2018-May/056829.html The upstream fix (in Mesa, where the bug was) is https://cgit.freedesktop.org/mesa/mesa/commit/?id=fe2edb25dd5628c395a65b60998f11e839d2b458 . -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Mesa and X developer signature.asc Description: OpenPGP digital signature
Bug#900149: xserver-xorg-core: after upgrade plasma shell/ taskbar freezes
On 2018-05-29 09:18 AM, hlehmbr...@gmx.net wrote: > Package: xserver-xorg-core > Version: 2:1.20.0-2 > Severity: important > > Dear Maintainer, > > Hi i tried to use reportbug but something went wrong, so i got a backup > of it. > I use that way to report the bug via a grapical email program and the > html side and copy/paste > > I don't know if this is the right place to report that bug > > *** Reporter, please consider answering these questions, where > appropriate *** > >* What led up to the situation? >Upgrade the xserver > >* What exactly did you do (or not do) that was effective (or > ineffective)? > apt full-upgrade > >* What was the outcome of this action? >Plasma shell/ taskbar freezes no chance to start a program with > mouse click >* What outcome did you expect instead? >a working desktop > > >After upgrading to 1.20.0.2 the kernel modesetting driver causes the >graphical glitches and freezes, no chance to work in graphical mode >(intel gpu i915) Downgading xserver-xorg-core or not using the >kernel modesetting driver (using the intel driver) solves the >porblem for my system. The freezes are due to a Mesa bug, fixed by https://cgit.freedesktop.org/mesa/mesa/commit/?id=fe2edb25dd5628c395a65b60998f11e839d2b458 . -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Mesa and X developer
Bug#897993: random black flickering
On 2018-05-05 04:20 PM, Eduard Bloch wrote: > Package: xserver-xorg-video-amdgpu > Version: 18.0.1-1 > Severity: normal > > Hello, > > my card (cheaper version of Rx560) has been working quite well for months. > But I made a dist-upgrade a few weeks ago and since then I see strange > flickering happening every few minutes, sometimes even multiple times > per minute. Feels like a quick insertion of a black frame. Maybe a > silent GPU reset or something? > > It seems to happen more often when mouse is moving and/or Firefox is > active. First I suspected the application where I saw it most in the > first days (another web browser) but now I see this happen from time to > time with other applications, like the gvim window I see in front of me > right now. > > First I attribute this to the amdgpu.dc=1 kernel option which I have set > for testing purposes before, but removing it did not change the > behavior. That's because DC is enabled by default for you, you need amdgpu.dc=0 to disable it. This is a DC issue which is fixed in current 4.16.y upstream. -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Mesa and X developer
Bug#892982: bugs.debian.org: system freeze after lock screen/switched off moniturs/spontaneously
On 2018-03-15 06:02 PM, Salve Mundus wrote: > Hello Don, > > sorry for the inconvenience you had and thank you for the reassignment. The gnome-shell crash is a gnome-shell bug. The amdgpu messages might be symptoms of an amdgpu kernel driver bug, or might be harmless. I don't see any evidence of an xserver-xorg-video-amdgpu bug (or even that it or Xorg is used at all). -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Mesa and X developer
Bug#891674: Patch to fix the problem
On 2018-02-28 02:41 AM, peter.ch...@data61.csiro.au wrote:
> The linux kernel treats PCI domains as 32 bit ints.
>
> diff -ru libpciaccess-0.13.4/include/pciaccess.h
> libpciaccess-0.13.4-fixed/include/pciaccess.h
> --- libpciaccess-0.13.4/include/pciaccess.h 2015-05-01 14:44:47.0
> +1000
> +++ libpciaccess-0.13.4-fixed/include/pciaccess.h 2018-02-28
> 12:21:12.280963252 +1100
> @@ -321,7 +321,7 @@
> * the domain will always be zero.
> */
> /*@{*/
> -uint16_tdomain;
> +uint32_tdomain;
> uint8_t bus;
> uint8_t dev;
> uint8_t func;
> diff -ru libpciaccess-0.13.4/src/linux_sysfs.c
> libpciaccess-0.13.4-fixed/src/linux_sysfs.c
> --- libpciaccess-0.13.4/src/linux_sysfs.c 2015-05-01 14:44:47.0
> +1000
> +++ libpciaccess-0.13.4-fixed/src/linux_sysfs.c 2018-02-28
> 12:21:32.676941130 +1100
> @@ -157,7 +157,7 @@
> (struct pci_device_private *) >devices[i];
>
>
> - sscanf(devices[i]->d_name, "%04x:%02x:%02x.%1u",
> + sscanf(devices[i]->d_name, "%x:%02x:%02x.%1u",
> & dom, & bus, & dev, & func);
>
> device->base.domain = dom;
>
Doing it like this breaks ABI. This is fixed in libpciaccess 0.14 by
https://cgit.freedesktop.org/xorg/lib/libpciaccess/commit/?id=a167bd6474522a709ff3cbb00476c0e4309cb66f
, though Xorg needs to be rebuilt against that for it to take effect.
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Mesa and X developer
Bug#891442: xserver-xorg-video-radeon: unable to load radeon module with HD 8400E
On 2018-02-25 05:15 PM, Manuele Rampazzo wrote: > Package: xserver-xorg-video-radeon > Version: 1:7.10.0-1 > Severity: important > > Dear Maintainer, > some weeks ago, after an update, 3D on my system failed to corretly > initialize. > > Some syntomps > > $ glxinfo > name of display: :0 > > [no more output, never going back to prompt until Ctrl-C] > > $ glxgears > X Error of failed request: BadAlloc (insufficient resources for operation) > Major opcode of failed request: 149 () > Minor opcode of failed request: 2 > Serial number of failed request: 37 > Current serial number in output stream: 38 > > Firefox, Thunderbird, VLC not working correctly (or not starting at all), etc. This was a Mesa bug, fixed in libgl1-mesa-dri 17.3.4-1 or newer. > /var/log/Xorg.0.log show that radeon module is unloaded, so the system use > vesa > instead. The bug above only happens when using Wayland, in which case Xorg isn't used. -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Mesa and X developer
Bug#890542: amdgpu ERROR
On 2018-02-15 08:26 PM, andreadicioc...@email.it wrote: > Package: xserver-xorg-video-amdgpu Version: 1.2.0-1+b1 > > > I get the errors: > [drm:amdgpu_vce_ring_test_ib [amdgpu]] *ERROR* amdgpu: IB test timed out. > [drm:amdgpu_ib_ring_tests [amdgpu]] *ERROR* amdgpu: failed testing IB on > ring 11 (-110). > [drm:amdgpu_device_init [amdgpu]] *ERROR* ib ring test failed (-110). > > sometimes the pc crashes, I think it's due to these errors, because > they're the only ones I have in the log about the graphics card Those are from the kernel, not from the Xorg driver. -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Mesa and X developer
Bug#884863: Support for Radeon R7 3rd generation (Merlin Falcon) in AMD A8-9600
On 2017-12-20 04:50 PM, Karsten wrote: > Package: x11-common > Version: 1:7.7+19 > Severity: normal > > Hello, > > i have the problem that this GPU is not supported fully. > http://www.cpu-world.com/CPUs/Bulldozer/AMD-A8-Series%20A8-9600.html > > It is not possible to get more display resolution then 1024x768. > > I discussed the problem already here: > https://debianforum.de/forum/viewtopic.php?f=12=167981 I'm afraid you got some bad advice there; your GPU is only supported by the amdgpu driver, not by radeon. The best advice you got there was from rendegast, have you tried the kernel and firmware from backports? If the problem persists with those, please provide the full dmesg output and Xorg log file with them. >From the Xorg log file there, it looks like the drivers don't get the EDID from the monitor. Since you say it's a "VGA-TFT" monitor, but the drivers only detect a DisplayPort connection, are you using some kind of DisplayPort-to-other converter? Can you try connecting the monitor to an HDMI output instead? > It seems that AMD is not interested to support the newer GPU's in > Linux anymore. Speaking as somebody working for AMD on open source GPU driver support, that's a demonstrably false statement. If you're interested, take a look at articles this year on Phoronix and other sites about our drivers. -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Mesa and X developer
Bug#884846: xserver-xorg-video-radeon: xrandr hang on resolution setup after xorg has been started
On 2017-12-20 12:17 PM, Angelo Dureghello wrote: > Package: xserver-xorg-video-radeon > Version: 1:7.8.0-1+b1 > Severity: grave > Justification: renders package unusable "renders the package unusable" in this context means the package cannot be used for its intended purpose at all by anyone, which isn't the case. > Dear Maintainer, > > In xserver-xorg-video-radeon v.1.7.10.0-1 i am observing the following issue: > > after xorg has been started, and openbox-session is called, xrandr seems to > hang leaving interface with mouse pointer only, but not usable. > > The line causing the issue is : > (sleep 1s && xrandr --output VGA-0 --off --output DVI-0 --primary --mode > 2560x1440 --output HDMI-0 --mode 1920x1080 --right-of DVI-0) & When it hangs, can you attach gdb to the Xorg process and get a backtrace? See https://www.x.org/wiki/Development/Documentation/ServerDebugging/ for detailed information about how this can be done. Make sure the xserver-xorg-core-dbgsym and xserver-xorg-video-radeon-dbg packages are installed. > If i roll back to v.1.7.8.0.1+b1 version all works fine as usual and expected. Can you use git bisect to determine which change introduced the problem? -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Mesa and X developer
Bug#884466: mesa: firefox, thunderbird, chromium don't start with mesa 17.3.0-1
On 2017-12-15 07:36 PM, Andreas Boll wrote: > On Fri, Dec 15, 2017 at 05:04:26PM +0100, Rodolphe Pelloux-Prayer wrote: >> Package: libglx-mesa0 >> Version: 17.3.0-1 >> Severity: important >> File: mesa >> >> Dear Maintainer, >> >> after upgrading to 17.3.0-1, firefox, thunderbird and chromium don't start >> or more accuratly seems to not display ([AMD/ATI] Oland GL [FirePro W2100]) >> >> Starting firefox in gdb: >> Start it from the beginning? (y or n) y >> Starting program: /usr/lib/firefox/firefox >> [Thread debugging using libthread_db enabled] >> Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". >> [New Thread 0x7fffe4844700 (LWP 9406)] >> [Thread 0x7fffe4844700 (LWP 9406) exited] >> Error: GDK_BACKEND does not match available displays Looks like this might be due to the environment variable GDK_BACKEND being set to an invalid value. -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Mesa and X developer
Bug#882997: libinput-bin: Laptop keyboard no longer working after upgrading to 1.9.2-1
On 2017-11-28 05:18 PM, Thomas Blanc wrote: > Le 28/11/2017 à 16:47, Michel Dänzer a écrit : >> On 2017-11-28 04:34 PM, Thomas Blanc wrote: >>> Package: libinput-bin >>> Version: 1.9.2-1 >>> Severity: normal >>> >>> Dear Maintainer, >>> >>> When upgrading from 1.8.3-1 to 1.9.2-1, and after restarting X, my >>> laptop's keyboard no longer worked properly on X. >>> My usb keyboard was working properly, so was the keyboard when outside >>> of X. >>> >>> I tried creating a xorg.conf with an explicit keyboard configuration but >>> this did not help (I am no system guru though). >>> >>> Reverting libinput-bin to 1.8.3-1 fixed the issue. >>> >>> My laptop is an HP EliteBook Folio 9470m. I don't know what information >>> you need if you want to investigate but I would be happy to provide >>> them. >> Assuming this only happens while the laptop is docked, it's a kernel bug >> fixed by >> >> https://marc.info/?l=linux-kernel=151188228819123=2 >> >> > This indeed only happens if the laptop is docked. I guess I'll patch my > kernel. > > > Thank you very much for the excellent support. I just happened to run and look into the same issue. :) In the meantime, it's been brought to my attention that there's already a fix for this in 4.15-rc1: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=9968e12a291e639dd51d1218b694d440b22a917f -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Mesa and X developer
Bug#882997: libinput-bin: Laptop keyboard no longer working after upgrading to 1.9.2-1
On 2017-11-28 04:34 PM, Thomas Blanc wrote: > Package: libinput-bin > Version: 1.9.2-1 > Severity: normal > > Dear Maintainer, > > When upgrading from 1.8.3-1 to 1.9.2-1, and after restarting X, my > laptop's keyboard no longer worked properly on X. > My usb keyboard was working properly, so was the keyboard when outside > of X. > > I tried creating a xorg.conf with an explicit keyboard configuration but > this did not help (I am no system guru though). > > Reverting libinput-bin to 1.8.3-1 fixed the issue. > > My laptop is an HP EliteBook Folio 9470m. I don't know what information > you need if you want to investigate but I would be happy to provide them. Assuming this only happens while the laptop is docked, it's a kernel bug fixed by https://marc.info/?l=linux-kernel=151188228819123=2 -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Mesa and X developer
Bug#882348: Probably not strictly a regression in 52.4.0-1
On 2017-11-22 10:57 AM, Michel Dänzer wrote: > > Hi, > > > I also hit this issue. However, I had upgraded thunderbird to 52.4.0-1 > about a month ago, but only noticed this issue this week. > > One thing that changed for me this week is that I'm now running a kernel > with AppArmor enabled. I suspect this issue might be AppArmor related, > though I haven't seen any specific DENIED messages obviously related to > it in /var/log/kern.log. Indeed, disabling thunderbird's AppArmor profile with sudo aa-disable /etc/apparmor.d/usr.bin.thunderbird fixed this issue for me, didn't even need to restart thunderbird. :) -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Mesa and X developer
Bug#882348: Probably not strictly a regression in 52.4.0-1
Hi, I also hit this issue. However, I had upgraded thunderbird to 52.4.0-1 about a month ago, but only noticed this issue this week. One thing that changed for me this week is that I'm now running a kernel with AppArmor enabled. I suspect this issue might be AppArmor related, though I haven't seen any specific DENIED messages obviously related to it in /var/log/kern.log. -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Mesa and X developer
Bug#878170: xserver-xorg-video-radeon: Fails to match video to vsync
On 11/10/17 10:58 AM, Anton Ivanov wrote: > It tears in full screen with and without compositing in xfce Tearing is expected while compositing is in effect, because xfwm4 4.12's compositor cannot avoid tearing. So the question is why there's tearing even without compositing. Can you provide the terminal output of e.g. mplayer when there is tearing in fullscreen? -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Mesa and X developer
Bug#878170: xserver-xorg-video-radeon: Fails to match video to vsync
On 10/10/17 07:50 PM, Anton Ivanov wrote: > Package: xserver-xorg-video-radeon > Version: 1:7.8.0-1+b1 > Severity: important > > Dear Maintainer, > > Radeon (and amdgpu for that matter) in stretch no longer match frames > to vsync correctly. This is observable with vdpau, opengl and plain > xvideo. > > This used to work correctly in jessie so this is a recent regression. > > This is also observable in both full screen and windowed mode. The > bottom ~5-10% of the picture updates on the wrong vsycn which is > clearly visible especially in action sequences and animation. > > Tested with vlc, mplayer, xine and other software in a variety of > output modes. I think I have eliminated other possible common factors > leaving the video driver (and/or firmware) the most likely culprit. The only possibilities for reliably avoiding tearing in Xorg have always been: 1. Using a compositing manager which uses OpenGL for rendering 2. Running an application in fullscreen, using page flipping (i.e. the application must use something like OpenGL / VDPAU / VA-API / ... for rendering / presentation, but not something like XVideo or even pure X11) 3. Enabling TearFree Note that 1.+2. are not sufficient when using rotation or other transforms via the RandR extension. Does your setup fall under any of these cases? If not, you may just have gotten lucky before. -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Mesa and X developer
Bug#872185: Please build LLVM with -DLLVM_DYLIB_SYMBOL_VERSIONING=ON
On 15/08/17 04:54 PM, Sylvestre Ledru wrote: > Le 15/08/2017 à 02:50, Michel Dänzer a écrit : >> This should help avoid trouble in cases where a single process ends up >> linking in multiple libLLVM-*.*.so libraries. >> > This is fixed already in bug #848368 Oops, I missed that, sorry. Thanks for taking care of it! > also merged upstream (which has now two solutions for the same issue) Do you have a pointer to the upstream solution other than LLVM_DYLIB_SYMBOL_VERSIONING? Can't find it in the revision history. -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Mesa and X developer
Bug#872185: Please build LLVM with -DLLVM_DYLIB_SYMBOL_VERSIONING=ON
Package: llvm-4.0 Version: 1:4.0.1-1 Severity: wishlist -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 This should help avoid trouble in cases where a single process ends up linking in multiple libLLVM-*.*.so libraries. - -- System Information: Debian Release: buster/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'stable'), (102, 'experimental'), (1, 'experimental-debug') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.12.5+ (SMP w/4 CPU cores) Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8), LANGUAGE=en_CA.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages llvm-4.0 depends on: ii libc6 2.24-14 ii libgcc1 1:7.1.0-12 ii libjsoncpp1 1.7.4-3 ii libllvm4.01:4.0.1-1 ii libstdc++67.1.0-12 ii libtinfo5 6.0+20170715-2 ii llvm-4.0-runtime 1:4.0.1-1 ii zlib1g1:1.2.8.dfsg-5 Versions of packages llvm-4.0 recommends: ii llvm-4.0-dev 1:4.0.1-1 Versions of packages llvm-4.0 suggests: pn llvm-4.0-doc - -- no debconf information -BEGIN PGP SIGNATURE- iHEEARECADEWIQSwn681vpFFIZgJURRaga+OatuyAAUCWZJFZxMcbWljaGVsQGRh ZW56ZXIubmV0AAoJEFqBr45q27IA3gMAnRyKI7fvvhUiTiApR1umPrsrCRQzAJ9l u9xUu9i5TV8IOW0R4+j5dw151g== =xYoh -END PGP SIGNATURE-
Bug#867701: Radeon HD 6450, black screen, cursor, no console
On 16/07/17 07:04 PM, Ivan Sergio Borgonovo wrote: On 07/16/2017 05:56 PM, Michel Dänzer wrote: Hmm, the string "EGL search path is" and the corresponding code was removed upstream for Mesa 10.6. Look for instances of libEGL.so.1* other than /usr/lib/x86_64-linux-gnu/libEGL.so.1* on your system and see if removing those helps. I'm not sure about what you're asking. On the problematic system apparently there are no packages installed containing libEGL*.* apt-file search libEGL.so libegl1-glvnd-nvidia: /usr/lib/x86_64-linux-gnu/nvidia/current/libEGL.so.1 libegl1-mesa: /usr/lib/x86_64-linux-gnu/libEGL.so.1 libegl1-mesa: /usr/lib/x86_64-linux-gnu/libEGL.so.1.0.0 libegl1-mesa-dev: /usr/lib/x86_64-linux-gnu/libEGL.so libegl1-nvidia: /usr/lib/x86_64-linux-gnu/nvidia/current/libEGL.so.1 libegl1-nvidia: /usr/lib/x86_64-linux-gnu/nvidia/current/libEGL.so.375.66 libegl1-nvidia-legacy-340xx: /usr/lib/x86_64-linux-gnu/nvidia/legacy-340xx/libEGL.so.1 libegl1-nvidia-legacy-340xx: /usr/lib/x86_64-linux-gnu/nvidia/legacy-340xx/libEGL.so.340.102 virtualbox-guest-x11: /usr/lib/virtualbox/additions/libEGL.so virtualbox-guest-x11: /usr/lib/virtualbox/additions/libEGL.so.1 but none of these packages are installed. But find /usr/lib/x86_64-linux-gnu/ -name libEGL*.* /usr/lib/x86_64-linux-gnu/libEGL.so.1 /usr/lib/x86_64-linux-gnu/libEGL.so.1.0.0 ls -l /usr/lib/x86_64-linux-gnu/libEGL.so.1 lrwxrwxrwx 1 root root 15 Jul 17 00:57 /usr/lib/x86_64-linux-gnu/libEGL.so.1 -> libEGL.so.1.0.0 aptitude reinstall glx-alternative-mesa update-alternatives: warning: forcing reinstallation of alternative /usr/lib/mesa-diverted because link group glx is broken You don't need this package. Does installing the libegl1-mesa package help? -- Earthling Michel Dänzer| http://www.amd.com Libre software enthusiast |Mesa and X developer
Bug#868581: xserver-xorg-video-amdgpu doesn't start due to incompatibility to DRM in Debian 9.0
On 16/07/17 04:56 PM, Wolf-Dieter Groll wrote: Package: xserver-xorg-video-amdgpu Version: 1.2.0-1+b1 Severity: normal Tags: newcomer Dear Maintainer, I tried to switch from the "radeon" to the the "amdgpu" driver by adding /etc/X11/xorg.conf.d/20-amdgpu.conf with the following lines: Section "Device" Identifier "AMD" Driver "amdgpu" EndSection This is invalid configuration. The xserver-xorg-video-amdgpu/radeon drivers can only work with the corresponding kernel driver respectively, and Xorg will use the right driver by default automatically. -- Earthling Michel Dänzer| http://www.amd.com Libre software enthusiast |Mesa and X developer
Bug#867701: Radeon HD 6450, black screen, cursor, no console
On 15/07/17 07:24 AM, Ivan Sergio Borgonovo wrote: On 07/15/2017 05:29 AM, Michel Dänzer wrote: On 15/07/17 07:10 AM, Ivan Sergio Borgonovo wrote: On 07/10/2017 04:03 AM, Michel Dänzer wrote: On 09/07/17 03:06 AM, Ivan Sergio Borgonovo wrote: Please provide the output of the following: apt-cache policy libegl1-mesa ldconfig -p|grep libEGL See attachments. Hmm, the string "EGL search path is" and the corresponding code was removed upstream for Mesa 10.6. Look for instances of libEGL.so.1* other than /usr/lib/x86_64-linux-gnu/libEGL.so.1* on your system and see if removing those helps. Does the same problem happen with 1:7.8.0-1+b1 with Option "AccelMethod" "glamor" in /etc/X11/xorg.conf ? Older xserver-xorg-video-radeon with that option DOESN'T WORK. Black screen, text cursor at the top right corner ( _ ). Right, as expected the problem is specific to glamor, which is the default for your GPU in 7.9.0 but wasn't yet in 7.8.0. This means in the worst case you can work around the problem with Option"AccelMethod" "EXA" in /etc/X11/xorg.conf. Thanks, this solved the problem. Could I suggest to add some notes in the changelog before closing the bug? It's just a workaround. We don't know yet what the problem is, though it's likely specific to your system. -- Earthling Michel Dänzer| http://www.amd.com Libre software enthusiast |Mesa and X developer
