Closed
Bug 712630
Opened 12 years ago
Closed 12 years ago
Allow devs to change screen resolution in-tree so they can try larger screen resolutions
Categories
(Infrastructure & Operations Graveyard :: CIDuty, task, P2)
Tracking
(Not tracked)
RESOLVED
FIXED
People
(Reporter: armenzg, Assigned: armenzg)
References
Details
Attachments
(8 files, 5 obsolete files)
1.30 KB,
patch
|
roc
:
review+
|
Details | Diff | Splinter Review |
52.10 KB,
text/plain
|
Details | |
1.76 KB,
patch
|
roc
:
review+
|
Details | Diff | Splinter Review |
3.15 KB,
patch
|
joe
:
review+
|
Details | Diff | Splinter Review |
4.52 KB,
patch
|
coop
:
review+
armenzg
:
checked-in+
|
Details | Diff | Splinter Review |
381 bytes,
patch
|
jmaher
:
review+
armenzg
:
checked-in+
|
Details | Diff | Splinter Review |
1.96 KB,
patch
|
jmaher
:
review+
armenzg
:
checked-in+
|
Details | Diff | Splinter Review |
2.35 KB,
patch
|
coop
:
review+
armenzg
:
checked-in+
|
Details | Diff | Splinter Review |
In bug 702504 we discovered that after attaching a dongle we can have the expected screen resolution to run accelerated reftests. Before IT and I can deploy the dongles we need someone to fix the tests. If these are not fixed there's nothing that IT/releng can do. We can loan a machine with a dongle for this to be fixed if needed. http://tinderbox.mozilla.org/showlog.cgi?log=MozillaTest/1323935060.1323937392.30220.gz&fulltext=1 REFTEST TEST-UNEXPECTED-FAIL | file:///c:/talos-slave/test/build/reftest/tests/layout/reftests/bugs/635373-1.html | image comparison (==) REFTEST TEST-UNEXPECTED-FAIL | file:///c:/talos-slave/test/build/reftest/tests/layout/reftests/bugs/635373-2.html | image comparison (==) REFTEST TEST-UNEXPECTED-FAIL | file:///c:/talos-slave/test/build/reftest/tests/layout/reftests/bugs/635373-3.html | image comparison (==)
Assignee | ||
Comment 1•12 years ago
|
||
Hi, We need this fixed so IT and releng can install the dongles and get back the correct screen resolution. Can I please have a taker?
Assignee | ||
Updated•12 years ago
|
Updated•12 years ago
|
Assignee: nobody → bas.schouten
Assignee | ||
Comment 2•12 years ago
|
||
Thanks for taking the bug! Is the plan to try to fix them? or to disable them while we figure it out? I would like to know the timeline just to give enough heads up to IT on when to add the dongles and to take advantage of any other downtimes scheduled in the next weeks.
Assignee | ||
Comment 3•12 years ago
|
||
Bas: ping Having a timeline will help IT and us to allocate resources. This quarter is going to be a super busy quarter for IT with the colo move. This means that if we get this resolved earlier we will have higher chances of finding a slot or a downtime to squeeze this in. Thanks!
Comment 4•12 years ago
|
||
I'll write a patch for this failure this week. I know what causes it.
Comment 5•12 years ago
|
||
Hi, Bas, just checking to see if there's been any progress on this. We're attempting to determine when a tree closure will need to happen to schedule the hardware work that depends on this fix. Thanks!
Comment 6•12 years ago
|
||
So, I've decided to mark these tests random. The reason for these failures is that in some situations we get a transparent layer, we then draw the rectangular bounds of the visible region and any edges of the visible region's rects inside the bounds of the visible region will get 'anti-aliased' by interpolation. When we have an opaque surface D3D10 will draw strictly the visible region rather than promoting the entire layer to be transparent (and making text drawing different). When doing this any inner edges will actual become boundaries of a quad and will become aliased. I think for now this behaviour is acceptable since our outer edges are aliased anyway. I'd rather mark these tests random than change behavior at this point. We should consider the behavior in a separate bug and make it consistent across layer managers to the extent that we can.
Attachment #592163 -
Flags: review?(roc)
How about making them fuzzy-if?
Comment 8•12 years ago
|
||
I'm not sure how fuzzy matching works? Note the per pixel differences here can be quite significant (up to 50% coverage). Although the absolute number of pixels is relatively small.
Comment on attachment 592163 [details] [diff] [review] Mark several tests random when D2D is used. Review of attachment 592163 [details] [diff] [review]: ----------------------------------------------------------------- ok
Attachment #592163 -
Flags: review?(roc) → review+
Comment 11•12 years ago
|
||
https://hg.mozilla.org/mozilla-central/rev/c0fa1e61c619
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla12
Assignee | ||
Comment 12•12 years ago
|
||
Thanks! I will test it in the next day on our pre-production systems to see that we're good to go.
Assignee | ||
Comment 13•12 years ago
|
||
It seems that we have 2 perma-oranges for both debug and opt reftests: https://tinderbox.mozilla.org/showlog.cgi?log=MozillaTest/1328146765.1328149807.19234.gz&fulltext=1 https://tinderbox.mozilla.org/showlog.cgi?log=MozillaTest/1328146765.1328149807.19234.gz&fulltext=1 REFTEST TEST-UNEXPECTED-FAIL | file:///c:/talos-slave/test/build/reftest/tests/layout/reftests/bugs/586683-1.html | image comparison (==) REFTEST TEST-UNEXPECTED-FAIL | file:///c:/talos-slave/test/build/reftest/tests/layout/reftests/bugs/718521.html | image comparison (==)
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Assignee | ||
Comment 14•12 years ago
|
||
Here are the differences of the images. bas, we can get you access to one of the two slaves so you can figure it out. It won't take us much time to set it up for you.
Assignee | ||
Comment 15•12 years ago
|
||
Bas, joe: ping This is very important as we want to get back to test with accelerated graphics.
Comment 16•12 years ago
|
||
Roc: One of these is a subpixel AA vs. non-subpixel AA difference, that's 1051 differing pixels, so we should probably just disable that with D3D10 layers. The other is a subtle corner AA difference, 51 differing pixels, we could fuzzy-match that. Do you agree with that?
I think we should just use fuzzy in both cases.
Comment 18•12 years ago
|
||
Attachment #597640 -
Flags: review?(roc)
Attachment #597640 -
Flags: review?(roc) → review+
Comment 19•12 years ago
|
||
Armen, can we land this and get the accelerated reftests turned on ASAP? That way we can be sure they'll stay green.
Assignee | ||
Comment 20•12 years ago
|
||
If we land it on the try server I can test it on staging. Once that shows fruitful I will coordinate with IT for a downtime next week to attach all the dongles.
Comment 21•12 years ago
|
||
https://hg.mozilla.org/integration/mozilla-inbound/rev/572b054e8c40 I didn't look on try? Can I get the data from the m-i run?
Comment 23•12 years ago
|
||
(In reply to Armen Zambrano G. [:armenzg] - Release Engineer from comment #20) > If we land it on the try server I can test it on staging. > Once that shows fruitful I will coordinate with IT for a downtime next week > to attach all the dongles. I just pushed m-i to try: https://tbpl.mozilla.org/?tree=Try&rev=8a2518e5f181
Assignee | ||
Comment 24•12 years ago
|
||
(In reply to Joe Drew (:JOEDREW!) from comment #23) > (In reply to Armen Zambrano G. [:armenzg] - Release Engineer from comment > #20) > > If we land it on the try server I can test it on staging. > > Once that shows fruitful I will coordinate with IT for a downtime next week > > to attach all the dongles. > > I just pushed m-i to try: https://tbpl.mozilla.org/?tree=Try&rev=8a2518e5f181 If what Bas pushed to m-i (which is now on m-c) is the same as on try then we don't need the try build. Mind cancelling the try build IIUC?
Comment 25•12 years ago
|
||
Done
Assignee | ||
Comment 26•12 years ago
|
||
Thanks Joe! I bring bad news :( I am going to need several oranges to be fixed. I am very sorry but I believe I only re-triggered reftests 2 weeks ago and this time I triggered everything. I might have discovered now oranges that might have been introduced in the last 2-3 months. FTR I am testing this on staging: https://tbpl.mozilla.org/?jobname=WINNT%206.1&rev=31fa580e684c There might actually be more oranges than the initial four suites since I had two slaves but one of the them was misbehaving (I pulled it out). I am triggering now every jobs on talos-r3-w7-053 for the same changeset and see if there are more oranges. This is the initial set of oranges: * Rev3 WINNT 6.1 mozilla-central debug test mochitest-other [1] (leak) * Rev3 WINNT 6.1 mozilla-central debug test reftest [2] * Rev3 WINNT 6.1 mozilla-central opt test mochitests-3/5 [3] * Rev3 WINNT 6.1 mozilla-central opt test reftest [4] [1] http://tinderbox.mozilla.org/showlog.cgi?log=MozillaTest/1329462846.1329466407.13165.gz&fulltext=1 [2] http://tinderbox.mozilla.org/showlog.cgi?log=MozillaTest/1329466489.1329469660.19461.gz&fulltext=1 REFTEST TEST-UNEXPECTED-FAIL | file:///c:/talos-slave/test/build/reftest/tests/layout/reftests/bugs/586683-1.html | image comparison (==) REFTEST TEST-UNEXPECTED-PASS | file:///c:/talos-slave/test/build/reftest/tests/layout/reftests/transform-3d/preserve3d-1a.html | image comparison (==) [3] http://tinderbox.mozilla.org/showlog.cgi?log=MozillaTest/1329445148.1329445602.4968.gz&fulltext=1 19788 ERROR TEST-UNEXPECTED-FAIL | /tests/editor/libeditor/text/tests/test_bug600570.html | Pasting and setting the value directly should result in the same rendering [4] http://tinderbox.mozilla.org/showlog.cgi?log=MozillaTest/1329442551.1329445064.3528.gz&fulltext=1 REFTEST TEST-UNEXPECTED-FAIL | file:///c:/talos-slave/test/build/reftest/tests/layout/reftests/bugs/586683-1.html | image comparison (==) REFTEST TEST-UNEXPECTED-FAIL | file:///c:/talos-slave/test/build/reftest/tests/layout/reftests/text-overflow/xulscroll.html | image comparison (==) REFTEST TEST-UNEXPECTED-PASS | file:///c:/talos-slave/test/build/reftest/tests/layout/reftests/transform-3d/preserve3d-1a.html | image comparison (==)
Comment 27•12 years ago
|
||
(In reply to Armen Zambrano G. [:armenzg] - Release Engineer from comment #26) > [4] > http://tinderbox.mozilla.org/showlog.cgi?log=MozillaTest/1329442551. > 1329445064.3528.gz&fulltext=1 > REFTEST TEST-UNEXPECTED-FAIL | > file:///c:/talos-slave/test/build/reftest/tests/layout/reftests/bugs/586683- > 1.html | image comparison (==) This one's interesting, 1051 difference but it reports only tolerating 52, my patch made it: fuzzy-if(d2d,1,1051) is that wrong somehow? > REFTEST TEST-UNEXPECTED-FAIL | > file:///c:/talos-slave/test/build/reftest/tests/layout/reftests/text- > overflow/xulscroll.html | image comparison (==) Tiny subpixel AA diff, I suspect we can just fuzzy-if. > REFTEST TEST-UNEXPECTED-PASS | > file:///c:/talos-slave/test/build/reftest/tests/layout/reftests/transform-3d/ > preserve3d-1a.html | image comparison (==) Unexpected pass! I can live with that :).
Assignee | ||
Comment 28•12 years ago
|
||
What is the status with this? Thanks in advance!
Comment 29•12 years ago
|
||
Can someone answer my first question? :)
Assignee | ||
Comment 30•12 years ago
|
||
Are you referring to comment 27? is that for joe/roc? me?
Comment 31•12 years ago
|
||
(In reply to Armen Zambrano G. [:armenzg] - Release Engineer from comment #30) > Are you referring to comment 27? is that for joe/roc? me? I'd be perfectly happy with anyone who knows the answer! :)
Assignee | ||
Comment 32•12 years ago
|
||
joe/roc: can you please see if you can help Bas with his question in comment 27?
Comment 33•12 years ago
|
||
I'm slammed right now, and roc's on vacation. Timothy, can you help us out with comment 27?
Comment 34•12 years ago
|
||
(In reply to Bas Schouten (:bas) from comment #27) > (In reply to Armen Zambrano G. [:armenzg] - Release Engineer from comment > #26) > > [4] > > http://tinderbox.mozilla.org/showlog.cgi?log=MozillaTest/1329442551. > > 1329445064.3528.gz&fulltext=1 > > REFTEST TEST-UNEXPECTED-FAIL | > > file:///c:/talos-slave/test/build/reftest/tests/layout/reftests/bugs/586683- > > 1.html | image comparison (==) > > This one's interesting, 1051 difference but it reports only tolerating 52, > my patch made it: > > fuzzy-if(d2d,1,1051) > > is that wrong somehow? I think 'fuzzy-if(d2d,1,1051)' means tolerate upto 1051 pixels being different by at most 1 in any channel. The log at http://tinderbox.mozilla.org/showlog.cgi?log=MozillaTest/1329442551.1329445064.3528.gz&fulltext=1#err0 is saying that 1051 pixels differed, and the maximum difference in any channel in those pixels was 52. So if you want to paper over this failure you want to increase the 1 to 52. Looking at the images though it appears that the text is getting subpixel AA in the reference, but grey scale AA in the test.
Comment 35•12 years ago
|
||
(In reply to Timothy Nikkel (:tn) from comment #34) > Looking at the images though it appears that the text is getting subpixel AA > in the reference, but grey scale AA in the test. I think we should still be able to get subpixel AA here, so if you go that route we should file a bug on this.
Comment 36•12 years ago
|
||
(In reply to Timothy Nikkel (:tn) from comment #35) > (In reply to Timothy Nikkel (:tn) from comment #34) > > Looking at the images though it appears that the text is getting subpixel AA > > in the reference, but grey scale AA in the test. > > I think we should still be able to get subpixel AA here, so if you go that > route we should file a bug on this. I suspect maybe normally both are greyscale. BasicLayers supplies subpixel AA a little less than the accelerated managers in theory. But regardless of that this is the reality our users are already on, I'd rather get the tests up and running for the current product than wait until we can fix underlying bugs. If you think the missing subpixel-AA is a gfx problem let me know though!
Comment 37•12 years ago
|
||
Yeah, that sounds reasonable.
Comment 38•12 years ago
|
||
I filed bug 730215 for that.
Comment 39•12 years ago
|
||
(In reply to Armen Zambrano G. [:armenzg] - Release Engineer from comment #26) > Thanks Joe! > > I bring bad news :( I am going to need several oranges to be fixed. > > I am very sorry but I believe I only re-triggered reftests 2 weeks ago and > this time I triggered everything. I might have discovered now oranges that > might have been introduced in the last 2-3 months. > > FTR I am testing this on staging: > https://tbpl.mozilla.org/?jobname=WINNT%206.1&rev=31fa580e684c > > There might actually be more oranges than the initial four suites since I > had two slaves but one of the them was misbehaving (I pulled it out). > I am triggering now every jobs on talos-r3-w7-053 for the same changeset and > see if there are more oranges. > > This is the initial set of oranges: > * Rev3 WINNT 6.1 mozilla-central debug test mochitest-other [1] (leak) > * Rev3 WINNT 6.1 mozilla-central debug test reftest [2] > * Rev3 WINNT 6.1 mozilla-central opt test mochitests-3/5 [3] > * Rev3 WINNT 6.1 mozilla-central opt test reftest [4] > > [1] > http://tinderbox.mozilla.org/showlog.cgi?log=MozillaTest/1329462846. > 1329466407.13165.gz&fulltext=1 > > [2] > http://tinderbox.mozilla.org/showlog.cgi?log=MozillaTest/1329466489. > 1329469660.19461.gz&fulltext=1 > REFTEST TEST-UNEXPECTED-FAIL | > file:///c:/talos-slave/test/build/reftest/tests/layout/reftests/bugs/586683- > 1.html | image comparison (==) > REFTEST TEST-UNEXPECTED-PASS | > file:///c:/talos-slave/test/build/reftest/tests/layout/reftests/transform-3d/ > preserve3d-1a.html | image comparison (==) > > [3] > http://tinderbox.mozilla.org/showlog.cgi?log=MozillaTest/1329445148. > 1329445602.4968.gz&fulltext=1 > 19788 ERROR TEST-UNEXPECTED-FAIL | > /tests/editor/libeditor/text/tests/test_bug600570.html | Pasting and setting > the value directly should result in the same rendering > > [4] > http://tinderbox.mozilla.org/showlog.cgi?log=MozillaTest/1329442551. > 1329445064.3528.gz&fulltext=1 > REFTEST TEST-UNEXPECTED-FAIL | > file:///c:/talos-slave/test/build/reftest/tests/layout/reftests/bugs/586683- > 1.html | image comparison (==) > REFTEST TEST-UNEXPECTED-FAIL | > file:///c:/talos-slave/test/build/reftest/tests/layout/reftests/text- > overflow/xulscroll.html | image comparison (==) > REFTEST TEST-UNEXPECTED-PASS | > file:///c:/talos-slave/test/build/reftest/tests/layout/reftests/transform-3d/ > preserve3d-1a.html | image comparison (==) Soo, question about this, I'll be addressing this, but one thing comes to mind, mochitest should've not changed. They should've always been running accelerated as they don't care about screen size. Did you not filter out random oranges perhaps? Especially since we have a failure in opt which isn't in debug reftests.
Assignee | ||
Comment 40•12 years ago
|
||
I will get back to you with fresh results tomorrow.
Assignee | ||
Comment 41•12 years ago
|
||
This is now finally working on staging again (I made few mistakes to trigger things). I will have answers for mochitests tomorrow. Are you being able to make progress on the reftests side? For the next round I will keep the logs on bugzilla or people since the tbox logs are not available.
Assignee | ||
Comment 42•12 years ago
|
||
Bas, do you have everything you need to make progress? It seems the mochitest were transient. This is what we have now: * Rev3 WINNT 6.1 mozilla-central debug test reftest [1] * Rev3 WINNT 6.1 mozilla-central opt test reftes [2] * Rev3 WINNT 6.1 mozilla-central opt test reftest-no-accel [3] [1] http://tinderbox.mozilla.org/showlog.cgi?log=MozillaTest/1330478093.1330481225.22197.gz&fulltext=1 REFTEST TEST-UNEXPECTED-FAIL | file:///c:/talos-slave/test/build/reftest/tests/layout/reftests/bugs/586683-1.html | image comparison (==) REFTEST TEST-UNEXPECTED-PASS | file:///c:/talos-slave/test/build/reftest/tests/layout/reftests/transform-3d/preserve3d-1a.html | image comparison (==) REFTEST TEST-UNEXPECTED-FAIL | file:///c:/talos-slave/test/build/reftest/tests/layout/reftests/transform-3d/scale3d-all.html | image comparison (==) REFTEST TEST-UNEXPECTED-FAIL | file:///c:/talos-slave/test/build/reftest/tests/layout/reftests/transform-3d/scale3d-all-separate.html | image comparison (==) [2] http://tinderbox.mozilla.org/showlog.cgi?log=MozillaTest/1330442311.1330444709.18555.gz&fulltext=1 REFTEST TEST-UNEXPECTED-FAIL | file:///c:/talos-slave/test/build/reftest/tests/layout/reftests/bugs/586683-1.html | image comparison (==) REFTEST TEST-UNEXPECTED-FAIL | file:///c:/talos-slave/test/build/reftest/tests/layout/reftests/css-valid/select/select-required-multiple-invalid.html | image comparison (==) REFTEST TEST-UNEXPECTED-FAIL | file:///c:/talos-slave/test/build/reftest/tests/layout/reftests/css-valid/select/select-required-multiple-valid.html | image comparison (==) REFTEST TEST-UNEXPECTED-FAIL | file:///c:/talos-slave/test/build/reftest/tests/layout/reftests/text-overflow/xulscroll.html | image comparison (==) REFTEST TEST-UNEXPECTED-PASS | file:///c:/talos-slave/test/build/reftest/tests/layout/reftests/transform-3d/preserve3d-1a.html | image comparison (==) REFTEST TEST-UNEXPECTED-FAIL | file:///c:/talos-slave/test/build/reftest/tests/layout/reftests/transform-3d/scale3d-all.html | image comparison (==) REFTEST TEST-UNEXPECTED-FAIL | file:///c:/talos-slave/test/build/reftest/tests/layout/reftests/transform-3d/scale3d-all-separate.html | image comparison (==) [3] http://tinderbox.mozilla.org/showlog.cgi?log=MozillaTest/1330474067.1330476335.12610.gz&fulltext=1 REFTEST TEST-UNEXPECTED-PASS | file:///c:/talos-slave/test/build/reftest/tests/layout/reftests/abs-pos/auto-offset-inline-block-1.html | image comparison (==) REFTEST TEST-UNEXPECTED-PASS | file:///c:/talos-slave/test/build/reftest/tests/layout/reftests/bidi/83958-2a.html | image comparison (==) REFTEST TEST-UNEXPECTED-PASS | file:///c:/talos-slave/test/build/reftest/tests/layout/reftests/bidi/83958-2b.html | image comparison (==) REFTEST TEST-UNEXPECTED-PASS | file:///c:/talos-slave/test/build/reftest/tests/layout/reftests/bidi/83958-2c.html | image comparison (==) REFTEST TEST-UNEXPECTED-PASS | file:///c:/talos-slave/test/build/reftest/tests/layout/reftests/bidi/613149-2a.html | image comparison (==) REFTEST TEST-UNEXPECTED-PASS | file:///c:/talos-slave/test/build/reftest/tests/layout/reftests/bidi/613149-2b.html | image comparison (==) REFTEST TEST-UNEXPECTED-PASS | file:///c:/talos-slave/test/build/reftest/tests/layout/reftests/bidi/613157-2.html | image comparison (==) REFTEST TEST-UNEXPECTED-FAIL | file:///c:/talos-slave/test/build/reftest/tests/layout/reftests/bugs/564991-1.html | image comparison (==) REFTEST TEST-UNEXPECTED-FAIL | file:///c:/talos-slave/test/build/reftest/tests/layout/reftests/bugs/579985-1.html | image comparison (==) REFTEST TEST-UNEXPECTED-FAIL | file:///c:/talos-slave/test/build/reftest/tests/layout/reftests/bugs/581317-1.html | image comparison (==) REFTEST TEST-UNEXPECTED-FAIL | file:///c:/talos-slave/test/build/reftest/tests/layout/reftests/bugs/586683-1.html | image comparison (==) REFTEST TEST-UNEXPECTED-FAIL | file:///c:/talos-slave/test/build/reftest/tests/layout/reftests/ogg-video/encoded-aspect-ratio-1.html | image comparison (==) REFTEST TEST-UNEXPECTED-FAIL | file:///c:/talos-slave/test/build/reftest/tests/layout/reftests/webm-video/encoded-aspect-ratio-1.html | image comparison (==) REFTEST TEST-UNEXPECTED-PASS | view-source:file:///c:/talos-slave/test/build/reftest/tests/parser/htmlparser/tests/reftest/bug482921-1.html | image comparison (==) REFTEST TEST-UNEXPECTED-PASS | file:///c:/talos-slave/test/build/reftest/tests/layout/reftests/svg/gradient-live-01a.svg | image comparison (==) REFTEST TEST-UNEXPECTED-PASS | file:///c:/talos-slave/test/build/reftest/tests/layout/reftests/svg/gradient-live-01b.svg | image comparison (==) REFTEST TEST-UNEXPECTED-PASS | file:///c:/talos-slave/test/build/reftest/tests/layout/reftests/svg/gradient-live-01c.svg | image comparison (==) REFTEST TEST-UNEXPECTED-PASS | file:///c:/talos-slave/test/build/reftest/tests/layout/reftests/svg/gradient-live-01d.svg | image comparison (==) REFTEST TEST-UNEXPECTED-PASS | file:///c:/talos-slave/test/build/reftest/tests/layout/reftests/transform-3d/preserve3d-1a.html | image comparison (==) REFTEST TEST-UNEXPECTED-FAIL | file:///c:/talos-slave/test/build/reftest/tests/layout/reftests/transform-3d/scale3d-all.html | image comparison (==) REFTEST TEST-UNEXPECTED-FAIL | file:///c:/talos-slave/test/build/reftest/tests/layout/reftests/transform-3d/scale3d-all-separate.html | image comparison (==)
Assignee | ||
Comment 43•12 years ago
|
||
I placed the logs in here: http://people.mozilla.com/~armenzg/bug712630
Comment 44•12 years ago
|
||
I'll have another look at this tomorrow, it looks like I've got the information I need here.
Assignee | ||
Comment 45•12 years ago
|
||
Any updates?
Assignee | ||
Comment 46•12 years ago
|
||
I just chatted with Bas and he will be looking into this today to mark them as random-if or fuzzy-if. This should get us going. Further investigation of why those failures are happening could come in a separate bug. Bas asked me how come no-accel gets regressed if they are *not* accelerated. I don't know why changing the resolution would affect those but let me put out the links and make explicit what gets called. This might help to point out if we are running anything incorrectly. * For accelerated tests (which we know they are not - this bug tries to fix it) [1]: 'python' 'reftest/runreftest.py' '--appname=firefox/firefox.exe' '--utility-path=bin' '--extra-profile-file=bin/plugins' u'--symbols-path=http://stage.mozilla.org/pub/mozilla.org/firefox/tinderbox-builds/mozilla-central-win32/1331676785/firefox-14.0a1.en-US.win32.crashreporter-symbols.zip' 'reftest/tests/layout/reftests/reftest.list' REFTEST INFO | WARNING: USE_WIDGET_LAYERS disabled args: ['c:\\talos-slave\\test\\build\\firefox\\firefox.exe', '-no-remote', '-profile', 'c:\\users\\cltbld\\appdata\\local\\temp\\tmpr3k-bc/', '-reftest', 'c:\\talos-slave\\test\\build\\reftest\\tests\\layout\\reftests\\reftest.list'] * For *not* accelerated tests [2]: 'python' 'reftest/runreftest.py' '--appname=firefox/firefox.exe' '--utility-path=bin' '--extra-profile-file=bin/plugins' u'--symbols-path=http://stage.mozilla.org/pub/mozilla.org/firefox/tinderbox-builds/mozilla-central-win32/1331676785/firefox-14.0a1.en-US.win32.crashreporter-symbols.zip' '--setpref=gfx.direct2d.disabled=true' '--setpref=layers.accelerate-none=true' 'reftest/tests/layout/reftests/reftest.list' args: ['c:\\talos-slave\\test\\build\\firefox\\firefox.exe', '-no-remote', '-profile', 'c:\\users\\cltbld\\appdata\\local\\temp\\tmp6yttpe/', '-reftest', 'c:\\talos-slave\\test\\build\\reftest\\tests\\layout\\reftests\\reftest.list'] REFTEST INFO | WARNING: USE_WIDGET_LAYERS disabled The only difference I see is this (which makes sense IIUC): '--setpref=gfx.direct2d.disabled=true' '--setpref=layers.accelerate-none=true' I hope this can allow us to spot something that is being run incorrectly. [1] https://tbpl.mozilla.org/php/getParsedLog.php?id=10047030&tree=Firefox&full=1 [2] https://tbpl.mozilla.org/php/getParsedLog.php?id=10047052&tree=Firefox&full=1
Assignee | ||
Comment 47•12 years ago
|
||
FTR from where I got the logs: https://tbpl.mozilla.org/?jobname=Rev3%20WINNT%206.1%20mozilla-central%20opt%20test%20reftest&rev=c71845b3b2a6
Assignee | ||
Comment 48•12 years ago
|
||
According to Bas, we're probably are *not* running non-accel properly. He says we need "layers.acceleration.disabled=true". This is instead of "--setpref=layers.accelerate-none=true". Let's see what happens on staging with a slave with dongle and another without a dongle.
Comment 49•12 years ago
|
||
Attachment #605854 -
Flags: review?(joe)
Assignee | ||
Updated•12 years ago
|
Whiteboard: [autoland-try:605854:try: -b do -p win32 -u all -t none
Comment 50•12 years ago
|
||
Comment on attachment 605854 [details] [diff] [review] Adjust several test markings Review of attachment 605854 [details] [diff] [review]: ----------------------------------------------------------------- Run 'er through try and we're good
Attachment #605854 -
Flags: review?(joe) → review+
Updated•12 years ago
|
Whiteboard: [autoland-try:605854:try: -b do -p win32 -u all -t none → [autoland-try:605854:-b do -p win32 -u all -t none]
Updated•12 years ago
|
Whiteboard: [autoland-try:605854:-b do -p win32 -u all -t none] → [autoland-in-queue]
Comment 51•12 years ago
|
||
Autoland Patchset: Patches: 605854 Branch: mozilla-central => try Destination: http://hg.mozilla.org/try/pushloghtml?changeset=da1766ae1903 Try run started, revision da1766ae1903. To cancel or monitor the job, see: https://tbpl.mozilla.org/?tree=Try&rev=da1766ae1903
Comment 52•12 years ago
|
||
Try run for da1766ae1903 is complete. Detailed breakdown of the results available here: https://tbpl.mozilla.org/?tree=Try&rev=da1766ae1903 Results (out of 49 total builds): exception: 1 success: 37 warnings: 11 Builds (or logs if builds failed) available at: http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/autolanduser@mozilla.com-da1766ae1903
Updated•12 years ago
|
Whiteboard: [autoland-in-queue]
Assignee | ||
Comment 54•12 years ago
|
||
I think we're close. reftests went green. I am doing a dry run of all suites again.
Assignee | ||
Comment 55•12 years ago
|
||
No issues. We're ready. Thanks Bas!
Status: REOPENED → RESOLVED
Closed: 12 years ago → 12 years ago
Resolution: --- → FIXED
Assignee | ||
Comment 56•12 years ago
|
||
I did one last run and I discovered that one of the win7 slaves that was taking jobs was not really using a higher screen resolution. talos-r3-w7-053 has a higher screen resolution and it does indeed fail on one more test: http://tinderbox.mozilla.org/showlog.cgi?log=MozillaTest/1332253145.1332255635.26560.gz&fulltext=1 REFTEST TEST-UNEXPECTED-FAIL | file:///c:/talos-slave/test/build/reftest/tests/layout/reftests/text-overflow/xulscroll.html | image comparison (==) Sorry for giving high hopes :(
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Assignee | ||
Comment 57•12 years ago
|
||
Hi Bas, These are the remaining issues: * Rev3 WINNT 6.1 mozilla-central opt test reftest on 2012/03/21 07:36:53 'python' 'reftest/runreftest.py' '--appname=firefox/firefox.exe' '--utility-path=bin' '--extra-profile-file=bin/plugins' '--symbols-path=http://stage.mozilla.org/pub/mozilla.org/firefox/tinderbox-builds/mozilla-central-win32/1332151882/firefox-14.0a1.en-US.win32.crashreporter-symbols.zip' 'reftest/tests/layout/reftests/reftest.list' REFTEST INFO | drawWindow flags = DRAWWINDOW_DRAW_CARET | DRAWWINDOW_DRAW_VIEW | DRAWWINDOW_USE_WIDGET_LAYERS; window size = 817,1038; test browser size = 800,1000 http://tinderbox.mozilla.org/showlog.cgi?log=MozillaTest/1332340613.1332343030.9668.gz&fulltext=1 REFTEST TEST-UNEXPECTED-FAIL | file:///c:/talos-slave/test/build/reftest/tests/layout/reftests/text-overflow/xulscroll.html | image comparison (==) * Rev3 WINNT 6.1 mozilla-central opt test reftest-no-accel on 2012/03/20 17:17:32 'python' 'reftest/runreftest.py' '--appname=firefox/firefox.exe' '--utility-path=bin' '--extra-profile-file=bin/plugins' '--symbols-path=http://stage.mozilla.org/pub/mozilla.org/firefox/tinderbox-builds/mozilla-central-win32/1332151882/firefox-14.0a1.en-US.win32.crashreporter-symbols.zip' '--setpref=gfx.direct2d.disabled=true' '--setpref=layers.acceleration.disabled=true' 'reftest/tests/layout/reftests/reftest.list' REFTEST INFO | drawWindow flags = DRAWWINDOW_DRAW_CARET | DRAWWINDOW_DRAW_VIEW | DRAWWINDOW_USE_WIDGET_LAYERS; window size = 817,1038; test browser size = 800,1000 http://tinderbox.mozilla.org/showlog.cgi?log=MozillaTest/1332289052.1332291471.20444.gz&fulltext=1 REFTEST TEST-UNEXPECTED-PASS | file:///c:/talos-slave/test/build/reftest/tests/layout/reftests/abs-pos/auto-offset-inline-block-1.html | image comparison (==) REFTEST TEST-UNEXPECTED-PASS | file:///c:/talos-slave/test/build/reftest/tests/layout/reftests/bidi/83958-2a.html | image comparison (==) REFTEST TEST-UNEXPECTED-PASS | file:///c:/talos-slave/test/build/reftest/tests/layout/reftests/bidi/83958-2b.html | image comparison (==) REFTEST TEST-UNEXPECTED-PASS | file:///c:/talos-slave/test/build/reftest/tests/layout/reftests/bidi/83958-2c.html | image comparison (==) REFTEST TEST-UNEXPECTED-PASS | file:///c:/talos-slave/test/build/reftest/tests/layout/reftests/bidi/613149-2a.html | image comparison (==) REFTEST TEST-UNEXPECTED-PASS | file:///c:/talos-slave/test/build/reftest/tests/layout/reftests/bidi/613149-2b.html | image comparison (==) REFTEST TEST-UNEXPECTED-PASS | file:///c:/talos-slave/test/build/reftest/tests/layout/reftests/bidi/613157-2.html | image comparison (==) REFTEST TEST-UNEXPECTED-FAIL | file:///c:/talos-slave/test/build/reftest/tests/layout/reftests/bugs/586683-1.html | image comparison (==) REFTEST TEST-UNEXPECTED-FAIL | file:///c:/talos-slave/test/build/reftest/tests/layout/reftests/bugs/632423-1.html | image comparison (==) REFTEST TEST-UNEXPECTED-PASS | view-source:file:///c:/talos-slave/test/build/reftest/tests/parser/htmlparser/tests/reftest/bug482921-1.html | image comparison (==) REFTEST TEST-UNEXPECTED-PASS | file:///c:/talos-slave/test/build/reftest/tests/layout/reftests/svg/gradient-live-01a.svg | image comparison (==) REFTEST TEST-UNEXPECTED-PASS | file:///c:/talos-slave/test/build/reftest/tests/layout/reftests/svg/gradient-live-01b.svg | image comparison (==) REFTEST TEST-UNEXPECTED-PASS | file:///c:/talos-slave/test/build/reftest/tests/layout/reftests/svg/gradient-live-01c.svg | image comparison (==) REFTEST TEST-UNEXPECTED-PASS | file:///c:/talos-slave/test/build/reftest/tests/layout/reftests/svg/gradient-live-01d.svg | image comparison (==) REFTEST TEST-UNEXPECTED-FAIL | file:///c:/talos-slave/test/build/reftest/tests/layout/reftests/transform-3d/scale3d-all.html | image comparison (==) REFTEST TEST-UNEXPECTED-FAIL | file:///c:/talos-slave/test/build/reftest/tests/layout/reftests/transform-3d/scale3d-all-separate.html | image comparison (==)
Comment 58•12 years ago
|
||
(In reply to Armen Zambrano G. [:armenzg] - Release Engineer from comment #57) > Hi Bas, > These are the remaining issues: > > * Rev3 WINNT 6.1 mozilla-central opt test reftest on 2012/03/21 07:36:53 > > 'python' 'reftest/runreftest.py' '--appname=firefox/firefox.exe' > '--utility-path=bin' '--extra-profile-file=bin/plugins' > '--symbols-path=http://stage.mozilla.org/pub/mozilla.org/firefox/tinderbox- > builds/mozilla-central-win32/1332151882/firefox-14.0a1.en-US.win32. > crashreporter-symbols.zip' 'reftest/tests/layout/reftests/reftest.list' > > REFTEST INFO | drawWindow flags = DRAWWINDOW_DRAW_CARET | > DRAWWINDOW_DRAW_VIEW | DRAWWINDOW_USE_WIDGET_LAYERS; window size = 817,1038; > test browser size = 800,1000 > > http://tinderbox.mozilla.org/showlog.cgi?log=MozillaTest/1332340613. > 1332343030.9668.gz&fulltext=1 > > REFTEST TEST-UNEXPECTED-FAIL | > file:///c:/talos-slave/test/build/reftest/tests/layout/reftests/text- > overflow/xulscroll.html | image comparison (==) I've figured out most of these except this one, do you have any idea here roc? My patch needs to be applied at the same time as when Ru -actually- becomes unaccelerated though. As this is currently testing D2D with basiclayers(an unsupported configuration).
Assignee | ||
Comment 59•12 years ago
|
||
Ru is really Ru after bug 737049, no?
Comment 60•12 years ago
|
||
(In reply to Armen Zambrano G. [:armenzg] - Release Engineer from comment #59) > Ru is really Ru after bug 737049, no? Right, so if Ru is green right now? How come you posted a bunch of failures up there? Or is it not green yet? I thought you said Ru was already being run.
Assignee | ||
Comment 61•12 years ago
|
||
What I know is that Ru in talos-r3-w7-53 fails: http://tinderbox.mozilla.org/showlog.cgi?log=MozillaTest/1332289052.1332291471.20444.gz&fulltext=1 and in production it succeeds: https://tbpl.mozilla.org/php/getParsedLog.php?id=10285684&tree=Firefox&full=1 Both staging and production run with: '--setpref=gfx.direct2d.disabled=true' '--setpref=layers.acceleration.disabled=true' 'reftest/tests/layout/reftests/reftest.list' I will put talos-r3-w7-036 (the one that has the normal screen resolution) to take a Ru just to contrast. If gfx wants we can ignore Ru for now and just hide it (even though I would prefer to both fixed at the same time) if there is just no time for this. We can loan you the machine if you would like to. Do you mind pushing to try the change you mentioned in comment 58? Please? That way I can test reftest-accelerated and hopefully move us one step forward.
Assignee | ||
Comment 62•12 years ago
|
||
I have verified that talos-r3-w7-036 goes green for Ru (this machine is using standard resolution rather than newer one).
Comment 63•12 years ago
|
||
I don't understand, something has to be wrong, if both are properly having acceleration disabled how can there be a difference.
Assignee | ||
Comment 64•12 years ago
|
||
Bas, I'm working with dividehex to add a dongle to 036 so at least we have 2 machines to get results from. Would you be able to peak for a couple of hours in those 2 slaves? (pending the second one is ready)
Comment 65•12 years ago
|
||
So, the key question here is what is different about the other machine after adding a dongle? Can we confirm that they are indeed both -not- using acceleration in any way? I'd be willing to look at any logs, but this is a lot easier for someone to look at that has direct access to both machines. For what it's worth, I think these are framework issue where somehow we're incorrectly detecting something or incorrectly disabling HWA, as both those builds should get !layersGPUAccelerated and it should fail or succeed on either of them. (whereas for example reftests/bidi/reftest.list believes it should fail if !layersGPUAccelerated). All the dongle should do is make it possible to use Widget layers instead of BasicLayers for reftests. Before the dongle it would be possible for layerGPUAccelerated to be true, but the actual reftest still to be run in BasicLayers. I'm not sure how the dongle would influence the reftest result -if- HWA was indeed off on both machines.
Assignee | ||
Comment 66•12 years ago
|
||
(In reply to Bas Schouten (:bas) from comment #65) > So, the key question here is what is different about the other machine after > adding a dongle? Can we confirm that they are indeed both -not- using > acceleration in any way? Sure. I will ensure they are the same tomorrow. > I'd be willing to look at any logs, but this is a > lot easier for someone to look at that has direct access to both machines. > I can give you access to both of them if you want to.
Comment 67•12 years ago
|
||
(In reply to Armen Zambrano G. [:armenzg] - Release Engineer from comment #66) > (In reply to Bas Schouten (:bas) from comment #65) > > So, the key question here is what is different about the other machine after > > adding a dongle? Can we confirm that they are indeed both -not- using > > acceleration in any way? > Sure. I will ensure they are the same tomorrow. > > > I'd be willing to look at any logs, but this is a > > lot easier for someone to look at that has direct access to both machines. > > > I can give you access to both of them if you want to. I don't actually know our reftest framework very well, particularly for build machines. I could launch firefox on them or run reftests from the command line and confirm hardware acceleration is disabled. But that wouldn't really tell us much as we know disabling hardware acceleration works. We need someone who can figure out what is -actually- being used when they run the reftests in their normal environment. If all else fails I could add a patch with some printfs that somebody can apply and run and then we can actually see it properly from the logs.
Assignee | ||
Comment 68•12 years ago
|
||
I spoke with joe directly and I explained to him that: * after dongles get attached "reftests" work and "reftest-non-accel" stop working I am going to test all suites again, add slaves w7-036 into the mix (I have verified the correct screen resolution is in it after dividehex added the dongle last week) and make sure that "reftests" are accelerated and green. If "reftest-no-accelerated" are still orange, we will disregard them and carry forward with deploying the dongles. We will fix Ru ("reftests-no-accel") in a follow up bug. joe agrees with this plan. The reasoning is that we have to move forward and Ru is *only* enabled on mozilla-central and try. I will post results tomorrow.
Assignee | ||
Comment 69•12 years ago
|
||
I lightning hit my head today and I hope this new idea would make this bug disappear immediately. We would call nircmd.exe setdisplay 1024 768 32 inside of a job instead of pre-buildbot-start. This means we could deploy the dongles without a downtime and we could test the newer screen resolution on the try server first and then land a change on mozilla-inbound. Let's fall in love with talos.json all over again if this works. Otherwise we will have a painful downtime landing "disable tests during downtime and follow up later" on all branches (m-c, m-a, m-b, m-r, m-esr10 et all).
Comment 70•12 years ago
|
||
(In reply to Armen Zambrano G. [:armenzg] - Release Engineer from comment #69) > I lightning hit my head today and I hope this new idea would make this bug > disappear immediately. We would call nircmd.exe setdisplay 1024 768 32 > inside of a job instead of pre-buildbot-start. > This means we could deploy the dongles without a downtime and we could test > the newer screen resolution on the try server first and then land a change > on mozilla-inbound. > Let's fall in love with talos.json all over again if this works. Armen: did you get a chance to try this out?
Assignee | ||
Comment 71•12 years ago
|
||
Yes, I did. I am getting mixed results from my quick looking: http://dev-master01.build.scl1.mozilla.com:8041/builders/Rev3%20WINNT%206.1%20mozilla-central%20opt%20test%20reftest I am triggering more jobs and I am trying to figure why I got only one green run. I will post the failures tomorrow. I am thinking of asking for another machine or two to get a dongle to get more reliable results.
Assignee: bas.schouten → nobody
Component: Graphics → History: Global
QA Contact: thebes → history.global
Updated•12 years ago
|
Assignee: nobody → bas.schouten
Component: History: Global → Graphics
QA Contact: history.global → thebes
Assignee | ||
Comment 72•12 years ago
|
||
Bas, could you please review these results? I know that it has once passed (slave036): http://tinderbox.mozilla.org/showlog.cgi?log=MozillaTest/1333665310.1333667535.3128.gz&fulltext=1 but I know that it has failed on the same test for both slaves: http://tinderbox.mozilla.org/showlog.cgi?log=MozillaTest/1334011608.1334013880.2243.gz&fulltext=1#err0 I can tell that the difference is focus. Perhaps I VNCed to the machine prior to starting the job. What do you think?
Comment 73•12 years ago
|
||
(In reply to Armen Zambrano G. [:armenzg] - Release Engineer from comment #72) > Bas, could you please review these results? > > I know that it has once passed (slave036): > http://tinderbox.mozilla.org/showlog.cgi?log=MozillaTest/1333665310. > 1333667535.3128.gz&fulltext=1 > but I know that it has failed on the same test for both slaves: > http://tinderbox.mozilla.org/showlog.cgi?log=MozillaTest/1334011608. > 1334013880.2243.gz&fulltext=1#err0 > > I can tell that the difference is focus. Perhaps I VNCed to the machine > prior to starting the job. > > What do you think? That's not a graphics issue, that's some side-effect of the dongle probably, causing a window to get focus somehow or something of the likes. Someone in content or editor or something like that probably has a better idea of what's going on there.
Assignee | ||
Comment 74•12 years ago
|
||
Hi bz/ehsan, For context, we have been running Windows 7 machines without dongles which means that we run at a lower resolution and thus not running reftests with accelerated hardware. We are now trying to attach the dongles without turning a bunch of tests permanently orange. We are trying to figure out all of these oranges on staging first. In comment 72 I describe how two machines that have dongles attached fail on a specific test due to focus on a button of a form (only one of the many runs went green). We need help figuring out why this is happening and hopefully fix the test or underlying problem. This is quite an important work and any help in the right direction would be extremely helpful.
Comment 75•12 years ago
|
||
Is that a focus effect, or a hover effect? If it's a hover effect, it could simply be a matter of mouse pointer position or some such... we've had issues like that with reftests involving form controls before.
Assignee | ||
Comment 76•12 years ago
|
||
I have added a step to move the cursor to the top right side of the screen. Let's side what it yields.
Assignee | ||
Comment 77•12 years ago
|
||
Is there a way to change the mouse position through our test infrastructure? I am trying to use "nircmd.exe setcursor 1010 10" but it only works when I open a command prompt on the VNC session (it doesn't work through ssh, buildbot or start up bat files).
Comment 78•12 years ago
|
||
If the issue really is hover state, we could also fix the test to not depend on hover state.
Assignee | ||
Comment 79•12 years ago
|
||
bz, if you could that for me it would be great. If you could push the change to the try server I could then try on staging. My python script seems to have failed when running through ssh (from VNCing into it I assume it did not work through buildbot regardless of the return code being 0): C:\talos-slave\test\build>cat setMousePosition.py import win32api, win32con def click(x,y): win32api.SetCursorPos((x,y)) click(1010,10) ### the following error is when I ssh into it C:\talos-slave\test\build>C:\mozilla-build\python25\python.exe setMousePosition.py Traceback (most recent call last): File "setMousePosition.py", line 6, in <module> click(1010,10) File "setMousePosition.py", line 4, in click win32api.SetCursorPos((x,y)) pywintypes.error: (1459, 'SetCursorPos', 'This operation requires an interactive window station.')
Assignee | ||
Comment 80•12 years ago
|
||
I am running setMousePosition.py [1] through buildbot and through startTalos.bat. Their output seems to succeed [2] but when I connect through VNC I can still see the cursor in the middle of the screen rather than at the top right. I am waiting on results and I really hope that it succeeds as I can't spend much more time on this during this week as I have a release and the SPDY work that is over-due. [1] import win32api import win32gui info = win32gui.GetCursorInfo() print "Previous mouse position: (%s, %s)" % (info[2][0], info[2][1]) win32api.SetCursorPos((1010,10)) info = win32gui.GetCursorInfo() print "Next mouse position: (%s, %s) "% (info[2][0], info[2][1]) [2] 'C:\\mozilla-build\\python25\\python.exe' 'setMousePosition.py' in dir c:\talos-slave\test\build (timeout 1200 secs) watching logfiles {} argv: ['C:\\mozilla-build\\python25\\python.exe', 'setMousePosition.py'] environment: ALLUSERSPROFILE=C:\ProgramData APPDATA=C:\Users\cltbld\AppData\Roaming COMMONPROGRAMFILES=C:\Program Files\Common Files COMPUTERNAME=TALOS-R3-W7-053 COMSPEC=C:\Windows\system32\cmd.exe FP_NO_HOST_CHECK=NO HOMEDRIVE=C: HOMEPATH=\Users\cltbld LOCALAPPDATA=C:\Users\cltbld\AppData\Local LOGONSERVER=\\TALOS-R3-W7-053 MOZ_CRASHREPORTER_NO_REPORT=1 MOZ_NO_REMOTE=1 NO_EM_RESTART=1 NUMBER_OF_PROCESSORS=2 OS=Windows_NT PATH=C:\mozilla-build;C:\mozilla-build\msys\bin;C:\mozilla-build\msys\local\bin;C:\mozilla-build\buildbotve\scripts;C:\mozilla-build\Python25;C:\mozilla-build\Python25\Scripts;C:\mozilla-build\hg;C:\mozilla-build\7zip;C:\mozilla-build\upx203w;C:\WINDOWS\System32\Wbem;C:\WINDOWS\System32;C:\WINDOWS; PATHEXT=.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH;.MSC PROCESSOR_ARCHITECTURE=x86 PROCESSOR_IDENTIFIER=x86 Family 6 Model 23 Stepping 10, GenuineIntel PROCESSOR_LEVEL=6 PROCESSOR_REVISION=170a PROGRAMDATA=C:\ProgramData PROGRAMFILES=C:\Program Files PROMPT=$P$G PSMODULEPATH=C:\Windows\system32\WindowsPowerShell\v1.0\Modules\ PUBLIC=C:\Users\Public PWD=c:\talos-slave\test\build SYSTEMDRIVE=C: SYSTEMROOT=C:\Windows TEMP=C:\Users\cltbld\AppData\Local\Temp TMP=C:\Users\cltbld\AppData\Local\Temp USERDOMAIN=TALOS-R3-W7-053 USERNAME=cltbld USERPROFILE=C:\Users\cltbld WINDIR=C:\Windows XPCOM_DEBUG_BREAK=warn using PTY: False Previous mouse position: (641, 513) Next mouse position: (1010, 10) program finished with exit code 0 elapsedTime=0.201000
Comment 81•12 years ago
|
||
> If you could push the change to the try server I could then try on staging. https://tbpl.mozilla.org/?tree=Try&rev=32db3b73f980
Assignee | ||
Comment 82•12 years ago
|
||
Thanks bz. I spoke with joduinn and I need to focus on SPDY work (which is over-due) before I head out for the MozCamp next Wednesday. As soon as that is done I will need 2-4 days heads down on this to make sure that I have the full picture of what exactly needs fixing. My plan is: 1) modify startTalos.bat to run current screen resolution ** make sure that we don't get any oranges on any branch 2) verify that we can attach the dongles without producing any new oranges ** ask IT to deploy the dongles 3) modify factory.py to allow setting the screen resolution from the code side ** this would allow pushing to the try server a higher screen resolution ** this would allow pushing to m-c and populate to other branches As soon as #1 is done I am inclined to say that #2 and #3 will be very easy. To accomplish #1, I have to verify the mouse pointer issue with the try server push or perhaps modify the test harness.
Assignee: bas.schouten → nobody
Priority: -- → P2
Target Milestone: mozilla12 → ---
Assignee | ||
Updated•12 years ago
|
Assignee: nobody → armenzg
Comment 83•12 years ago
|
||
Sorry for my delay here, but it seems like you guys have been making progress here. I didn't fully read the comments here (it's 12AM now!) but if my assistance is still required, please let me know what I can help with (or ping me on IRC to have a chat). Thanks!
Comment 84•12 years ago
|
||
Any news here guys?
This is incredibly critical. With no testing of D2D on Tinderbox, we basically have no testing of the graphics code that some large percentage of our users use. This is a lot more important than SPDY.
Assignee | ||
Comment 86•12 years ago
|
||
My priority is now on Windows 8. SPDY got done a while ago. I know this is important.
Priority: P2 → P3
Updated•12 years ago
|
Component: Graphics → Release Engineering: Platform Support
Product: Core → mozilla.org
QA Contact: thebes → coop
Version: unspecified → other
If you're setting up Windows 8 test machines that will test with accelerated rendering, that will take some of the urgency out of this bug. If you're not doing that, then I'm still very worried.
Comment 89•12 years ago
|
||
Just as a note: As we're switching on Azure-Thebes. This bug means we will now go to not just having an untested Layers backend. But a completely untested rendering backend, since Azure is bypassed when using BasicLayers. In other words we'll know if Azure is triggering assertions or crashing (since the drawing to the window still happens with Azure). But we will -not- know if Azure is drawing incorrectly.
Assignee | ||
Updated•12 years ago
|
Priority: P3 → P2
Assignee | ||
Comment 90•12 years ago
|
||
I am running this. I am now going to try proper formal jobs. ################################################################################ self.addStep(ShellCommand( name='download script', command=['wget', '--no-check-certificate', '-Omouse_and_screen_resolution.py','http://people.mozilla.com/~armenzg/incoming/mouse_and_screen_resolution.py'], flunkOnFailure=True, haltOnFailure=True, )) self.addStep(ShellCommand( name='run script', command=['C:\\mozilla-build\\python25\\python.exe', 'mouse_and_screen_resolution.py'], flunkOnFailure=True, haltOnFailure=True, )) ################################################################################ 'C:\\mozilla-build\\python25\\python.exe' 'mouse_and_screen_resolution.py' ... Screen resolution (current): (1280, 1024) Screen resolution (new): (1024, 768) Mouse position (current): (512, 384) Mouse position (new): (1010, 10)
Assignee | ||
Comment 91•12 years ago
|
||
I feel that a code similar to this should live in layout/tools/reftest/runreftest.py. roc, joe, jmaher: what do you think? This code right now is a no-op that would allow IT to attach the dongles and for developers to push to try newer screen resolutions. Armens-MacBook-Air:mozilla-inbound armenzg$ cat testing/configuration.json { "screen_resolution": { "x": 1024, "y": 768 }, "mouse_position": { "x": 1010, "y": 10 } }
Attachment #629870 -
Attachment is obsolete: true
Attachment #630315 -
Flags: feedback?(roc)
Attachment #630315 -
Flags: feedback?(jmaher)
Should we put this in automation.py.in so any test can use it? configuration.json could be a little more descriptive. Say machine-configuration.json? So the idea is that we check this in, then we can push to try with changes to machine-configuration.json and get the desired screen size/mouse position etc? Then when try's green, we push the configuration change to mozilla-central? That sounds good. Especially if we can extend it to other platforms later.
Comment 93•12 years ago
|
||
Comment on attachment 630315 [details] [diff] [review] [tools] mouse_and_screen_resolution.py Review of attachment 630315 [details] [diff] [review]: ----------------------------------------------------------------- a few comments, I really think we need to put error checking around the setresolution stuff as indicated below ::: scripts/support/mouse_and_screen_resolution.py @@ +17,5 @@ > +import os, sys > +import urllib2 > +import win32api > +import win32con > +import pywintypes are these python modules available inside our python evironment? I believe we have python 2.5 that we use, but we would have to install these separate. If we do have these installed we could probably switch to python 2.5 for talos on windows :) Likewise will this run on all windows platforms (xp, win7, w764)? I see the comment below that this is designed for w7 32 bit only, my concern is the imports here will fail on xp if you don't have the python modules installed. @@ +60,5 @@ > + if current_screen_resolution == new_screen_resolution: > + print "No need to change the screen resolution." > + else: > + print "Changing the screen resolution..." > + changeScreenResolution(new_screen_resolution) do we have to consider it might take a second or two here for this to change? @@ +100,5 @@ > + display_modes[key] = devmode > + n += 1 > + > + mode_required = (32, new["x"], new["y"], 60) > + devmode = display_modes[mode_required] what if the 32,x,y,60 is not an option? This with throw a python error.
Attachment #630315 -
Flags: feedback?(jmaher) → feedback-
Assignee | ||
Comment 94•12 years ago
|
||
jmaher I will tackle your comments tomorrow or Friday. (In reply to Robert O'Callahan (:roc) (Mozilla Corporation) from comment #92) > Should we put this in automation.py.in so any test can use it? > I will leave this for a follow up bug in case anyone wants to extend this beyond Win7 and reftests. I would remove my code at that point. > configuration.json could be a little more descriptive. Say > machine-configuration.json? > Sounds good. > So the idea is that we check this in, then we can push to try with changes > to machine-configuration.json and get the desired screen size/mouse position > etc? Then when try's green, we push the configuration change to > mozilla-central? That sounds good. Especially if we can extend it to other > platforms later. This is correct. It will be possible to extend to other platforms. We will see where we need it.
Assignee | ||
Comment 95•12 years ago
|
||
> > + mode_required = (32, new["x"], new["y"], 60)
> > + devmode = display_modes[mode_required]
>
> what if the 32,x,y,60 is not an option? This with throw a python error.
I have tested this and I would get a "KeyError: (a, b, c, d)" traceback and an error exit code.
Should I bother adding a try/except block if it would make buildbot stop the job without changing anything?
Comment 96•12 years ago
|
||
is it cleaner to have code than handles known possible exceptions, but either way we need to make buildbot continue or stop, so as long as the log files make sense to understand what is happening I am fine with either way.
Assignee | ||
Comment 97•12 years ago
|
||
Attachment #630315 -
Attachment is obsolete: true
Attachment #630315 -
Flags: feedback?(roc)
Attachment #630938 -
Flags: review?(jmaher)
Attachment #630938 -
Flags: review?(coop)
Assignee | ||
Comment 98•12 years ago
|
||
FTR I have also tested the script on win7 64-bit and WinXP.
Attachment #630939 -
Flags: review?(jmaher)
Comment 99•12 years ago
|
||
Comment on attachment 630938 [details] [diff] [review] [tools] mouse_and_screen_resolution.py Review of attachment 630938 [details] [diff] [review]: ----------------------------------------------------------------- just a few minor things. ::: scripts/support/mouse_and_screen_resolution.py @@ +4,5 @@ > +# file, You can obtain one at http://mozilla.org/MPL/2.0/. > + > +# > +# Script name: mouse_and_screen_resolution.py > +# Purpose: Sets mouse position and screen resolution for Windows slaves windows 7 32 bit slaves @@ +28,5 @@ > + > +def main(): > + ''' > + We load the configuration file from: > + http://hg.mozilla.org/mozilla-central/raw-file/default/build/configuration.json did we still want to call this configuration.json? I agree with roc's comment about how ambiguous that sounds. @@ +79,5 @@ > + print "Mouse position (new): (%(x)s, %(y)s)" % (current_mouse_position) > + > + if current_screen_resolution != new_screen_resolution or current_mouse_position != new_mouse_position: > + print "INFRA-ERROR: The new screen resolution or mouse positions are not what we expected" > + return 1 can we explicitly return 0 on success? @@ +106,5 @@ > + devmode.DisplayFrequency > + ) > + display_modes[key] = devmode > + n += 1 > + mixing 2 and 4 space indentation here, please correct to 4 space.
Attachment #630938 -
Flags: review?(jmaher) → review+
Comment 100•12 years ago
|
||
Comment on attachment 630939 [details] [diff] [review] machine-configuration.json Review of attachment 630939 [details] [diff] [review]: ----------------------------------------------------------------- can we comment that this is for windows 7 32 bit? Or is this going to be used for other purposes?
Attachment #630939 -
Flags: review?(jmaher) → review+
Assignee | ||
Comment 101•12 years ago
|
||
I addressed the comments by jmaher.
Attachment #630938 -
Attachment is obsolete: true
Attachment #630938 -
Flags: review?(coop)
Attachment #630975 -
Flags: review?(coop)
Assignee | ||
Comment 102•12 years ago
|
||
Added platform specific entry.
Attachment #630939 -
Attachment is obsolete: true
Attachment #630977 -
Flags: review?(jmaher)
Comment 103•12 years ago
|
||
Comment on attachment 630977 [details] [diff] [review] [inbound] machine-configuration.json Review of attachment 630977 [details] [diff] [review]: ----------------------------------------------------------------- cool, please make sure the file that reads this is updated as well.
Attachment #630977 -
Flags: review?(jmaher) → review+
Comment 104•12 years ago
|
||
Comment on attachment 630975 [details] [diff] [review] [tools] mouse_and_screen_resolution.py Review of attachment 630975 [details] [diff] [review]: ----------------------------------------------------------------- Script looks good. I would echo jmaher's comment but go further: if this script is really only ever going to be used on Win7, we should add 'win7' to the name of the script as a further clue that it shouldn't be expected to work elsewhere.
Attachment #630975 -
Flags: review?(coop) → review+
Comment 105•12 years ago
|
||
Once we have this working we should expect some accelerated reftests to fail again since we switched on Azure content. I wasn't able to mark them fuzzy because the exact behavior is hardware dependent. I'll need to get a D2D enabled run from the test machines so I can adjust the fuzziness of the tests.
Assignee | ||
Updated•12 years ago
|
Attachment #630975 -
Flags: checked-in+
Assignee | ||
Updated•12 years ago
|
Attachment #630977 -
Flags: checked-in+
Assignee | ||
Comment 106•12 years ago
|
||
The script even if run on Windows XP or Windows 7 64-bit it would simply skip it. I have to modify the script for the case where hg is down momentarily rather than falling on the default values I added (which are good for trees without the json file). I know that hg blips occur all the time since I had to add in-step-retry logic for the talos_from_code.py code.
Comment 107•12 years ago
|
||
https://hg.mozilla.org/mozilla-central/rev/e11cfc5084ea (Merged by Ed Morley)
Assignee | ||
Comment 108•12 years ago
|
||
I changed C:\Windows\System32\drivers\etc\hosts to point hg.m.o to localhost.
Attachment #631410 -
Flags: review?(jmaher)
Comment 109•12 years ago
|
||
Comment on attachment 631410 [details] [diff] [review] [tools] handle the situation when hg is down Review of attachment 631410 [details] [diff] [review]: ----------------------------------------------------------------- looking good.
Attachment #631410 -
Flags: review?(jmaher) → review+
Assignee | ||
Comment 110•12 years ago
|
||
We need a larger screen resolution for accelerated reftests. We need to move the mouse away because it causes so many oranges for various test suites. Remaining plan of actions: * Monday - deploy this buildbotcustom patch * Tuesday - dividehex deploys 5 dongles to production machines ** This should be a no-op since they should run at 1024x768 instead of 1200x1024 * Tuesday - /me watches for any fallouts if any on those 5 machines * Wednesday - go/no-go for IT to deploy remaining dongles whenever suits them best ** we can ask buildduty to disable slaves ahead of time for IT to deploy dongles when not running jobs ** OR ask for a small downtime (we can determine which one we want/need)
Attachment #631120 -
Attachment is obsolete: true
Attachment #631495 -
Flags: review?(coop)
Comment 111•12 years ago
|
||
Comment on attachment 631495 [details] [diff] [review] [buildbotcustom] run new screen resolution and mouse position for all unit tests jobs for Windows 7 32-bit slaves Review of attachment 631495 [details] [diff] [review]: ----------------------------------------------------------------- ::: process/factory.py @@ +6816,5 @@ > name='disable_screensaver', > command=['xset', 's', 'reset'], > env=self.env, > )) > + if self.platform.startswith('win32'): Should this be win7 instead of win32?
Attachment #631495 -
Flags: review?(coop) → review+
Assignee | ||
Comment 112•12 years ago
|
||
(In reply to Chris Cooper [:coop] from comment #111) > > + if self.platform.startswith('win32'): > > Should this be win7 instead of win32? Right now, UnitttestPackagedFactory don't have that fine graining. The script mouse_and_screen_resolution.py skips running on XP and Win7 64-bit.
Assignee | ||
Comment 113•12 years ago
|
||
Comment on attachment 631495 [details] [diff] [review] [buildbotcustom] run new screen resolution and mouse position for all unit tests jobs for Windows 7 32-bit slaves http://hg.mozilla.org/build/buildbotcustom/rev/2945a9b02531 As I said, this should be a no-op change even after the dongles get attached (since I enforce 1024x768 which is what we run right now). I will deploy this on Monday and continue the plan as mentioned on the previous comment.
Attachment #631495 -
Flags: checked-in+
Assignee | ||
Comment 114•12 years ago
|
||
Comment on attachment 631410 [details] [diff] [review] [tools] handle the situation when hg is down This patch landed last week: http://hg.mozilla.org/build/tools/rev/6df476d6cf98
Attachment #631410 -
Flags: checked-in+
Assignee | ||
Comment 115•12 years ago
|
||
This code has been merged to the production branch and masters have been reconfigured around 7:40 AM PDT. This means that we have landed code in preparation for adding 5 dongles tomorrow. This is a no-op change even after we attach the dongles.
Assignee | ||
Comment 116•12 years ago
|
||
This seems to have stick properly (at least for try - waiting on more results): https://tbpl.mozilla.org/php/getParsedLog.php?id=12553362&tree=Try&full=1 This branch does not seem to have the configuration file HTTP Error 404: Not Found Let's fail over to 1024x768. Screen resolution (current): (1024, 768) No need to change the screen resolution. Mouse position (current): (513, 385) Mouse position (new): (1010, 10) program finished with exit code 0 elapsedTime=1.301000 For Windows XP: INFO: This script was written to be used with Windows 7 32-bit machines.
Assignee | ||
Updated•12 years ago
|
Assignee | ||
Comment 117•12 years ago
|
||
The dependency and descriptions of these bugs have been somehow mixed (mea culpa). We ended up doing investigation and fix the releng side on this bug. I propose opening a new bug for the gfx to work on increasing a larger screen resolution. Thoughts?
Summary: Fix perma-oranges for accelerated reftests → Allow devs to change screen resolution in-tree so they can try larger screen resolutions
Comment 118•12 years ago
|
||
Sounds good to me.
Assignee | ||
Comment 119•12 years ago
|
||
I tested that we can change the screen resolution and mouse position by landing code changes: https://hg.mozilla.org/try/rev/84d83c001cad Screen resolution (current): (1024, 768) Changing the screen resolution... Screen resolution (new): (1280, 1024) Mouse position (current): (640, 512) Mouse position (new): (1270, 10) program finished with exit code 0 This also causes oranges to show up: https://tbpl.mozilla.org/php/getParsedLog.php?id=13080585&tree=Try&full=1 https://tbpl.mozilla.org/php/getParsedLog.php?id=13100834&tree=Try&full=1 I will push bug 702504 to the gfx team to finish up any remaining work. Yay!
Assignee | ||
Updated•12 years ago
|
Status: REOPENED → RESOLVED
Closed: 12 years ago → 12 years ago
Resolution: --- → FIXED
Updated•11 years ago
|
Product: mozilla.org → Release Engineering
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
•