Closed Bug 629759 Opened 13 years ago Closed 13 years ago

Upgrade NVIDIA driver to version 260.99 on all Windows XP rev3 test slaves

Categories

(Release Engineering :: General, defect, P2)

Product:
Release Engineering
Component:
General
Platform:
All
Windows 7
Type:
defect

Tracking

(Not tracked)

Status:
RESOLVED FIXED

People

(Reporter: armenzg, Assigned: armenzg)

References

(Blocks 1 open bug)

Details

(Whiteboard: [xp][gfx][q2goal][opsi])

Attachments

(1 file, 1 obsolete file)

OPSI package to install NVIDIA graphic drivers
2.94 KB, patch
rail
: review+
coop
: checked-in+
Details | Diff | Splinter Review 
+++ This bug was initially created as a clone of Bug #624044 +++

I want to keep separate the work on the Windows XP slaves as it is deployed through OPSI and it has lower priority (I want to get debug XP unit tests first as they have more value as this moment since bjacob has a workaround right now).

My estimate is to get to this work is on the week of the 15th of February and to have it deploy before the end of February.

Please rise up your voice if this schedule does not work for you.
FTR here is the current configuration on our XP slaves:

Name:        NVIDIA GeForce 9400
Main driver: nv4_disp.dll
Version:     6.14.001.7756
Date:        7/22/2009
Blocks: 629935
No longer depends on: 624044
Whiteboard: [xp][gfx] I have to finish first work on bug 614955
Priority: P3 → P4
Priority: P4 → P5
I've spoken with bjacob and it is fine to postpone this later as my load on my goals have been reprioritized and this is not critical.
Whiteboard: [xp][gfx] I have to finish first work on bug 614955 → [xp][gfx][q2goal]
Whiteboard: [xp][gfx][q2goal] → [xp][gfx][q2goal][opsi]
Priority: P5 → P4
There is just too much assigned to me.
Assignee: armenzg → nobody
Blocks: 660264
Assignee: nobody → armenzg
Priority: P4 → P2
Armen, where is this in your queue? Not pressuring, just trying to get some visibility. Thanks!
I have been build on duty all this week so I have not been able to do it.
I will pick this up on Monday.
Will this take downtime or is a matter of updating a refimage and then slowly rolling that out over the pool?
I can answer on the other bug so we don't keep two different conversations.

Also note that we are on our work week and next week I am off.
If I can't get it done this week I will have to pass it to someone else.
I am using talos-r3-xp-003 on staging-master:8041.
I still have to write the opsi package.

I am grabbing this:
Version:		260.99 WHQL
Release Date:		2010.10.25
Operating System:	Windows XP
Language:		English (U.S.)
File Size:		80.4 MB

[1] http://www.nvidia.com/object/winxp-260.99-whql-driver.html
NOTE to myself: Don't run dxdiag when connecting RDP as it messes you up.

To help automating I am looking into creating a zip file with all the contents of:
"C:\NVIDIA\Display Driver\260.99\WinXP\English"
and then run:
"setup.exe /s /k /noeula"
I might have to tie that command with a sleep step since it spawns the installation process.
After the process finishes it reboots the slave.

3 items get installed after the driver installation: "Nvidia graphics driver 260.99", "Nvidia nview 135.36" & "Nvidia physX system Software 9.10.0514".

I am going to put now the slave to run unit tests and talos.

What talos-r3-xp-003 has:
---------------
Display Devices
---------------
        Card name: NVIDIA GeForce 9400 
     Manufacturer: NVIDIA
        Chip type: GeForce 9400
         DAC type: Integrated RAMDAC
       Device Key: Enum\PCI\VEN_10DE&DEV_0861&SUBSYS_00AE106B&REV_B1
   Display Memory: 512.0 MB
     Current Mode: 1280 x 1024 (32 bit) (60Hz)
          Monitor: Default Monitor
  Monitor Max Res: 
      Driver Name: nv4_disp.dll
   Driver Version: 6.14.0012.6099 (English)
      DDI Version: 9 (or higher)
Driver Attributes: Final Retail
 Driver Date/Size: 10/16/2010 11:55:00, 6359552 bytes


What talos-r3-xp-001 has:
---------------
Display Devices
---------------
        Card name: NVIDIA GeForce 9400
     Manufacturer: NVIDIA
        Chip type: GeForce 9400
         DAC type: Integrated RAMDAC
       Device Key: Enum\PCI\VEN_10DE&DEV_0861&SUBSYS_00AE106B&REV_B1
   Display Memory: 512.0 MB
     Current Mode: 1280 x 1024 (32 bit) (60Hz)
          Monitor: Default Monitor
  Monitor Max Res: 
      Driver Name: nv4_disp.dll
   Driver Version: 6.14.0011.7756 (English)
      DDI Version: 9 (or higher)
Driver Attributes: Final Retail
 Driver Date/Size: 7/22/2009 11:14:33, 6286080 bytes
So far I have only seen talos svg to fail [1] [2] with the following error:
Traceback (most recent call last):
  File "bcontroller.py", line 230, in ?
    sys.exit(main())
  File "bcontroller.py", line 227, in main
    bcontroller.run()
  File "bcontroller.py", line 173, in run
    results_file = open(self.browser_log, "a")
IOError: [Errno 13] Permission denied: 'browser_output.txt'

I will re-trigger it and see if anything changes.

I still have opt unit test jobs that are still pending.
I will report back when they are done.

Meanwhile I will write the OPSI package and prepare instructions for someone else to deploy this change.

I have spoken with coop and he will either deploy it or find someone to do it.
Otherwise I will do it after I come back from holidays.


[1] http://tinderbox.mozilla.org/showlog.cgi?log=MozillaTest/1311918382.1311933233.12763.gz&fulltext=1
[2] http://staging-master.build.mozilla.org:8041/buildslaves/talos-r3-xp-003?numbuilds=30
All the unit tests have run and I have only seen one failure for reftest [1]:
REFTEST TEST-UNEXPECTED-FAIL | http://localhost:4444/1311952952214/194/svg-stylesheet-datauri-1.html | load failed: null

The 2nd triggered svg job did not fail this time and it succeeded.

I need two things to happen:
* grab the tinderbox values (copy/paste from the scrapping values on tinderbox) and compare with production numbers
* test that the OPSI package deploys the actual change

[1] http://tinderbox.mozilla.org/showlog.cgi?log=MozillaTest/1311952842.1311954623.28732.gz&fulltext=1#err0
The mentioned .zip file is on staging-master:~/winxp-260.99-whql-driver.zip
Passing it to coop.

I will try to put the package on staging-opsi before I head out tonight to make it easier for him.
Assignee: armenzg → coop
Priority: P2 → --
I tested the OPSI package by following this instructions:
https://wiki.mozilla.org/ReleaseEngineering/OPSI#Testing_the_package_on_staging

The patch failed on line 10 saying that SevenZip is undefined/incorrect (the path should have been C:\mozilla-build instead of D:\mozilla-build).

I tried to correct it locally and regenerated the package but it didn't work when I tested it again.
I must be doing something silly.

FTR I was using talos-r3-xp-001 to deploy the package if anyone gets a chance to try this again.

I am off now until Aug. 8th.
Priority: -- → P2
(In reply to comment #16)
> The patch failed on line 10 saying that SevenZip is undefined/incorrect (the
> path should have been C:\mozilla-build instead of D:\mozilla-build).

Your DOS commands need to be run inside a Winbatch_ or DosInAnIcon_ command.

You also don't need to worry about the sleep to catch the end of the process. OPSI blocks on the install, so you just need to reboot at the end.

I was able to successfully install this package on talos-r3-xp-001 today. The zip file will end up in opsi-binaries, as per usual.
Attachment #549439 - Attachment is obsolete: true
Attachment #550435 - Flags: review?(armenzg)
Comment on attachment 550435 [details] [diff] [review]
OPSI package to install NVIDIA graphic drivers

Armen's out until next week. Switching review.
Attachment #550435 - Flags: review?(armenzg) → review?(rail)
Comment on attachment 550435 [details] [diff] [review]
OPSI package to install NVIDIA graphic drivers

Looks good.
Attachment #550435 - Flags: review?(rail) → review+
I've added the package to production-opsi and have marked it for setup on all the XP slaves. 

Will monitor to config editor tomorrow to check on uptake.
Most xp slaves have this now. The install failed on xp-026, but I marked it for re-install, and it worked fine (if somewhat slow) the second time.

Slaves that are still missing the package:

007, 008, 010, 016, 022, 032, 033, 045, 053, 058, 060, ref
All xp slaves are updated now except 045 (bug 661377) and the ref image.

Back over to Armen to close out when he gets back.
Assignee: coop → armenzg
I see performance improvements on August 4th for Windows XP on m-a, m-c & m-i for Txul & Paint.

You can look at dev.tree-management to see the improvement emails.

http://graphs-new.mozilla.org/graph.html#tests=[[82,63,1],[17,63,1],[82,1,1],[17,1,1]]&sel=1312337758045.449,1312502324750.3857&displayrange=7&datatype=running
bjacob do we need to deploy a newer version of DirectX?
I don't think we need it as we did for Win7's WebGL failures, right? (see bug 624044)

If not, we can close this bug.

I documented that we added the newer graphic driver [1].

[1] https://wiki.mozilla.org/ReferencePlatforms/Test/WinXP#Upgrade_NVIDIA_driver
(In reply to Armen Zambrano G. [:armenzg] - Release Engineer from comment #25)
> bjacob do we need to deploy a newer version of DirectX?

No thanks, we don't need an update of DirectX SDKs. We already got the June 2010 edition which AFAIK is the latest.
(In reply to Benoit Jacob [:bjacob] from comment #26)
> (In reply to Armen Zambrano G. [:armenzg] - Release Engineer from comment
> #25)
> > bjacob do we need to deploy a newer version of DirectX?
> 
> No thanks, we don't need an update of DirectX SDKs. We already got the June
> 2010 edition which AFAIK is the latest.

What is the correct way of verifying such?
I want to be sure you are not getting confused with the Windows 2003 *build* machines rather than the Windows XP *testing* machines (talos-r3-xp-*) before closing this bug.
(In reply to Armen Zambrano G. [:armenzg] - Release Engineer from comment #27)
> What is the correct way of verifying such?
> I want to be sure you are not getting confused with the Windows 2003 *build*
> machines rather than the Windows XP *testing* machines (talos-r3-xp-*)
> before closing this bug.

In a build made by some of these build slaves, look in the dist/bin directory, if you see d3dx9_43.dll that means that it was made with the June 2010 DX SDK. If you saw d3dx9_42.dll that would mean it was made with the Feb 2010 DX SDK, which would be bad.
also, you can get this info right after the configure step by doing:

  grep DIRECTX config/autoconf.mk

in the object directory.
Thanks for the detailed instructions but I believe you think I am talking about the SDK rather that the runtime installer.

For the Win7 slaves (on bug 624044) we 1) upgraded the drivers and 2) installed the Direct X *runtime* [a].

For this bug we have already done #1 but I am asking if we need the DirectX *runtime* as well (I'm not talking about the SDK that was installed on the builders).

If we don't need it then we are happily done with this bug. 

[a] http://www.microsoft.com/download/en/details.aspx?id=35
Oh oops. sorry. No, there is no need anymore to install the DXSDK runtime on test slaves.

It used to be that Firefox relied on the presence of the DXSDK runtime for WebGL to work on Windows. So at that time, I needed the DXSDK runtime to be installed on test slaves. The problem with that approach is that many users don't have the DXSDK runtime installed. We solved this problem (bug 630628) by shipping the required parts of the DXSDK runtime with Firefox itself. So now Firefox only requires the DXSDK to be installed on the _build_ slaves, and there is no DXSDK requirement anymore on the test slaves.

Sorry I should have updated this bug.
No worries bjacob.

On another note, it seems that we might something more besides the graphic drivers update for bug 660264.

We can reopen if the DX runtime is needed after all.
Status: ASSIGNED → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
Summary: Install DirectX and upgrade NVIDIA driver to latest version on all Windows XP test slaves → Upgrade NVIDIA driver to version 260.99 on all Windows XP rev3 test slaves
Product: mozilla.org → Release Engineering
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: