Bug#839381: xserver-xorg-video-amdgpu: very long Xorg initilization time in recent kernels
Hi, i think i found the problem: it's powerplay. The bisection showed that 3466904d38ff1e63f0a19cb31166db67f2d05c61 is the commit which introduced the problem: while the code before checked if amdgpu_powerplay > 0 now it checks equality. The default value is -1 so pp is enabled. I booted with amdgpu.powerplay=0 and the problem is gone for the testing kernel 4.7. I tried a more recent kernel (4.9-rc5) and it seemed that it's not checked anymore if amdgpu.powerplay equals 0. I'm adding a patch which re enables the boot parameter. Furthermore i'm not sure what causes the problem with my GPU in the first place. If there is anything i can do please let me know. Best Michael On 10/03/2016 04:45 AM, Michel Dänzer wrote: > On 01/10/16 06:30 PM, Michael Strobel wrote: >> Package: xserver-xorg-video-amdgpu >> Version: 1.1.2-1 >> Severity: normal >> >> Dear Maintainer, >> >> i'm running debian testing and for quite a while i have problems with my >> xserver on newer kernels. While linux-image-4.2.0-1-amd64 works fine >> linux-image-4.6.0-1-amd64 and linux-image-4.7.0-1-amd64 my xserver spends >> very long time (several minutes) on initialization. >> The only problem i can spot is a lot of >> >> Failed to send Previous Message. >> Failed to send Message. >> >> messages in dmesg. I'm not complete sure if the problem is even xserver > > Yeah, unless this doesn't happen with an older version of > xserver-xorg-video-amdgpu (and possibly related packages), it sounds > like an amdgpu kernel driver regression. Any chance you can bisect or at > least narrow down which kernel version introduced the problem? > > From fad1325ec8845a81e2ec39c49c11237fe8a6c689 Mon Sep 17 00:00:00 2001 From: Michael Strobel Date: Sun, 13 Nov 2016 12:39:54 +0100 Subject: [PATCH] respect amdgpu_powerplay == 0 --- drivers/gpu/drm/amd/amdgpu/amdgpu_powerplay.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_powerplay.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_powerplay.c index 7532ff8..b998bef 100644 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_powerplay.c +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_powerplay.c @@ -101,7 +101,7 @@ static int amdgpu_pp_early_init(void *handle) case CHIP_TONGA: case CHIP_FIJI: case CHIP_TOPAZ: - adev->pp_enabled = true; + adev->pp_enabled = (amdgpu_powerplay == 0) ? false : true; break; case CHIP_CARRIZO: case CHIP_STONEY: -- 2.10.2 signature.asc Description: OpenPGP digital signature
Bug#844227: FTBFS on mips*, ./.libs/libmutter-cogl.so: undefined reference to `eglQueryString'
Source: mutter Version: 3.22.2-1 Severity: serious The latest build of mutter failed on mips, mipsel and mips64el with ./.libs/libmutter-cogl.so: undefined reference to `eglQueryString' ./.libs/libmutter-cogl.so: undefined reference to `eglTerminate' collect2: error: ld returned 1 exit status This looks like a recent regression in either mutter or mesa, mutter 3.22.1 built fine on those architectures. -- System Information: Debian Release: stretch/sid APT prefers unstable APT policy: (500, 'unstable'), (200, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.8.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) -- no debconf information
Re: Bug#844227: Acknowledgement (FTBFS on mips*, ./.libs/libmutter-cogl.so: undefined reference to `eglQueryString')
Looking at the git log for mutter, I don't find any changes between 3.22.1 and 3.22.2 which look like it could be the cause for this build failure. So I suspect it's a change in mesa. 3.22.1-2 (from 2016-10-15) successfully built against mesa 12.0.3-1 3.22.2-1 failed to build [1] against 12.0.4-2 @mesa maintainers: any ideas? [1] https://buildd.debian.org/status/fetch.php?pkg=mutter&arch=mips&ver=3.22.2-1&stamp=1479018257 -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Re: Bug#844227: FTBFS on mips*, ./.libs/libmutter-cogl.so: undefined reference to `eglQueryString'
On 2016-11-13 17:14 +0100, Michael Biebl wrote: > Source: mutter > Version: 3.22.2-1 > Severity: serious > > The latest build of mutter failed on mips, mipsel and mips64el with > > ./.libs/libmutter-cogl.so: undefined reference to `eglQueryString' > ./.libs/libmutter-cogl.so: undefined reference to `eglTerminate' > collect2: error: ld returned 1 exit status > > This looks like a recent regression in either mutter or mesa, > mutter 3.22.1 built fine on those architectures. I had a look at the build log, and libmutter-cogl.so appears to have been linked with -lEGL as it's supposed to. Also, the two mentioned symbols are still present in libEGL.so, so there's no obvious mesa problem either. The toolchain has also changed quite a bit in the past four weeks, with gcc having pie enabled by default and binutils at a bleeding edge snapshot. Maybe one of those has triggered the build failure. Cheers, Sven
Re: Bug#844227: FTBFS on mips*, ./.libs/libmutter-cogl.so: undefined reference to `eglQueryString'
Am 13.11.2016 um 18:37 schrieb Sven Joachim: > The toolchain has also changed quite a bit in the past four weeks, with > gcc having pie enabled by default and binutils at a bleeding edge > snapshot. Maybe one of those has triggered the build failure. That might well be it. Currently mutter still builds fine in stretch. The new binutils should migrate to testing soon. I can then retry the build on a mips porter machine with 2.27.51.20161108-1 -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Bug#839381: xserver-xorg-video-amdgpu: very long Xorg initilization time in recent kernels
On 13/11/16 09:09 PM, Michael Strobel wrote: > Hi, > > i think i found the problem: it's powerplay. The bisection showed that > 3466904d38ff1e63f0a19cb31166db67f2d05c61 is the commit which introduced > the problem: > > while the code before checked if amdgpu_powerplay > 0 now it checks > equality. The default value is -1 so pp is enabled. I booted with > amdgpu.powerplay=0 and the problem is gone for the testing kernel 4.7. > > I tried a more recent kernel (4.9-rc5) and it seemed that it's not > checked anymore if amdgpu.powerplay equals 0. I'm adding a patch which > re enables the boot parameter. > > Furthermore i'm not sure what causes the problem with my GPU in the > first place. If there is anything i can do please let me know. Adding the amd-gfx mailing list to Cc. This bug report should be reassigned to the kernel package. > On 10/03/2016 04:45 AM, Michel Dänzer wrote: >> On 01/10/16 06:30 PM, Michael Strobel wrote: >>> Package: xserver-xorg-video-amdgpu >>> Version: 1.1.2-1 >>> Severity: normal >>> >>> Dear Maintainer, >>> >>> i'm running debian testing and for quite a while i have problems with my >>> xserver on newer kernels. While linux-image-4.2.0-1-amd64 works fine >>> linux-image-4.6.0-1-amd64 and linux-image-4.7.0-1-amd64 my xserver spends >>> very long time (several minutes) on initialization. >>> The only problem i can spot is a lot of >>> >>> Failed to send Previous Message. >>> Failed to send Message. >>> >>> messages in dmesg. I'm not complete sure if the problem is even xserver >> >> Yeah, unless this doesn't happen with an older version of >> xserver-xorg-video-amdgpu (and possibly related packages), it sounds >> like an amdgpu kernel driver regression. Any chance you can bisect or at >> least narrow down which kernel version introduced the problem? >> >> > -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Mesa and X developer signature.asc Description: OpenPGP digital signature
