Enable 24-bit display on Windows test boxes.



Release Engineering
10 years ago
5 years ago


(Reporter: Dolske, Assigned: coop)


Firefox Tracking Flags

(Not tracked)




10 years ago
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...

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.]
adding coop to put this on his radar...

Comment 2

10 years ago
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.
Alright, I'll mark it down and try to set it up on Friday morning, Feb 8th.
Whiteboard: [scheduled for weekend of Feb 8, 2008]

Comment 4

10 years ago
We can try this on the staging boxes earlier if we want.
sounds like a good idea. Do we have the staging-win2k3 machine up yet? I'd like to see the results there.

Comment 6

10 years ago
(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?
Don't know. What do you think, Justin?

Comment 8

10 years ago
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.
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

10 years ago
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

10 years ago
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

10 years ago
(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.
Assignee: nobody → ccooper


10 years ago
Priority: -- → P2

Comment 13

10 years ago
Color depth has been changed on qm-win2k3-01.
Last Resolved: 10 years ago
Resolution: --- → FIXED

Comment 14

10 years ago
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

10 years ago

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).
Resolution: FIXED → ---


10 years ago
Whiteboard: [scheduled for weekend of Feb 8, 2008]

Comment 16

10 years ago
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).
Last Resolved: 10 years ago10 years ago
Resolution: --- → FIXED

Comment 17

10 years ago
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

10 years ago
That test will be more useful once bug 424386 is fixed ;)
Depends on: 458847
Blocks: 458847
No longer depends on: 458847
Component: Testing → Release Engineering
Product: Core → mozilla.org
QA Contact: testing → release
Target Milestone: mozilla1.9beta4 → ---
Version: Trunk → other
Product: mozilla.org → Release Engineering
You need to log in before you can comment on or make changes to this bug.