-
Notifications
You must be signed in to change notification settings - Fork 29.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
test: increase timeouts on arm #1366
Conversation
@@ -51,7 +51,7 @@ function onNoMoreLines() { | |||
|
|||
setTimeout(function testTimedOut() { | |||
assert(false, 'test timed out.'); | |||
}, 6000).unref(); | |||
}, common.platformTimeout(3000)).unref(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This timeout seems to have been chosen too generous, so I reduced it.
@bnoordhuis could you start off a CI run with this PR? I need it to determine if the factors need more tweaking. |
Results are looking quite promising. I've rebased my branch to include silverwind@92ab3c0 which should fix two
@bnoordhuis would appreciate another CI run! (also I think I messed up this PR with my last rebase) |
@silverwind You should probably sort out the rebase before I start another CI run, it looks like a wrong merge base now. |
3deca2c
to
cb025c1
Compare
bd0f345
to
0c2210b
Compare
@bnoordhuis branch fixed. |
Quite satisfied so far. Results:
@bnoordhuis please review. |
armv7: 2.0 | ||
}; | ||
|
||
exports.platformTimeout = function (ms) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Minor style issue: function(ms)
Left some comments. |
In addition to above comments, I'll work on fixing that last timeout from |
8750c84
to
e4a5192
Compare
@bnoordhuis good for another CI run.
|
FYI, the persistent failure of parallel/test-debug-port-cluster on the ARMv8 machine was because there was a long running process there from a previous test run that was blocking the debug port that test was trying to use. I've killed that and now: So woohoo! I think this means we have solid ARMv8 support now doesn't it? I thought OpenSSL 1.0.2 was a blocker for us on ARMv8 but obviously that was addressed, by @bnoordhuis I guess. Unless anyone has a reason not to, I'm going to push forward trying to get some more server resources to figure out a release build strategy for ARMv8/AARCH64 binaries. |
@rvagg 🎉 nice, that means armv8 works pretty well already. While you're at the CI, I think the ARM bots could use some relabeling. You mentioned |
😄 Glad to see a blue light on armv8! Wait for a moment for ssl. |
Woops, I'll fix this. |
Sorry I missed the issue. I've just abort my job. So 472 will go on right now. |
@silverwind derp! I have an origial pi1 switched with the pi2 and they are reporting themselves as such, in the process of rectifying now |
Almost fully blue 😃 The
@bnoordhuis please review so I can land this. |
LGTM |
https://jenkins-iojs.nodesource.com/job/iojs+any-pr+multi/473/ should be with the right machines running in the right place |
Looks |
This commit introduces platform-specific test timeouts for the ARM architectures. ARMv6 is notoriously slow so gets very large timeouts on both the timeout value for each test, as well as certain problematic individual tests. ARMv7 and ARMv8 also get slightly increased headroom. PR-URL: #1366 Fixes: #1343 Reviewed-By: Ben Noordhuis <[email protected]>
Merged in 7049d7b |
@silverwind iirc, ccache is running on those machines, so it should be less than if you are running without. |
Little Pi still going strong after 7hrs: (I think it's safe to assume there's no cache involved here) |
it's because I changed the env of this and pi2 when you notified me they were around the wrong way - so the cache has to start again with new env vars influencing the build .. over time it should get much better |
Notable changes: * C++ API: Fedor Indutny contributed a feature to V8 which has been backported to the V8 bundled in io.js. SealHandleScope allows a C++ add-on author to seal a HandleScope to prevent further, unintended allocations within it. Currently only enabled for debug builds of io.js. This feature helped detect the leak in #1075 and is now activated on the root HandleScope in io.js. (Fedor Indutny) #1395. * ARM: This release includes significant work to improve the state of ARM support for builds and tests. The io.js CI cluster's ARMv6, ARMv7 and ARMv8 build servers are now all (mostly) reporting passing builds and tests. - ARMv8 64-bit (AARCH64) is now properly supported, including a backported fix in libuv that was mistakenly detecting the existence of `epoll_wait()`. (Ben Noordhuis) #1365. - ARMv6: #1376 reported a problem with Math.exp() on ARMv6 (incl Raspberry Pi). The culprit is erroneous codegen for ARMv6 when using the "fast math" feature of V8. --nofast_math has been turned on for all ARMv6 variants by default to avoid this, fast math can be turned back on with --fast_math. (Ben Noordhuis) #1398. - Tests: timeouts have been tuned specifically for slower platforms, detected as ARMv6 and ARMv7. (Roman Reiss) #1366. * npm: Upgrade npm to 2.7.6. See the release notes (https://github.com/npm/npm/releases/tag/v2.7.6) for details.
Related: #1343
The static factors are still subject to change, and I think I'll look into benchmarking to obtain them dynamically. ARMv8 gets no special treatment as I think it won't need it. The ARMv6 factor is probably too low for some boards. My RPi does fine with around 2-3x, but it is overclocked and has a pretty fast SD.
If someone could start off a CI run with this PR, I'd be grateful as this should green out CI for ARMv6 and ARMv7.