414720 - Enable 24-bit display on Windows test boxes.

Status: RESOLVED FIXED

(Release Engineering :: General, defect, P2)

Description

[Justin Dolske [:Dolske]]

Over in bug 405384, I was investigating reftest failures when testing PNG images. The color values in the test images were different than the expected values. Turns out this is due to the desktop running in 16-bit color mode. I was able to replicate the problem on a cloned VM, and switching to 24-bit color made everything work.

The steps to enable 24-bit color are from bug 405384 comment 14...

1. Run GPEDIT.MSC;
2. Go to: Local Computer Policy/Computer Configuration/
     Administrative Templates/Windows Components/Terminal Services;
3. Open the policy 'Limit maximum colour depth';
4. Set this to 'Enabled and 24 bit'

Then confirm that the display settings (via Windows Control Panel) are set to 24-bit mode.

This change will be needed on both qm-win2k3-01 and qm-winxp01, and will need to coordinate landing with the patch in bug 405384 to reenable the reftests. [Otherwise reftest will complain about "unexpected pass" results.]

Comment 1

[Rob Campbell [:rc] (:robcee)]

adding coop to put this on his radar...

Comment 2

[Justin Dolske [:Dolske]]

Can we try making this change at the end of this week, perhaps on the weekend? I don't want to get in the way of the big projects and post-freeze flood of checkins, but hopefully that could be clear by then.

Comment 3

[Rob Campbell [:rc] (:robcee)]

Alright, I'll mark it down and try to set it up on Friday morning, Feb 8th.

Comment 4

[Chris Cooper [:coop] (he/him)]

We can try this on the staging boxes earlier if we want.

Comment 5

[Rob Campbell [:rc] (:robcee)]

sounds like a good idea. Do we have the staging-win2k3 machine up yet? I'd like to see the results there.

Comment 6

[Chris Cooper [:coop] (he/him)]

(In reply to comment #5)
> sounds like a good idea. Do we have the staging-win2k3 machine up yet? I'd like
> to see the results there.

Still waiting to have the leak test win2k3 box imaged as part of bug 409042 so we can install that image on the staging box. I may just install this box by hand if we don't get traction there soon.

Are the XP boxes too flaky to make them a valid testing platform for this?

Comment 7

[Rob Campbell [:rc] (:robcee)]

Don't know. What do you think, Justin?

Comment 8

[Justin Dolske [:Dolske]]

The "flaky XP boxes" being qm-winxp-01? AFAIK the issue with that box was that it randomly failed now and then. But those failures should be distinct from the tests at issue here. Worst case should just be it taking an extra cycle or two to verify our changes, lest one of these failures happen to strike when the change is made.

Regardless, the end result needs to be that all Windows test boxes are using 24-bit color. The tests are marked as pass/fail on a general platform basis, so Win2K3 and XP will both need to be configured the same way.

Comment 9

[Rob Campbell [:rc] (:robcee)]

yeah, the failures on winxp01 were timing-related on the mochitests, I believe. Recently, they've started failing Tunit tests (bug 413287). It's a separate problem from this bug.

Comment 10

[Chris Cooper [:coop] (he/him)]

I've made the color depth changes changes to the qm-winxp01 and qm-stage-winxp01 slaves. Both are currently reporting to the the MozillaTest tinderbox tree.

Comment 11

[Justin Dolske [:Dolske]]

Looks like the change on qm-winxp01 and qm-stage-winxp01 worked as expected. Yay!

They're currently reporting "UNEXPECTED PASS" errors, which means the reftests are working like they should be, and will be green with the patch from bug 405384.

So, we should probably go ahead and make this change for qm-win2k3-01 (and concurrently land 405384). Are we waiting for a staging box to be born first, or can this happen any time?

Comment 12

[Chris Cooper [:coop] (he/him)]

(In reply to comment #11)
> So, we should probably go ahead and make this change for qm-win2k3-01 (and
> concurrently land 405384). Are we waiting for a staging box to be born first,
> or can this happen any time?

Let's not wait on the staging box (it's been a long time coming). I'll make the change on qm-win2k3-01 now, and we may have a few cycles of UNEXPECTED PASS until bug 405384 lands.

Comment 13

[Chris Cooper [:coop] (he/him)]

Color depth has been changed on qm-win2k3-01.

Comment 14

[Justin Dolske [:Dolske]]

Process nitpick:

The qm-win2k3-01 change was made at 7am PST, and the trees burned for 4 hours (until bug 405384 landed). The change probably should have been postponed until it was confirmed that I was around to land my half in coordination, so that the tree wasn't unnecessarily burning.

Not a big deal, and having staging boxes will help mitigate this, but just something to watch out for when making changes that can affect the tree status...

Comment 15

[Justin Dolske [:Dolske]]

Reopening:

Stuart had to back out the fix in bug 405384 on Friday night because the reftests started failing again after qm-win2k3-01 was rebooted.

I can't reproduce this on the qm-winxp01 clone I was working on before... I checked the display was set to 24-bit mode, rebooted it, reconnected, and the display was still in 24-bit color mode. I'm not sure what happened, perhaps whoever rebooted qm-win2k3-01 was using RDP in 16-bit color mode, and that somehow caused a reversion after the reboot/reconnect.

It should be possible to check that by setting qm-win2k3-01 back to 24-bit mode, rebooting it, and ensuring that it's still in 24-bit mode afterwards. (This will entail coordinating relanding 405384, if it stays in 24-bit mode).

Comment 16

[Justin Dolske [:Dolske]]

So... Apparently IT rebooted the box for some unrelated issue, and the tests started failing with "UNEXPECTED PASS" -- it rebooted into 24-bit color mode.

I think this suggests that the problem in the last comment was due to connecting with a 16-bit color RDP client. I'll send out an email, since preventing this problem from happening again is probably going to require people who can access the box being careful to not use 16-bit color in their RDP client. [Maybe there's some way to force 24-bit only mode in the registry stuff in comment #0, but I didn't see it.]

Sounds like the cure if this happens again is to disconnect the remote access client and reboot (perhaps just logging out would be sufficient, not sure).

Comment 17

[Justin Dolske [:Dolske]]

I've added an explicit test for 24-bit color mode now. This will be the first libpr0n reftest to fail if the box isn't in the right mode, which will hopefully make the cause more apparent to anyone unfamiliar with this problem.

Checking in modules/libpr0n/test/reftest/colordepth.html;
  initial revision: 1.1
Checking in modules/libpr0n/test/reftest/reftest.list;
  new revision: 1.11; previous revision: 1.10

Comment 18

[Jesse Ruderman]

That test will be more useful once bug 424386 is fixed ;)