Created attachment 11226 [details]
Output of xdpyinfo

Created attachment 11227 [details]
Extracted lines from boot journal

Searched for lines containing GL and GLX.

Created attachment 11228 [details]
Boot journal for testing session

Attachment 11227 is obsolete: 0 => 1

The test was run with NVIDIA graphics: NVIDIA GP102 [GeForce GTX 1080 Ti]
driver: nvidia v: 430.26

Works with Intel hw:

$ glmark2
=======================================================
    glmark2 2017.07
=======================================================
    OpenGL Information
    GL_VENDOR:     Intel Open Source Technology Center
    GL_RENDERER:   Mesa DRI Intel(R) HD Graphics 620 (Kaby Lake GT2) 
    GL_VERSION:    3.0 Mesa 19.1.3
=======================================================
[build] use-vbo=false: FPS: 2809 FrameTime: 0.356 ms
=======================================================
                                  glmark2 Score: 2809 
=======================================================

CC: (none) => tmb

*** Bug 25203 has been marked as a duplicate of this bug. ***

I will try this on different desktops (Radeon video).

CC: (none) => lewyssmith

AMD/ATI/Radeon HD7310 graphics x64
Glmark2 ran OK under all 6 desktops. This looks like another nVidia problem...

@Thomas : thanks for your test.

@Len
When I installed glmark2, it gave an odd choice for an additional dependancy. One (that I chose) was a lib64pngsomething; the other was 'nvidia-nightsomething'.
 $ urpmq --requires
includes what might be the addition
 libpng12.so.0()(64bit)
Can you see which one you have? And ask in QA for other nVidia feedback on this?

Summary: glmark2 fails to run on Mageia 7 => glmark2 fails to run with nVidia on Mageia 7

With nvidia 430.40 glmark2 works on the GTX 1080 Ti

@Lewis
libpng12 comes up in the requires list and /usr/lib64/libpng12.so.0 exists.

Cannot find any file whose name includes 'nvidia' and 'night'.  You might have seen 'nvidia-nsight'.  That shows up in the --requires-recursive list but I cannot locate it here.  The exact entries are:
lib64jpeg8|nvidia-nsight
lib64png12_0|nvidia-nsight

I don't know what that nomenclature means.

> You might have seen 'nvidia-nsight'
That was it. I was just probing to see whether you had it and whether it might be the reason fo the failure. Not so.

> lib64png12_0|nvidia-nsight
> I don't know what that nomenclature means
Just one or the other, I imagine.

> And ask in QA for other nVidia feedback on this
Reminder, please.
From your comment 9, this clearly needs narrowing down. QA's various nVidia users seem the best route: qa-discuss (I am not on it any more).

Summary: glmark2 fails to run with nVidia on Mageia 7 => glmark2 fails to run with some nVidia on Mageia 7

Created attachment 11267 [details]
strace output for glmark2

Mageia 7
graphics driver nvidia 430.26
GeForce GTX 1080 Ti

glmark2 failed after upgrading from kernel 5.2.7 to 5.2.10 in Mageia 7.
Ran strace to provide attached file.

> glmark2 failed after upgrading from kernel 5.2.7 to 5.2.10 in Mageia 7.
I await the newer kernel to try this.

(In reply to Len Lawrence from comment #9)
> With nvidia 430.40 glmark2 works on the GTX 1080 Ti
I had not noticed that this relates to just a more recent driver! Is that now the current Mageia one? If so, the bug was resolved/fixed at that point.
If not, where did you get it?
However, your new comment 12 still relates to the older driver 'nvidia 430.26'.

Reminder: the hardware is NVIDIA GP102 [GeForce GTX 1080 Ti]

Another thing to try, if you can: what happens with nouveau?

Assignee: bugsquad => kernel

In reply to Lewis comment 14:

I had not noticed the driver version either.  I'll see if nvidia-current  works better.  Cannot remember anything about the previous circumstances - I might have been testing nvidia-current on one of the other mga7 installations or it could have been mga6.  impossible to tell now.

Yes, it was foolish of me not to try glmark2 when nouveau came up - I was just too anxious to get nvidia back.  Shall poke around.

Following on from comment 15, after installation of dkms-nvidia-current and a reboot the picture did not change - glmark2 still failed to launch.

Curiouser and curiouser...

Tried a series of experiments on another partition for the hardware used for the test referred to in comment 13.
NVIDIA GP102 [GeForce GTX 1080 Ti]

nvidia 430.26 :: 5.1.18-desktop-1.mga7      glmark2 OK
nvidia 430.26 :: 5.1.14-desktop-1.mga7      glmark2 OK

Updated kernel from testing.
nvidia 430.26 :: 5.2.10-desktop-1.mga7      glmark2 OK
This was the point at which glmark2 failed on the other partition.
Updated nvidia-current.

nvidia 430.40 :: 5.2.10-desktop-1.mga7      glmark2 OK

So the bug has vanished as far as this partition is concerned.

Continuing from comment 17:
One last chance - clutching at straws.

Updated microcode to version 0.20190618
Rebooted
glmark2 still launches.

I wonder whether the new bug 25555 (GeForce 750Ti GPU) is the same problem, potentially a duplicate of this one.

Thanks Lewis.  Had a look at bug 25555 which throws some light on the problem.  The reason stellarium and other GL applications work would seem to be because they do not require the libEGL library.  Also there is a direct soft link to the nvidia version of the libOpenGL library.  Tried unlinking libEGL.so.1 but that did not help so replaced the link by a soft link to the nvidia-current version but that did not help either.
# ll libEGL.so.1
lrwxrwxrwx 1 root root 37 Oct 14 17:14 libEGL.so.1 -> /usr/lib64/nvidia-current/libEGL.so.1*

Tried this also:
# unlink libEGL.so
# ln -s /usr/lib64/nvidia-current/libEGL.so.1 libEGL.so
Still no luck with glmark2, nvidia 430.50.

Looked at libGL as well.
One thing to note is that there are GLX libraries in the nvidia-current directory which as far as I can see are not accessed by glmark2, at least directly.
$ grep -i glx glmark2-trace
openat(AT_FDCWD, "/lib64/libxcb-glx.so.0", O_RDONLY|O_CLOEXEC) = 4
writev(3, [{iov_base="b\0\3\0\3\0\0\0", iov_len=8}, {iov_base="GLX", iov_len=3}, {iov_base="\0", iov_len=1}], 3) = 12
writev(3, [{iov_base="b\0\3\0\3\0\0\0GLX\0", iov_len=12}], 1) = 12
write(2, "X Error of failed request:  GLXB"..., 44) = 44
write(2, " (GLX)\n", 7)                 = 7
write(2, " (X_GLXIsDirect)", 16)        = 16

The point to remember is that the same version of glmark2 does run on other nvidia hardware with the same kernel.  It may have worked in earlier versions on the machines where it now fails.  Baffling.

Hello Len, just poking this.

From comment 17:
> Tried a series of experiments on another partition for the hardware used
> for the test referred to in comment 13.
> NVIDIA GP102 [GeForce GTX 1080 Ti]
> bug has vanished as far as this partition is concerned
I am curious about this other partition: is it just another Mageia 7 installation?
Are you saying you have, with the same:
- video hardware
- driver
- kernel
one Mageia 7 system where glmark2 fails and one where it works?

it seems it fails on nvidia and works on intel. BTW, on cauldron I just uploaded glmark2-202004, it can be easily recompiled on mga7. Is this version showing the same problems?

Yes, it works with nouveau reliably as well AFAICT.

In reply to Lewis, comment 21:

Oops sent my reply to the list instead of the bug - this has been a very bad day so far.

Yes the two partitions on the one machine would both have been Mageia7.  It is too far back in time to remember any of the details now.  It has been impossible to isolate common factors. Sometimes it works on  two machines and not a third.  Sometime it fails on one partition but works on another partition on the same machine and sometime later the case reverses.  Sometimes the kernels are different, sometimes not.

The variables are the kernel, the version of Mageia, the partition, a re-installation, the package manifest, the version of the nvidia driver....  How many permutations can one find there? As far as I can tell success or failure is independent of which desktop is chosen.

Anyway, I have lost interest in the case.  If it works, fine - if not, life is too short, or as they might say in Glasgow: "Och man, ah'm scunnered wi'it!".

Further to that:

It is currently failing in mga8 as well.

$ glmark2
libGL error: No matching fbConfigs or visuals found
libGL error: failed to load driver: swrast
X Error of failed request:  GLXBadContext
  Major opcode of failed request:  150 (GLX)
  Minor opcode of failed request:  6 (X_GLXIsDirect)
  Serial number of failed request:  44
  Current serial number in output stream:  43
$ locate swrast
/usr/lib64/dri/kms_swrast_dri.so
/usr/lib64/dri/swrast_dri.so
/usr/lib64/gallium-pipe/pipe_swrast.so
$ uname -r
5.6.11-desktop-1.mga8

Switched to mga7 on this same machine and glmark2 is running.
$ uname -r
5.5.15-desktop-3.mga7
$ locate swrast
/usr/lib64/dri/kms_swrast_dri.so
/usr/lib64/dri/swrast_dri.so
/usr/lib64/gallium-pipe/pipe_swrast.so

Tried another partition on the same machine:
$ uname -r
5.6.8-desktop-1.mga7
glmark2 is running.

Same machine, yet another partition, nvidia graphics - glmark2 fails.
$ uname -r
5.5.9-desktop-1.mga7
$ ll `locate swrast`
lrwxrwxrwx 1 lcl  lcl        27 May  9 22:39 /home/lcl/.#swrast -> 'lcl@canopus.8769:1589060221'
-rwxr-xr-x 9 root root 20087280 Mar  6 17:49 /usr/lib64/dri/kms_swrast_dri.so*
-rwxr-xr-x 9 root root 20087280 Mar  6 17:49 /usr/lib64/dri/swrast_dri.so*
-rwxr-xr-x 1 root root  4150936 Mar  6 17:49 /usr/lib64/gallium-pipe/pipe_swrast.so*

The symbolic link is flashing red which means something is wrong.
unlink'd it and ran glmark2, which still failed.  The softlink did not reappear.
So no help there.

More observations.

libGL error: No matching fbConfigs or visuals found
libGL error: failed to load driver: swrast

swrast has been compiled in all cases but in some it fails to load.
That message comes right after a reference to something to do with the framebuffer.  glmark2 has been tested under many levels of CPU and GPU loading from very busy to almost idling so it does not look like a resources problem.

The last partition upon which glmark2 was tested has just received a large update, some 240 packages including kernel-desktop-5.6.8.
After reboot glmark2 still fails.

The next step would be to try Giuseppe's comment 22 version, but:
$ mgarepo co -d 8 glmark2
Using the svn mirror.
svn: E170000: URL 'svn://svn.mageia.org/svn/packages/updates/8/glmark2/current' doesn't exist
$ mgarepo co -d 8 glmark2-202004
Using the svn mirror.
svn: E170000: URL 'svn://svn.mageia.org/svn/packages/updates/8/glmark2-202004/current' doesn't exist

Just to confirm that the build system was working I checked out the current version in mga7, ran buildrequires after 'bm -ls' and then successfully rebuilt glmark2 and installed it.  So, no problem with the mechanism.  There must be some trick to finding the mga8 version Giuseppe refers to.

(In reply to Len Lawrence from comment #28)
> Just to confirm that the build system was working I checked out the current
> version in mga7, ran buildrequires after 'bm -ls' and then successfully
> rebuilt glmark2 and installed it.  So, no problem with the mechanism.  There
> must be some trick to finding the mga8 version Giuseppe refers to.

Cauldron is upcoming "mga8",

so basically mgarepo co glmark2

the "svn://svn.mageia.org/svn/packages/updates/8" only get created when we actually release Mga 8 and fork svn

mgarepo co svn://svn.mageia.org/svn/packages/cauldron/glmark2/current will bring you the current 2020.04 version.

(In reply to Giuseppe Ghibò from comment #30)
> mgarepo co svn://svn.mageia.org/svn/packages/cauldron/glmark2/current will
> bring you the current 2020.04 version.

That is the exact same as the way shorter:

mgarepo co glmark2

Replying to comments 29 and 30.
Yes, that works a treat.  Thanks amici.

$ mgarepo co glmark2
$ cd glmark2
$ sudo urpmi --buildrequires SPECS/glmark2.spec
To satisfy dependencies, the following packages are going to be installed:
  Package                        Version      Release       Arch    
(medium "Core Release")
  waf                            2.0.16       1.mga7        noarch  
  waf-doc                        2.0.16       1.mga7        noarch  (recommended)
$ bm -ls
Wrote: /home/lcl/glmark2/SRPMS/glmark2-2020.04-1.20200503.mga7.src.rpm
$ bm -l
succeeded!
$ cd RPMS/x86_64
$ sudo rpm -U glmark2-2020.04-1.20200503.mga7.x86_64.rpm
$ rpm -q glmark2
glmark2-2020.04-1.20200503.mga7
$ glmark2
libGL error: No matching fbConfigs or visuals found
libGL error: failed to load driver: swrast
X Error of failed request:  GLXBadContext
  Major opcode of failed request:  150 (GLX)
  Minor opcode of failed request:  6 (X_GLXIsDirect)
  Serial number of failed request:  44
  Current serial number in output stream:  43

So, the problem is still there.

what is the output of glxinfo?

Created attachment 11632 [details]
Output of glxinfo for mga7.

And the output of "glxinfo -v -s -l" ?

Created attachment 11633 [details]
Verbose output from glxinfo where glmark2 fails

$ glxinfo -v -s -l > glmark2fail.info

@Giuseppe: comment 36
When I can find time I shall try a diff between the good and the bad systems.

Another partition on the machine where glmark2 fails.
glmark2 2017 runs.
Installed the newly built version.
glmark2 2020 runs OK as well.  So maybe I should diff glxinfo between these two mga7 partitions as well....

$ diff glmark2_sda5.info glmark2_sda7_bad.info 
106c106
<     Currently available dedicated video memory: 10947 MB
---
>     Currently available dedicated video memory: 10959 MB

So no evident difference between two partitions on the same machine, same versions of glmark2 - runs fine on one but not the other.

same xorg.conf?

Yep.

$ diff xorg_sda7.conf xorg_sda5.conf
$

same /var/log/Xorg.0.log (apart memory pointers)?

/dev/sda5, glmark2 runs

$ ll Xorg.0.log
-rw-r--r-- 1 root gdm 28402 May 10 12:42 Xorg.0.log

Made a user copy and switched to the other partition.

/dev/sda7, glmark2 fails

Made a user copy of the log.

$ ll *.log
-rw-r--r-- 1 lcl lcl 28402 May 10 12:52 Xorg_sda5.0.log
-rw-r--r-- 1 lcl lcl 28402 May 10 12:57 Xorg_sda7.0.log

diffing these is pointless because the timestamps have to differ.
The size match could be indicative of no fundamental difference.
Anything in particular to look for?

$ diff *.log | grep "<" | wc -l
432
$ diff *.log | grep ">" | wc -l
435

$ lines Xorg_sda7.0.log
442
$ lines Xorg_sda5.0.log
442

skip the timestamp before diffing, e.g. with cat Xorg.0.log | cut -c 14- > Xorg_nots.0.log

Thanks.  That's handy - never used 'cut' before.
Back later - on my lunch break just now - first chance to eat today.

Created attachment 11634 [details]
Differences between Xorg.0.log files on different partitions

$ cat Xorg_sda7.0.log | cut -c 14- > Xorg7.log
$ cat Xorg_sda5.0.log | cut -c 14- > Xorg5.log
$ diff Xorg7.log Xorg5.log > differences

Admitting there aren't corrupted libraries or libraries installed by some external installer beyond rpm (you could rpm -Va once maybe in the first case), 
the only difference I see from the file is the different order of the options
"nokmsboot splash quiet noiswmd" in one boot and "splash quiet noiswmd nokmsboot" in the second one, which corresponds to what you have defined in 
GRUB_CMDLINE_LINUX_DEFAULT="..." in /etc/default/grub. I would try to remove both noiswmd nokmsboot in both the partitions, regenrate the grub.cfg with grub2-mkconfig, at least to sync, and see what happens.

Had a go at this, starting with the sda7 partition where glmark2 fails.  Edited the default grub in /etc/default, removing the nokmsboot and noiswmd options and regenerated the grub menu and rebooted.  No change.  It looked like the grub alterations had not made it into /boot so rebooted and edited the kernel entry on the fly.  Removing nokmsboot killed nvidia completely and the system did not revert to nouveau either so I had to crash reboot.  I think I am out of my depth with this.  Retiring from the field before I do real damage.

(In reply to Len Lawrence from comment #51)
> Retiring from the field before I do real damage.
Yes! To yourself or your systems? Sorry I poked you about this. It is more an academic than real problem.

@Giuseppe : thanks for your helpful comments.

@Lewis
No need to apologize.  It has been an interesting side trip.
One of the experiments resulted in a a grub prompt at reboot which was difficult to get past.  Rescue and reinstall bootloader did not work but a null upgrade did.  Maybe comparing gdb runs might yield some information.  Not now though.

Experimenting on a Mageia 7.1 installation where glmark2 failed to run I tried installing nvidia-current-devel and then restarting glmark2.  It worked!

This still strikes me as being a bit anomalous though unless glmark2 was never intended to be a user tool.

glmark2 should normally work without devel stuff.

maybe we have packaged some lib in wrong rpm

There was a bug in glmark2 that lookups in libGL*.so libraries before libGL*.so.<version>; it has been fixed already in cauldron, but not in mga7.1.

 
ah, that would explain it

I'm seeing a failure of glmark2 on an Intel-based mga8 Plasma system. The hardware is a Probook 6550b, with an i3 M350 and integrated Intel i915 graphics. When I run glmark2 from the command line, both before and after installing the mesa update of bug 28666, I see the following:

=======================================================
    glmark2 2020.04
=======================================================
    OpenGL Information
    GL_VENDOR:     Intel Open Source Technology Center
    GL_RENDERER:   Mesa DRI Intel(R) HD Graphics (ILK)
    GL_VERSION:    2.1 Mesa 21.0.1
=======================================================
[build] use-vbo=false: FPS: 254 FrameTime: 3.937 ms
[build] use-vbo=true: FPS: 256 FrameTime: 3.906 ms
[texture] texture-filter=nearest: FPS: 264 FrameTime: 3.788 ms
[texture] texture-filter=linear: FPS: 261 FrameTime: 3.831 ms
Segmentation fault (core dumped)

it DOES work, both before and after the mesa update, on newer processor/graphics hardware, namely an i5 2500, also with i915 graphics. When I run it on that hardware, I see this:

=======================================================
    glmark2 2020.04
=======================================================
    OpenGL Information
    GL_VENDOR:     Intel Open Source Technology Center
    GL_RENDERER:   Mesa DRI Intel(R) HD Graphics 2000 (SNB GT1)
    GL_VERSION:    3.0 Mesa 21.0.1
=======================================================
[build] use-vbo=false: FPS: 1600 FrameTime: 0.625 ms
[build] use-vbo=true: FPS: 1122 FrameTime: 0.891 ms
[texture] texture-filter=nearest: FPS: 1055 FrameTime: 0.948 ms
[texture] texture-filter=linear: FPS: 1051 FrameTime: 0.951 ms
[texture] texture-filter=mipmap: FPS: 1053 FrameTime: 0.950 ms

and it goes on to finish the session. Note that there are differences in the GL_RENDERER and GL_VERSION between the systems.

I have also run glmark2 in mga8 on a system with a Core2Quad and AMD HD 8570 graphics with no problems. In fact, the performance of that system was reported as better than the Intel system. I did notice that that system was using a GL_VERSION of 4.something, so that probably made the difference.

CC: (none) => andrewsfarm

Seeing the same thing on the Probook in mga7 Plasma:

=======================================================
    glmark2 2017.07
=======================================================
    OpenGL Information
    GL_VENDOR:     Intel Open Source Technology Center
    GL_RENDERER:   Mesa DRI Intel(R) HD Graphics (ILK)
    GL_VERSION:    2.1 Mesa 20.2.3
=======================================================
[build] use-vbo=false: FPS: 251 FrameTime: 3.984 ms
[build] use-vbo=true: FPS: 254 FrameTime: 3.937 ms
[texture] texture-filter=nearest: FPS: 262 FrameTime: 3.817 ms
[texture] texture-filter=linear: FPS: 260 FrameTime: 3.846 ms
Segmentation fault (core dumped)

Mageia 7 is EOL since July 1st 2021.
There will not have any further bugfix for this release.

You are encouraged to upgrade to Mageia 8 as soon as possible.

@reporter, if this bug still apply with Mageia 8, please let us know it.

@packager, if you work on the Mageia 7 version of your package, please check the Mageia 8 package if issue is also present. In this case, please fix the Mageia 8 version instead.

This bug report will be closed OLD if there is no further notice within 1st September 2021.

Still valid in Mageia 8 on my HP Probook 6550b. This is the report I get in Konsole if I attempt to run glmark2:

=======================================================
    glmark2 2020.04
=======================================================
    OpenGL Information
    GL_VENDOR:     Intel Open Source Technology Center
    GL_RENDERER:   Mesa DRI Intel(R) HD Graphics (ILK)
    GL_VERSION:    2.1 Mesa 21.1.3
=======================================================
[build] use-vbo=false: FPS: 253 FrameTime: 3.953 ms
[build] use-vbo=true: FPS: 255 FrameTime: 3.922 ms
[texture] texture-filter=nearest: FPS: 264 FrameTime: 3.788 ms
[texture] texture-filter=linear: FPS: 262 FrameTime: 3.817 ms
Segmentation fault (core dumped)

Changing this to a Mageia 8 bug.

Version: 7 => 8
Whiteboard: MGA8TOO => (none)

Changing the summary to reflect that the bug now refers to Mageia 8, and that older Intel systems are also affected. 

I cannot say whether nvidia is still affected, as I no longer use any nvidia gpus. It would be a good idea for those with nvidia gpus that were affected by the Mageia 7 bug try again with the Mageia 8 glmark2 to see if they are still affected.

Summary: glmark2 fails to run with some nVidia on Mageia 7 => glmark2 fails to run with some nVidia and older Intel on Mageia 8

Interesting tidbit of information:

While testing the mesa update in Bug 29504, I once again tried glmark2 and once again it segfaulted. However, on the same physical hardware in a VirtualBOx guest, it did not crash. 

The GL_version reported in the Probook was again 2.1, but the one in the Vbox guest was 3.1.

Update: Glmark2 no longer fails on my Probook 6550b, now using Mageia 9.

Mageia 8 is soon End Of Life, https://blog.mageia.org/en/2023/12/30/mageia-8-end-of-life/
This one might be closed?

CC: (none) => micheelsen

(In reply to Hans Micheelsen from comment #65)
> Mageia 8 is soon End Of Life,
> https://blog.mageia.org/en/2023/12/30/mageia-8-end-of-life/
> This one might be closed?

Yes, thanks.

Resolution: (none) => OLD
Status: NEW => RESOLVED