You are not logged in.

Pages: 1

#1 2018-04-07 17:20:25

schmidtbag
Member
From: NH, USA
Registered: 2011-02-08
Posts: 337

Is Mesa 18.0.0 broken? SOLVED

So today, after I launched Steam, I updated Mesa from 17 to 18.  After doing so, I was unable to run any games.  At one point, I rebooted, only to find Steam won't start up, either.  In fact, nothing that depends on Mesa works - not even glxgears:

pp: Failed to translate a shader for depth1fs
pp: Failed to translate a shader for blend2fs
pp: Failed to translate a shader for color1fs
pp: Failed to translate a shader for blend2fs
glxgears: ../mesa-18.0.0/src/gallium/drivers/radeonsi/si_state_draw.c:1239: si_draw_vbo: Assertion `0' failed.
Aborted (core dumped)

Everything was working fine before this update.  I tried removing my xorg.conf, I double-checked that mkinitcpio has "radeon" in it, and I re-installed all Mesa packages, just to be safe.  I'm running an R9 290, and I don't have one of the models that has reclocking issues.

If I downgrade back to 17.3.7, everything works fine.

EDIT:
I'd like to point out that I didn't get any warnings or errors in the Xorg logs pertaining to the GPU, and glxinfo confirms my GPU's specs and Mesa version.

Last edited by schmidtbag (2018-04-08 17:21:41)

Offline

#2 2018-04-07 18:38:50

damjan
Member
Registered: 2006-05-30
Posts: 452

Re: Is Mesa 18.0.0 broken? SOLVED

glxgears works with intel, so it's not a general mesa failure. (and I use KDE with Kwin set for OpenGL 3.1, that works fine too)

Offline

#3 2018-04-07 19:05:30

R00KIE
Forum Fellow
From: Between a computer and a chair
Registered: 2008-09-14
Posts: 4,734

Re: Is Mesa 18.0.0 broken? SOLVED

Both glxgears and glmark2 work fine here with both intel and an amd oland card so not a generalized problem.

R00KIE
Tm90aGluZyB0byBzZWUgaGVyZSwgbW92ZSBhbG9uZy4K

Offline

#4 2018-04-07 23:17:17

schmidtbag
Member
From: NH, USA
Registered: 2011-02-08
Posts: 337

Re: Is Mesa 18.0.0 broken? SOLVED

damjan wrote:

glxgears works with intel, so it's not a general mesa failure. (and I use KDE with Kwin set for OpenGL 3.1, that works fine too)

I also have a Intel+KDE setup, with Mesa 18 and Wayland, and that also works.

But for my AMD setup it doesn't make sense - I'm using LXQt for that, but otherwise everything else is pretty much all defaults.  No special kernel paramters/builds and no weird config files.  Mesa 17 still works fine.  I don't understand what's wrong with Mesa 18.  The error output from glxgears is the most info I get.

Last edited by schmidtbag (2018-04-07 23:18:17)

Offline

#5 2018-04-07 23:19:25

loqs
Member
Registered: 2014-03-06
Posts: 17,414

Re: Is Mesa 18.0.0 broken? SOLVED

What is the backtrace from the coredump see `man coredumpctl` the info from the relevant coredump will include the backtrace.

Offline

#6 2018-04-07 23:30:54

schmidtbag
Member
From: NH, USA
Registered: 2011-02-08
Posts: 337

Re: Is Mesa 18.0.0 broken? SOLVED

This was for glxgears (I'm not 100% sure if this is the failed attempt to run it, but I'm pretty sure it is):

               Stack trace of thread 18242:
                #0  0x00007ffbcde7a860 raise (libc.so.6)
                #1  0x00007ffbcde7bec9 abort (libc.so.6)
                #2  0x00007ffbcde730bc __assert_fail_base (libc.so.6)
                #3  0x00007ffbcde73133 __assert_fail (libc.so.6)
                #4  0x00007ffbca3ec982 n/a (radeonsi_dri.so)
                #5  0x00007ffbcaa5e4f3 n/a (radeonsi_dri.so)
                #6  0x00007ffbcaa5b537 n/a (radeonsi_dri.so)
                #7  0x00007ffbca979a4a n/a (radeonsi_dri.so)
                #8  0x00007ffbca9795c8 n/a (radeonsi_dri.so)
                #9  0x00007ffbcd33208c start_thread (libpthread.so.0)
                #10 0x00007ffbcdf3be7f __clone (libc.so.6)
                
                Stack trace of thread 18235:
                #0  0x00007ffbcd3383bd pthread_cond_wait@@GLIBC_2.3.2 (libpthread.so.0)
                #1  0x00007ffbca979903 n/a (radeonsi_dri.so)
                #2  0x00007ffbca9795c8 n/a (radeonsi_dri.so)
                #3  0x00007ffbcd33208c start_thread (libpthread.so.0)
                #4  0x00007ffbcdf3be7f __clone (libc.so.6)

                Stack trace of thread 18239:
                #0  0x00007ffbcd3383bd pthread_cond_wait@@GLIBC_2.3.2 (libpthread.so.0)
                #1  0x00007ffbca979903 n/a (radeonsi_dri.so)
                #2  0x00007ffbca9795c8 n/a (radeonsi_dri.so)
                #3  0x00007ffbcd33208c start_thread (libpthread.so.0)
                #4  0x00007ffbcdf3be7f __clone (libc.so.6)
                
                Stack trace of thread 18240:
                #0  0x00007ffbcd3383bd pthread_cond_wait@@GLIBC_2.3.2 (libpthread.so.0)
                #1  0x00007ffbca979903 n/a (radeonsi_dri.so)
                #2  0x00007ffbca9795c8 n/a (radeonsi_dri.so)
                #3  0x00007ffbcd33208c start_thread (libpthread.so.0)
                #4  0x00007ffbcdf3be7f __clone (libc.so.6)

                Stack trace of thread 18234:
                #0  0x00007ffbcdf36879 syscall (libc.so.6)
                #1  0x00007ffbca97956f n/a (radeonsi_dri.so)
                #2  0x00007ffbcaa5c2f4 n/a (radeonsi_dri.so)
                #3  0x00007ffbcaa5c9d8 n/a (radeonsi_dri.so)
                #4  0x00007ffbca6c809c n/a (radeonsi_dri.so)
                #5  0x00007ffbca23926e n/a (radeonsi_dri.so)
                #6  0x00007ffbccad9203 glPrimitiveBoundingBox (libGLX_mesa.so.0)
                #7  0x000056280e057a27 n/a (glxgears)
                #8  0x00007ffbcde66f4a __libc_start_main (libc.so.6)
                #9  0x000056280e05808a n/a (glxgears)
                
                Stack trace of thread 18241:
                #0  0x00007ffbcd3383bd pthread_cond_wait@@GLIBC_2.3.2 (libpthread.so.0)
                #1  0x00007ffbca979903 n/a (radeonsi_dri.so)
                #2  0x00007ffbca9795c8 n/a (radeonsi_dri.so)
                #3  0x00007ffbcd33208c start_thread (libpthread.so.0)
                #4  0x00007ffbcdf3be7f __clone (libc.so.6)
                
                Stack trace of thread 18237:
                #0  0x00007ffbcd3383bd pthread_cond_wait@@GLIBC_2.3.2 (libpthread.so.0)
                #1  0x00007ffbca979903 n/a (radeonsi_dri.so)
                #2  0x00007ffbca9795c8 n/a (radeonsi_dri.so)
                #3  0x00007ffbcd33208c start_thread (libpthread.so.0)
                #4  0x00007ffbcdf3be7f __clone (libc.so.6)

                Stack trace of thread 18238:
                #0  0x00007ffbcd3383bd pthread_cond_wait@@GLIBC_2.3.2 (libpthread.so.0)
                #1  0x00007ffbca979903 n/a (radeonsi_dri.so)
                #2  0x00007ffbca9795c8 n/a (radeonsi_dri.so)
                #3  0x00007ffbcd33208c start_thread (libpthread.so.0)
                #4  0x00007ffbcdf3be7f __clone (libc.so.6)
                
                Stack trace of thread 18236:
                #0  0x00007ffbcd3383bd pthread_cond_wait@@GLIBC_2.3.2 (libpthread.so.0)
                #1  0x00007ffbca979903 n/a (radeonsi_dri.so)
                #2  0x00007ffbca9795c8 n/a (radeonsi_dri.so)
                #3  0x00007ffbcd33208c start_thread (libpthread.so.0)
                #4  0x00007ffbcdf3be7f __clone (libc.so.6)

I've also noticed that if I run glxgears with Mesa 17, those 4 lines starting with "pp:" still show up, so, I'm not sure they're related to my problem.

Last edited by schmidtbag (2018-04-07 23:33:27)

Offline

#7 2018-04-07 23:43:58

loqs
Member
Registered: 2014-03-06
Posts: 17,414

Re: Is Mesa 18.0.0 broken? SOLVED

Unfortunately mesa has not been built with debug info removing a lot of the value of the backtrace.  Could you try rebuilding mesa Debug_-_Getting_Traces

Offline

#8 2018-04-08 09:40:56

R00KIE
Forum Fellow
From: Between a computer and a chair
Registered: 2008-09-14
Posts: 4,734

Re: Is Mesa 18.0.0 broken? SOLVED

One thing to look at is the kernel driver, for me the default is still radeon but for you I suspect it is amdgpu, it might be a red herring but it doesn't hurt to give linux-lts a try and see if anything changes.

R00KIE
Tm90aGluZyB0byBzZWUgaGVyZSwgbW92ZSBhbG9uZy4K

Offline

#9 2018-04-08 10:42:15

lo1
Member
Registered: 2017-09-25
Posts: 584

Re: Is Mesa 18.0.0 broken? SOLVED

Mmh I am experiencing problems here too, and downgrading of course is helpful. Posting some thumbs since I have no idea on how to describe this issue nor how to help you debug (of course I'm willing to help if you tell me what I should provide).

The first one with mesa and mesa-vdpau both at 17.3.7, nothing else has been modified.

Ex4NZmE.png
iMD5JSx.png

[angelo@Arch ~]$ pacman -Q | grep mesa
libva-mesa-driver 18.0.0-2
mesa 18.0.0-2
mesa-demos 8.4.0-1
mesa-vdpau 18.0.0-2
[angelo@Arch ~]$ cat /proc/cmdline 
BOOT_IMAGE=/boot/vmlinuz-linux root=UUID=96e76026-de71-4618-b166-cf5b60ce8352 rw rootflags=rw,noatime,data=ordered quiet udev.log_priority=3 rd.udev.log_priority=3 loglevel=3 ipv6.disable_ipv6=1
[angelo@Arch ~]$ uname -a
Linux Arch 4.15.15-1-ARCH #1 SMP PREEMPT Sat Mar 31 23:59:25 UTC 2018 x86_64 GNU/Linux

Xorg log here

How To Ask Questions The Smart Way && Tacts Filters && K.I.S.S. &&
Rootless Root

Offline

#10 2018-04-08 11:32:52

Gigamo
Member
Registered: 2008-01-19
Posts: 394

Re: Is Mesa 18.0.0 broken? SOLVED

lo1 wrote:

Mmh I am experiencing problems here too, and downgrading of course is helpful. Posting some thumbs since I have no idea on how to describe this issue nor how to help you debug (of course I'm willing to help if you tell me what I should provide).

The first one with mesa and mesa-vdpau both at 17.3.7, nothing else has been modified.

https://i.imgur.com/Ex4NZmE.png
https://i.imgur.com/iMD5JSx.png

[angelo@Arch ~]$ pacman -Q | grep mesa
libva-mesa-driver 18.0.0-2
mesa 18.0.0-2
mesa-demos 8.4.0-1
mesa-vdpau 18.0.0-2
[angelo@Arch ~]$ cat /proc/cmdline 
BOOT_IMAGE=/boot/vmlinuz-linux root=UUID=96e76026-de71-4618-b166-cf5b60ce8352 rw rootflags=rw,noatime,data=ordered quiet udev.log_priority=3 rd.udev.log_priority=3 loglevel=3 ipv6.disable_ipv6=1
[angelo@Arch ~]$ uname -a
Linux Arch 4.15.15-1-ARCH #1 SMP PREEMPT Sat Mar 31 23:59:25 UTC 2018 x86_64 GNU/Linux

Xorg log here

If using compton, you can try adding

<application name="compton" executable="compton">
    <option name="allow_rgb10_configs" value="false"/>
</application>

to your /etc/drirc, as per https://bugs.freedesktop.org/show_bug.cgi?id=104597

Offline

#11 2018-04-08 15:31:52

schmidtbag
Member
From: NH, USA
Registered: 2011-02-08
Posts: 337

Re: Is Mesa 18.0.0 broken? SOLVED

loqs wrote:

Unfortunately mesa has not been built with debug info removing a lot of the value of the backtrace.  Could you try rebuilding mesa Debug_-_Getting_Traces

I'm not sure I totally understand what I'm supposed to do for that.  I'm not sure where to get the 18.0.0-2 source pkgbuild.  What I can get is mesa-git from the AUR, but it's a different version.  That being said, I wanted to see if the git version has the same problem, so I tried to build and install that.  Unfortunately, after taking nearly a full hour to compile everything, it failed.  I don't remember what the error was, but at this rate I don't feel like adding a debugger to something that also needs debugging, especially if it takes this long for it to point out a problem.

R00KIE wrote:

One thing to look at is the kernel driver, for me the default is still radeon but for you I suspect it is amdgpu, it might be a red herring but it doesn't hurt to give linux-lts a try and see if anything changes.

Good idea, though according to the Xorg.log, radeonsi is in use; not amdgpu.  Also, I don't have amdgpu in mkinitcpio.conf, if that makes a difference.


EDIT:
I tried adding the mesa-git repo to my pacman.conf.  That comes with mesa 18.1.0, and that seems to work just fine.  It also removes those "pp" errors I get.

Last edited by schmidtbag (2018-04-08 15:38:38)

Offline

#12 2018-04-08 15:43:32

lo1
Member
Registered: 2017-09-25
Posts: 584

Re: Is Mesa 18.0.0 broken? SOLVED

Gigamo wrote:

If using compton, you can try adding

<application name="compton" executable="compton">
    <option name="allow_rgb10_configs" value="false"/>
</application>

to your /etc/drirc, as per https://bugs.freedesktop.org/show_bug.cgi?id=104597

That works fine, I didn't even know that compton was to blame for this so I didn't bother including the keyword "compton" in my search. Thanks!

What does the "allow_rgb10_configs" actually do? https://lists.freedesktop.org/archives/ … 68492.html
search-fu is working fine.

Last edited by lo1 (2018-04-08 17:34:05)

How To Ask Questions The Smart Way && Tacts Filters && K.I.S.S. &&
Rootless Root

Offline

#13 2018-04-08 16:10:57

Lone_Wolf
Forum Moderator
From: Netherlands, Europe
Registered: 2005-10-04
Posts: 11,952

Re: Is Mesa 18.0.0 broken? SOLVED

Looks more like search-fu is broken.

The pp failed shader is an ancient problem : https://bugs.freedesktop.org/show_bug.cgi?id=99549

Disliking systemd intensely, but not satisfied with alternatives so focusing on taming systemd.


(A works at time B)  && (time C > time B ) ≠  (A works at time C)

Offline

#14 2018-04-08 16:37:25

loqs
Member
Registered: 2014-03-06
Posts: 17,414

Re: Is Mesa 18.0.0 broken? SOLVED

@Lone_Wolf would the core dump be separate to the pp failed shader issue?

Offline

#15 2018-04-08 16:56:33

Lone_Wolf
Forum Moderator
From: Netherlands, Europe
Registered: 2005-10-04
Posts: 11,952

Re: Is Mesa 18.0.0 broken? SOLVED

I expect they are  not related, but this thread is to general and hard to get necessary info from.

Schmidtbag, if you want get help with running mesa 18 from extra, i suggest you start a new thread.

add glxinfo output, full lspci -k, xorg log, dmesg and journal .

Disliking systemd intensely, but not satisfied with alternatives so focusing on taming systemd.


(A works at time B)  && (time C > time B ) ≠  (A works at time C)

Offline

#16 2018-04-08 17:02:57

schmidtbag
Member
From: NH, USA
Registered: 2011-02-08
Posts: 337

Re: Is Mesa 18.0.0 broken? SOLVED

Lone_Wolf wrote:

I expect they are  not related, but this thread is to general and hard to get necessary info from.

Schmidtbag, if you want get help with running mesa 18 from extra, i suggest you start a new thread.

add glxinfo output, full lspci -k, xorg log, dmesg and journal .

Well, at this rate since mesa-git works fine, I'm not sure how much I really care to continue to pursue this, unless someone else is also getting these problems (it seems lo1 is all set).  Besides, I don't know what I could say in a new thread that I hadn't already said here, other than the outputs you requested.

Offline

#17 2018-04-08 17:20:14

loqs
Member
Registered: 2014-03-06
Posts: 17,414

Re: Is Mesa 18.0.0 broken? SOLVED

It could be already fixed in git or the different build system mesa-git still use autotools and the repo package uses meson/ninja.
If you no longer wish to pursue this thread could you please either mark it as solved or use the report button to contact the moderators to delete the thread as abandonned.
Edit:

lo1 wrote:

What does the "allow_rgb10_configs" actually do?

https://bugs.freedesktop.org/show_bug.cgi?id=104597

Last edited by loqs (2018-04-08 17:33:28)

Offline

#18 2018-04-08 17:43:19

lo1
Member
Registered: 2017-09-25
Posts: 584

Re: Is Mesa 18.0.0 broken? SOLVED

Thanks loqs, actually I was reading this for a more explanatory answer:

this patch series adds support to the i965 classic Mesa driver for
ARGB2101010 and XRGB2101010 fbconfigs/visuals for X11/GLX, X11/EGL
and Wayland/EGL, and for rendering into those winsys framebuffers
with 10 bpc precision.

How To Ask Questions The Smart Way && Tacts Filters && K.I.S.S. &&
Rootless Root

Offline

#19 2018-04-08 17:53:33

loqs
Member
Registered: 2014-03-06
Posts: 17,414

Re: Is Mesa 18.0.0 broken? SOLVED

@lo1 so the issue for your system would seem assuming mesa is correctly rendering 10bpp that something else in the stack is not handling it correctly (probably dropping 2 of the bits down to 8bpp) hence the odd color rendition.

Offline

#20 2018-04-08 18:17:04

lo1
Member
Registered: 2017-09-25
Posts: 584

Re: Is Mesa 18.0.0 broken? SOLVED

loqs wrote:

@lo1 so the issue for your system would seem assuming mesa is correctly rendering 10bpp that something else in the stack is not handling it correctly (probably dropping 2 of the bits down to 8bpp) hence the odd color rendition.

Honestly, I have no idea. If anyone thinks I didn't hijack OP's thread and wants some closure about this issue, be my guest:

journal https://ptpb.pw/p4Bh
dmesg https://ptpb.pw/Wqbf
lspci -k https://ptpb.pw/TIhw
glxinfo https://ptpb.pw/p6_U

Notice that the following have been annoying me since linux 4.15.4 but *shouldn't* be a problem (never experienced issue excluding this mesa thing).

apr 08 19:19:01 Arch kernel: do_IRQ: 1.55 No irq handler for vector
apr 08 19:19:01 Arch kernel: do_IRQ: 2.55 No irq handler for vector
apr 08 19:19:01 Arch kernel: do_IRQ: 3.55 No irq handler for vector

How To Ask Questions The Smart Way && Tacts Filters && K.I.S.S. &&
Rootless Root

Offline

Pages: 1

Board footer

Powered by FluxBB