Closed
Bug 684165
Opened 13 years ago
Closed 11 years ago
Upgrade OpenGL drivers on linux test machines
Categories
(Infrastructure & Operations Graveyard :: CIDuty, task, P3)
Tracking
(Not tracked)
RESOLVED
WONTFIX
People
(Reporter: mattwoodrow, Unassigned)
References
(Depends on 2 open bugs)
Details
(Whiteboard: [refplatform][puppet])
Attachments
(1 file, 1 obsolete file)
3.51 KB,
patch
|
Details | Diff | Splinter Review |
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!
Updated•13 years ago
|
OS: Mac OS X → Linux
Comment 1•13 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•13 years ago
|
||
This would probably make the talos numbers to wobble. It might require a downtime.
Comment 3•13 years ago
|
||
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.
Comment 4•13 years ago
|
||
(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
Comment 5•13 years ago
|
||
Marking P3 because this is blocked on someone from GFX investigating the upgrade, tracked in the dependent bug.
Priority: -- → P3
Comment 6•13 years ago
|
||
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
Comment 7•13 years ago
|
||
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.
Comment 8•13 years ago
|
||
(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!
Comment 9•13 years ago
|
||
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.
Comment 10•13 years ago
|
||
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.
Comment 11•13 years ago
|
||
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.
Comment 12•13 years ago
|
||
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.
Comment 13•13 years ago
|
||
(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?
Comment 14•13 years ago
|
||
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.
Comment 15•13 years ago
|
||
(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: → 708236
Comment 16•13 years ago
|
||
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?
Comment 17•13 years ago
|
||
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 18•13 years ago
|
||
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+
Comment 19•13 years ago
|
||
Sure, but I'll use unless instead of onlyif to avoid the confusing double negative.
Comment 20•13 years ago
|
||
Attachment #580178 -
Attachment is obsolete: true
Comment 21•13 years ago
|
||
@ Matt Woodrow / Jeff Muizelaar: can one of you take a look at these reftest and canvas2d mochitest failures? (See blocking bugs).
Comment 22•12 years ago
|
||
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
Updated•12 years ago
|
Whiteboard: [refplatform][puppet]
Comment 23•11 years ago
|
||
Is this still valid now that we're moving to Ubuntu for our test slaves?
Flags: needinfo?(bjacob)
Comment 24•11 years ago
|
||
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)
Comment 25•11 years ago
|
||
(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)
Comment 26•11 years ago
|
||
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)
Comment 27•11 years ago
|
||
[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)
Comment 28•11 years ago
|
||
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)
Comment 29•11 years ago
|
||
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?
Comment 30•11 years ago
|
||
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.
Comment 31•11 years ago
|
||
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
Closed: 11 years ago
Resolution: --- → WONTFIX
Assignee | ||
Updated•11 years ago
|
Product: mozilla.org → Release Engineering
Assignee | ||
Updated•6 years ago
|
Component: Platform Support → Buildduty
Product: Release Engineering → Infrastructure & Operations
Updated•4 years ago
|
Product: Infrastructure & Operations → Infrastructure & Operations Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•