Upgrade OpenGL drivers on linux test machines

RESOLVED WONTFIX

Status

P3
normal
RESOLVED WONTFIX
7 years ago
5 months ago

People

(Reporter: mattwoodrow, Unassigned)

Tracking

(Depends on: 18 bugs)

Details

(Whiteboard: [refplatform][puppet])

Attachments

(1 attachment, 1 obsolete attachment)

(Reporter)

Description

7 years ago
The current OpenGL drivers (nvidia 190.42) on the linux machines is really old and I believe it's causing bugs with OpenGL layers that aren't present on newer drivers.

I'm not sure what version we need exactly, I haven't been able to reproduce problems with 275.19. Preferably as new as possible :)

We're currently blacklisting anything before 257.21 (bar an exception for the tinderbox drivers), so this would probably be a minimum version required.

Thanks!
OS: Mac OS X → Linux

Comment 1

7 years ago
That's why I had not seen this at all.

Any instructions on how this gets updated?
Component: Infrastructure → Release Engineering
Product: Testing → mozilla.org
QA Contact: infra → release
Version: unspecified → other

Comment 2

7 years ago
This would probably make the talos numbers to wobble. It might require a downtime.
Depends on: 687443
I talked with Benoit last week about this and he agreed to take a stab at this on a loaned machine. Tracking access to that in bug 686337.
(In reply to Ben Hearsum [:bhearsum] from comment #3)
> I talked with Benoit last week about this and he agreed to take a stab at
> this on a loaned machine. Tracking access to that in bug 686337.

Oops, I mean bug 687443
Marking P3 because this is blocked on someone from GFX investigating the upgrade, tracked in the dependent bug.
Priority: -- → P3
Benoit Jacob did some initial work trying to get the drivers on the test machines updated, to no avail. I'm going to poke around some and see if I can figure something out. Here's Benoit's notes (from bug 687443):
Thanks for doing your best here, Benoit. I'm going to have a look and see if I can figure something out, but let's take it to bug 684165.(In reply to Benoit Jacob [:bjacob] from comment #4)
> TL;DR: EPIC FAIL
> 
> I used talos-r3-fed-001. The only Fedora 12 package for recent NVIDIA
> drivers that I found were:
> ftp://ftp.pbone.net/mirror/atrpms.net/f12-i386/atrpms/stable/nvidia-
> graphics275.09.07-libs-275.09.07-136.fc12.i686.rpm
> 
> I installed that on the test slave:
> 
> [root@talos-r3-fed-001 lib]# rpm -Uvh
> nvidia-graphics275.09.07-libs-275.09.07-136.fc12.i686.rpm
> 
> 
> I checked with rpm -qa what nvidia-related packages I had installed at this
> point:
> 
> [root@talos-r3-fed-001 lib]# rpm -qa | grep nvidia
> xorg-x11-drv-nvidia-libs-190.42-5.fc12.i686
> nvidia-graphics275.09.07-libs-275.09.07-136.fc12.i686
> nvidia-xconfig-1.0-1.fc12.i686
> xorg-x11-drv-nvidia-190.42-5.fc12.i686
> nvidia-settings-1.0-3.2.fc12.i686
> kmod-nvidia-2.6.31.5-127.fc12.i686.PAE-190.42-1.fc12.4.i686
> 
> 
> It was quite disconcerting to still have those 190.42 packages around so I
> searched for Fedora 12 versions of these packages, like kmod-nvidia and
> xorg-x11-drv-nvidia-libs, but I couldn't find any, so I decided that all I
> could do was hope that nvidia-graphics was enough.
> 
> So I rebooted it, and ran glxinfo... which told me that it was still using
> 190.42.
> 
> I checked in /usr/lib what the libGL / nvidia packages were looking like.
> 
> [root@talos-r3-fed-001 lib]# ls -l | egrep libGL\|nvidia
> lrwxrwxrwx  1 root root       12 2011-10-18 13:34 libGL.so.1 -> libGL.so.1.2
> -rwxr-xr-x  1 root root   590024 2009-09-21 14:25 libGL.so.1.2
> lrwxrwxrwx  1 root root       20 2010-01-20 11:08 libGLU.so.1 ->
> libGLU.so.1.3.070700
> -rwxr-xr-x  1 root root   446072 2009-09-21 14:25 libGLU.so.1.3.070700
> drwxr-xr-x  3 root root     4096 2010-01-21 03:37 nvidia
> drwxr-xr-x  4 root root     4096 2011-10-18 13:01 nvidia-graphics-275.09.07
> 
> I replaced the existing libGL.so.1 symlink by a link to
> nvidia-graphics-275.09.07/libGL.so.1 and retried glxinfo which was still
> using 190.42.
> 
> I unpacked a Firefox 10.0a1 Nightly build and went to about:support to force
> it to create a WebGL context and show me the GL version, but that crashed
> Firefox. Worried I might have caused that with my symlink change, I undid
> it... but going to about:support in Nightly still crashed.
> 
> I then decided to try the official NVIDIA driver installer so I downloaded
> NVIDIA-Linux-x86-285.05.09.run .... but it complained that it needed a
> compiler which wasn't present on this test slave.
> 
> Giving up. This needs someone more knowledgeable than me in Fedora.
> 
> Again, the motivation for this is to be able to turn on by default OpenGL
> Layers Acceleration in Firefox/Linux. Time is running short to do that for
> Firefox 10; it would be nice to have it in Firefox 11.
Assignee: nobody → bhearsum
(In reply to Ben Hearsum [:bhearsum] from comment #7)
> I found some promising looking packages on an ATrpms mirror:
> http://www.mirrorservice.org/sites/download.atrpms.net/f12-i386/atrpms/
> stable/nvidia-graphics275.09.07-275.09.07-136.fc12.i686.rpm
> http://www.mirrorservice.org/sites/download.atrpms.net/f12-i386/atrpms/
> stable/nvidia-graphics275.09.07-kmdl-2.6.32.26-175.fc12-275.09.07-136.fc12.
> i686.rpm
> http://www.mirrorservice.org/sites/download.atrpms.net/f12-i386/atrpms/
> stable/nvidia-graphics275.09.07-libs-275.09.07-136.fc12.i686.rpm
> http://www.mirrorservice.org/sites/download.atrpms.net/f12-i386/atrpms/
> stable/nvidia-graphics-helpers-0.0.30-33.fc12.i686.rpm
> 
> I'll try to find time to try them out this week.

I managed to get these installed, but also had to install a few extra packages:
nvidia-graphics-devices-1.0-6.fc12.noarch.rpm
kernel-firmware-2.6.32.26-175.fc12.noarch.rpm
kernel-PAE-2.6.32.26-175.fc12.i686.rpm

I also had to set vmalloc=192M as a boot option, otherwise the nvidia kernel driver didn't work.

After all of that, X still won't start. Here's an excerpt from the log:
(==) NVIDIA(0): Depth 24, (==) framebuffer bpp 32
(==) NVIDIA(0): RGB weight 888
(==) NVIDIA(0): Default visual is TrueColor
(==) NVIDIA(0): Using gamma correction (1.0, 1.0, 1.0)
(**) NVIDIA(0): Option "UseEDID" "False"
(**) NVIDIA(0): Option "IgnoreDisplayDevices" "DFP-0, DFP-1, DFP-2"
(**) NVIDIA(0): Option "RegistryDwords" "PowerMizerEnable=0x1; PerfLevelSrc=0x2222; PowerMizerDefault=0x1; PowerMizerDefaultAC=0x1"
(**) NVIDIA(0): Option "UseDisplayDevice" "CRT-0"
(**) NVIDIA(0): Option "AddARGBGLXVisuals" "True"
(**) NVIDIA(0): Option "ModeValidation" "CRT-0: NoVesaModes, NoEdidModes, NoXServerModes, NoPredefinedModes"
(**) NVIDIA(0): Option "ModeDebug" "True"
(**) Oct 20 07:37:46 NVIDIA(0): Ignoring EDIDs
(II) Oct 20 07:37:46 NVIDIA(0): NVIDIA GPU GeForce 9400 (C79) at PCI:2:0:0 (GPU-0)
(--) Oct 20 07:37:46 NVIDIA(0): Memory: 524288 kBytes
(--) Oct 20 07:37:46 NVIDIA(0): VideoBIOS: 62.79.4e.00.01
(--) Oct 20 07:37:46 NVIDIA(0): Interlaced video modes are supported on this GPU
(--) Oct 20 07:37:46 NVIDIA(0): Connected display device(s) on GeForce 9400 at PCI:2:0:0
(--) Oct 20 07:37:46 NVIDIA(0):     none
(EE) Oct 20 07:37:46 NVIDIA(0): No display devices found for this X screen.
(II) UnloadModule: "nvidia"
(II) UnloadModule: "wfb"
(II) UnloadModule: "fb"
(EE) Screen(s) found, but none have a usable configuration.


Googling around gives me mostly results talking about using custom EDID files, but I don't think that's relevant since we've disabled EDID. I'm a bit lost to where to go at this point, so if anyone has any ideas, please chime in!
That looks like your xorg.conf is missing the special sauce needed to run headless and dongle free.  Was the xorg.conf file was overwritten or modified when the driver was installed?  All the magic that makes things work is in the xorg.conf file, and I wouldn't be shocked if the post install scriptlet broke things.  If we are using the same xorg.conf as the previous driver then I wonder if nvidia has removed or changed some of the critical options.  EDID was tried but it didn't work at all, I wouldn't bother with it.

I'd avoid using ATRpms personally.  We used rpmfusion for the driver that's on there now and I know that rpmfusion's packages work.  Since they aren't supporting Fedora 12 anymore, I would rebuild the SRPMs from F13/14.  This would require installing a development toolchain on an F12 machine.  Probably easiest to sacrifice a staging machine and ask for it to be reimaged after this bug is resolved but a VM might work (my concern is the availability of kernel headers for the kernel we use, but those could be copied over for this).

RPMFusion has srpms for 280.13, 270.41.19 and 260.19.36 on F14.  On F13, they have 260.19.29 and 260.19.36.  They are also no longer supporting F13, but it is going to be closer to F12 than F14 and has a version that satisfies comment 0.  We could also write a simple specfile to use the nvidia installer.

The SRPMS should all be in the following directories.  You'll probably need nvidia-kmod and xorg-x11-drv-nvidia.  I also bet that you'd need to download the .run installers from nvidia's website to match the rpms.

http://download1.rpmfusion.org/nonfree/fedora/updates/13/SRPMS/
http://download1.rpmfusion.org/nonfree/fedora/updates/14/SRPMS/

Hope that helps!  Let me know if you have further questions.
Thanks for your help, John! I've been having a bit of trouble getting the packages built, but only due to missing build deps.

I spoke with bjacob about this on Friday and we both agreed that it's too late at this point to hit Firefox 10. I've got other pressing things at the moment, so I'm going to put this on the backburner for now and look at it again a few weeks, early in the Firefox 11 cycle.
I managed to get the drivers built! I used a local VM instead of a test machine because it was easier to work with. I had to install some extra packages on that machine in order to build, they were:
http://download1.rpmfusion.org/free/fedora/releases/12/Everything/i386/os/kmodtool-1-18.fc11.noarch.rpm
http://download1.rpmfusion.org/free/fedora/releases/12/Everything/i386/os/buildsys-build-rpmfusion-12-0.1.i686.rpm
http://download1.rpmfusion.org/free/fedora/releases/12/Everything/i386/os/buildsys-build-rpmfusion-kerneldevpkgs-current-12-0.1.i686.rpm

I also had to downgrade the kernel to:


Here's what I did to build the packages after that:
wget http://download1.rpmfusion.org/nonfree/fedora/updates/14/SRPMS/nvidia-kmod-280.13-2.fc14.src.rpm
wget http://download1.rpmfusion.org/nonfree/fedora/updates/14/SRPMS/xorg-x11-drv-nvidia-280.13-1.fc14.src.rpm
rpmbuild --rebuild --target=i686 nvidia-kmod-280.13-12.fc14.src.rpm
rpmbuild --rebuild --target=i686 xorg-x11-drv-nvidia-280.13-1.fc14.src.rpm

That gave me the following packages:
akmod-nvidia-280.13-2.fc12.i686.rpm
kmod-nvidia-2.6.31.5-127.fc12.i686.PAE-280.13-2.fc12.i686.rpm
kmod-nvidia-PAE-280.13-2.fc12.i686.rpm
nvidia-kmod-debuginfo-280.13-2.fc12.i686.rpm
xorg-x11-drv-nvidia-280.13-1.fc12.i686.rpm
xorg-x11-drv-nvidia-devel-280.13-1.fc12.i686.rpm
xorg-x11-drv-nvidia-libs-280.13-1.fc12.i686.rpm

AFAICT, we only need the two kmod ones, xorg-x11-drv-nvidia, and xorg-x11-drv-nvidia-libs. The akmod one is for DKMS AFAICT, and since we've built the drivers already, we don't need them. In addition to those four packages, a had to install libvdpau, because it was a dependency. All in all, I installed the following:
http://archives.fedoraproject.org/pub/archive/fedora/linux/updates/12/i386/libvdpau-0.4-1.fc12.i686.rpm
kmod-nvidia-2.6.31.5-127.fc12.i686.PAE-280.13-2.fc12.i686.rpm
kmod-nvidia-PAE-280.13-2.fc12.i686.rpm
xorg-x11-drv-nvidia-280.13-1.fc12.i686.rpm
xorg-x11-drv-nvidia-libs-280.13-1.fc12.i686.rpm

Additionally, in order to make X work I had to make the following changes to xorg.conf (I'll attach a full version of it later):
* Change "UseDisplayDevice" to "ConnectedMonitor"
* Comment out "IgnoreDisplayDevices" line.

I've now got both talos-r3-fed-002 and talos-r3-fed64-002 with updated drivers, and ready for validation by Benoit or another developer.
I've run mochitest-1 on both the i686 and the x86_64 slaves loaned to me. In both cases I get:

44329 ERROR TEST-UNEXPECTED-FAIL | /tests/content/canvas/test/test_canvas.html | pixel 20,48 of c347 is 14,241,0,255; expected 0,255,0,255 +/- 0
46376 ERROR TEST-UNEXPECTED-FAIL | /tests/content/canvas/test/webgl/test_webgl_conformance_test_suite.html | Test failed, "contextA.getUniform(programS, locationSx) should be 3. Was 0." (URL: conformance/uniforms/uniform-location.html)
46430 ERROR TEST-UNEXPECTED-PASS | /tests/content/canvas/test/webgl/test_webgl_conformance_test_suite.html | Test expected to fail, but passed: conformance/misc/uninitialized-test.html
46431 ERROR TEST-UNEXPECTED-PASS | /tests/content/canvas/test/webgl/test_webgl_conformance_test_suite.html | Test expected to fail, but passed: conformance/programs/gl-get-active-attribute.html
46432 ERROR TEST-UNEXPECTED-PASS | /tests/content/canvas/test/webgl/test_webgl_conformance_test_suite.html | Test expected to fail, but passed: conformance/uniforms/gl-uniform-bool.html
46433 ERROR TEST-UNEXPECTED-PASS | /tests/content/canvas/test/webgl/test_webgl_conformance_test_suite.html | Test expected to fail, but passed: conformance/more/functions/uniformfArrayLen1.html


This is good news: the first one is the only one that we need to worry about. All the rest is just known stuff. The second UNEXPECTED-FAIL is a known, harmless regression in the NVIDIA driver. The Four UNEXPECTED-PASS corresponds to bugs that are now fixed in the new NVIDIA driver.


So we just need to look into this canvas failure. CCing people.
(In reply to Benoit Jacob [:bjacob] from comment #12)
> I've run mochitest-1 on both the i686 and the x86_64 slaves loaned to me. In
> both cases I get:
> 
> 44329 ERROR TEST-UNEXPECTED-FAIL |
> /tests/content/canvas/test/test_canvas.html | pixel 20,48 of c347 is
> 14,241,0,255; expected 0,255,0,255 +/- 0
> 46376 ERROR TEST-UNEXPECTED-FAIL |
> /tests/content/canvas/test/webgl/test_webgl_conformance_test_suite.html |
> Test failed, "contextA.getUniform(programS, locationSx) should be 3. Was 0."
> (URL: conformance/uniforms/uniform-location.html)
> 46430 ERROR TEST-UNEXPECTED-PASS |
> /tests/content/canvas/test/webgl/test_webgl_conformance_test_suite.html |
> Test expected to fail, but passed: conformance/misc/uninitialized-test.html
> 46431 ERROR TEST-UNEXPECTED-PASS |
> /tests/content/canvas/test/webgl/test_webgl_conformance_test_suite.html |
> Test expected to fail, but passed:
> conformance/programs/gl-get-active-attribute.html
> 46432 ERROR TEST-UNEXPECTED-PASS |
> /tests/content/canvas/test/webgl/test_webgl_conformance_test_suite.html |
> Test expected to fail, but passed: conformance/uniforms/gl-uniform-bool.html
> 46433 ERROR TEST-UNEXPECTED-PASS |
> /tests/content/canvas/test/webgl/test_webgl_conformance_test_suite.html |
> Test expected to fail, but passed:
> conformance/more/functions/uniformfArrayLen1.html
> 
> 
> This is good news: the first one is the only one that we need to worry
> about. All the rest is just known stuff. The second UNEXPECTED-FAIL is a
> known, harmless regression in the NVIDIA driver. The Four UNEXPECTED-PASS
> corresponds to bugs that are now fixed in the new NVIDIA driver.
> 
> 
> So we just need to look into this canvas failure. CCing people.

Can we move the investigation of specific tests to other bugs, please?
Still to do here before we can deploy:
* run the upgraded machines through all test suites to look for additional failures.

I haven't had time to make any progress on this in a week or so. Once I'm done with some higher priority work, this is the next thing on my list.
(In reply to Ben Hearsum [:bhearsum] from comment #13)
> (In reply to Benoit Jacob [:bjacob] from comment #12)
> > I've run mochitest-1 on both the i686 and the x86_64 slaves loaned to me. In
> > both cases I get:
> > 
> > 44329 ERROR TEST-UNEXPECTED-FAIL |
> > /tests/content/canvas/test/test_canvas.html | pixel 20,48 of c347 is
> > 14,241,0,255; expected 0,255,0,255 +/- 0
> > 
> > This is good news: the first one is the only one that we need to worry
> > about.
> Can we move the investigation of specific tests to other bugs, please?

I filed https://bugzilla.mozilla.org/show_bug.cgi?id=708236 on the test_canvas failure.
See Also: → bug 708236
Depends on: 708236
Depends on: 708579
I filed bugs 708236 and 708579 on the two M1 failures. We also have a bunch of reftest failures that need to get dealt with before we can deploy. Should I be filing them in Core: Graphics, or somewhere else?
Depends on: 708647
Depends on: 708648
Depends on: 708652
Depends on: 708653
Depends on: 708655
Depends on: 708657
Depends on: 708658
Depends on: 708659
Depends on: 708661
Depends on: 708662
Depends on: 708663
Depends on: 708664
Depends on: 708666
Depends on: 708669
Depends on: 708670
Depends on: 708671
Created attachment 580178 [details] [diff] [review]
puppet manifests to upgrade the nvidia drivers

I tried to do this with package {}, but both of the xorg-* packages depend on each other, and xorg-x11-drv-nvidia and one of the kmod-nvidia packages also depend on each other. So, I gave up and used an exec for these. I tested on talos-r3-fed{,64}-001, which were never touched when I did my manual tests, so they were in a clean state. With the first reboot they got the drivers, with the subsequent one they had them activated.
Attachment #580178 - Flags: review?(jhford)
Comment on attachment 580178 [details] [diff] [review]
puppet manifests to upgrade the nvidia drivers

Review of attachment 580178 [details] [diff] [review]:
-----------------------------------------------------------------

r+ with the change to using the package name instead of grepping the installed files.

::: os/talos_fedora.pp
@@ +13,5 @@
> +    }
> +    exec {
> +        "install-xorg-nvidia":
> +            command => "/bin/rpm -U ${platform_httproot}/RPMs/xorg-x11-drv-nvidia-280.13-1.fc12.${hardwaremodel}.rpm ${platform_httproot}/RPMs/xorg-x11-drv-nvidia-libs-280.13-1.fc12.${hardwaremodel}.rpm ${kmodPackages}",
> +            onlyif => "/bin/bash -c '! /bin/rpm -ql xorg-x11-drv-nvidia | grep 280'";

What about "! /bin/rpm -qv xorg-x11-drv-nvidia | grep xorg-x11-drv-nvidia-280.13-1.fc12.${hardwaremodel}" ?

This makes sure that we have the exact version we want and is a more robust check in general.

[cltbld@talos-r3-fed-001 ~]$ rpm -qv xorg-x11-drv-nvidia
xorg-x11-drv-nvidia-280.13-1.fc12.i686
Attachment #580178 - Flags: review?(jhford) → review+
Sure, but I'll use unless instead of onlyif to avoid the confusing double negative.
Created attachment 580196 [details] [diff] [review]
use different check
Attachment #580178 - Attachment is obsolete: true
@ Matt Woodrow / Jeff Muizelaar: can one of you take a look at these reftest and canvas2d mochitest failures? (See blocking bugs).
Once the dep bugs are done this needs to be tested again, reviewed, and then landed. Anyone can do this though, so I'm throwing it back to the pool.
Assignee: bhearsum → nobody
Component: Release Engineering → Release Engineering: Platform Support
QA Contact: release → coop
Whiteboard: [refplatform][puppet]
Is this still valid now that we're moving to Ubuntu for our test slaves?
Flags: needinfo?(bjacob)
Not sure I understand, but: all what we need is that all the linux test slaves that we are using, have recent enough drivers. If the current, old slaves are getting replaced by newer ones, that sounds great, as long as the new slaves have new drivers! Maybe I could be more specific if you could tell me what GPU, Mesa or driver version, or distro version, the new slaves are using.
Flags: needinfo?(bjacob)
(In reply to Benoit Jacob [:bjacob] from comment #24)
> Not sure I understand, but: all what we need is that all the linux test
> slaves that we are using, have recent enough drivers. If the current, old
> slaves are getting replaced by newer ones, that sounds great, as long as the
> new slaves have new drivers! Maybe I could be more specific if you could
> ... or distro version, the new slaves
> are using.

[cltbld@talos-linux64-ix-007.test.releng.scl3.mozilla.com ~]$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:    Ubuntu 12.04 LTS
Release:        12.04
Codename:       precise

> ... tell me what GPU, ...

[cltbld@talos-linux64-ix-007.test.releng.scl3.mozilla.com ~]$ lspci | grep VGA
01:00.0 VGA compatible controller: NVIDIA Corporation Device 104a (rev a1)
05:03.0 VGA compatible controller: Matrox Graphics, Inc. MGA G200eW WPCM450 (rev 0a)
[cltbld@talos-linux64-ix-007.test.releng.scl3.mozilla.com ~]$ lspci | grep Display

> ... Mesa or driver version, ...

[cltbld@talos-linux64-ix-007.test.releng.scl3.mozilla.com ~]$ dpkg -l | grep mesa
ii  libgl1-mesa-dri                        9.2.0~git20130216.dd599188-0ubuntu0sarvatt~precise
  free implementation of the OpenGL API -- DRI modules
ii  libgl1-mesa-dri:i386                   9.2.0~git20130216.dd599188-0ubuntu0sarvatt~precise
  free implementation of the OpenGL API -- DRI modules
ii  libgl1-mesa-glx                        9.2.0~git20130216.dd599188-0ubuntu0sarvatt~precise
  free implementation of the OpenGL API -- GLX runtime
ii  libgl1-mesa-glx:i386                   9.2.0~git20130216.dd599188-0ubuntu0sarvatt~precise
  free implementation of the OpenGL API -- GLX runtime
ii  libglapi-mesa                          9.2.0~git20130216.dd599188-0ubuntu0sarvatt~precise
  free implementation of the GL API -- shared library
ii  libglapi-mesa:i386                     9.2.0~git20130216.dd599188-0ubuntu0sarvatt~precise
  free implementation of the GL API -- shared library
ii  libglu1-mesa                           9.0.0-0ubuntu1~precise1
  Mesa OpenGL utility library (GLU)
ii  libglu1-mesa:i386                      9.0.0-0ubuntu1~precise1
  Mesa OpenGL utility library (GLU)
[cltbld@talos-linux64-ix-007.test.releng.scl3.mozilla.com ~]$ dpkg -l | grep idia
ii  nvidia-310                             310.32-0ubuntu1~xedgers~precise1
  NVIDIA binary Xorg driver, kernel module and VDPAU library
ii  nvidia-common                          1:0.2.44
  Find obsolete NVIDIA drivers
ii  nvidia-settings-310                    310.32-0ubuntu1~xedgers~precise1
  Tool for configuring the NVIDIA graphics driver

--- bjacob, does that answer enough of your questions, to allow you to answer coops?
Flags: needinfo?(bjacob)
Thanks; yes, Ubuntu 12.04 LTS is recent enough, it should be good. One question remains unanswered: out of the two NVIDIA drivers (NVIDIA's proprietary one, and the Mesa Nouveau driver) which one is being used?

You can get this answer by either running glxinfo (from the mesa-utils package) and searching for vendor/renderer lines in the output, or running Firefox and going to about:support -> WebGL Renderer.
Flags: needinfo?(bjacob)
[cltbld@talos-linux64-ix-021.test.releng.scl3.mozilla.com ~]$ DISPLAY=:0 glxinfo | grep vendor
server glx vendor string: NVIDIA Corporation
client glx vendor string: NVIDIA Corporation
OpenGL vendor string: NVIDIA Corporation
[cltbld@talos-linux64-ix-021.test.releng.scl3.mozilla.com ~]$ DISPLAY=:0 glxinfo | grep renderer
OpenGL renderer string: GeForce GT 610/PCIe/SSE2

Anything more?
Flags: needinfo?(bjacob)
Alright, so we're using the NVIDIA binary driver. And the dkpg output from comment 25 says it's version 310.32. That's fine! If you want extra confirmation, you can check that

$ glxinfo | grep version

confirms version 310.32
Flags: needinfo?(bjacob)
ok!

[cltbld@talos-linux64-ix-021.test.releng.scl3.mozilla.com ~]$ DISPLAY=:0 glxinfo | grep version
server glx version string: 1.4
client glx version string: 1.4
GLX version: 1.4
OpenGL version string: 4.3.0 NVIDIA 310.32
OpenGL shading language version string: 4.30 NVIDIA via Cg compiler

:bjacob does this mean we can close this bug out as wontfix (since we won't fix the fedora machines) and it was part of our initial rollout on ubuntu?
Yes, this definitely means that replacing the current Fedora machines by such Ubuntu machines would address the problem that the current Fedora machines have too old drivers.
per c#30, this bug is wontfix.

We have most test suites moved over to Ubuntu already, there are a few holdouts though (mochitest browser chrome).

I say that working on making the ubuntu copies of those tests green is a much better endeavor than worrying about this bug. [It's also needed for other reasons too]
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → WONTFIX
(Assignee)

Updated

5 years ago
Product: mozilla.org → Release Engineering
(Assignee)

Updated

5 months ago
Component: Platform Support → Buildduty
Product: Release Engineering → Infrastructure & Operations
You need to log in before you can comment on or make changes to this bug.