test: increase timeouts on arm

[silverwind]

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.

[silverwind]

This timeout seems to have been chosen too generous, so I reduced it.

[silverwind]

@bnoordhuis could you start off a CI run with this PR? I need it to determine if the factors need more tweaking.

[bnoordhuis]

@silverwind https://jenkins-iojs.nodesource.com/view/iojs/job/iojs+any-pr+multi/465/

[silverwind]

Results are looking quite promising. I've rebased my branch to include silverwind@92ab3c0 which should fix two --- TIMEOUT --- cases and increased the timeout on one last problematic test. This will only leave one failing test on the iojs-armv7-wheezy bot, which is certainly not timeout related:

=== release test-child-process-exit-code ===
Path: parallel/test-child-process-exit-code
assert.js:88
  throw new assert.AssertionError({
        ^
AssertionError: 'SIGILL' === null

@bnoordhuis would appreciate another CI run!

(also I think I messed up this PR with my last rebase)

[bnoordhuis]

@silverwind You should probably sort out the rebase before I start another CI run, it looks like a wrong merge base now.

[silverwind]

@bnoordhuis branch fixed.

[bnoordhuis]

@silverwind https://jenkins-iojs.nodesource.com/view/iojs/job/iojs+any-pr+multi/468/

[silverwind]

Quite satisfied so far. Results:

• iojs-raspbian-wheezy-pi1 passing for the first time
• iojs-armv7-ubuntu1401 passing (did already pass before)
• iojs-raspbian-wheezy-pi2 would've passed if it didn't crash in an unrelated test:

=== release test-deprecation-flags ===
Path: sequential/test-deprecation-flags
Command: out/Release/iojs /home/iojs/build/workspace/iojs+any-pr+multi/nodes/iojs-armv7-wheezy/test/sequential/test-deprecation-flags.js
--- CRASHED ---

• iojs-raspbian-wheezy-pi2 (armv6) also would've passed but ran into a --- TIMEOUT --- (seems 3066f2c isn't enough for that test)

 === release test-stringbytes-external ===
 Path: parallel/test-stringbytes-external
 Command: out/Release/iojs /home/iojs/build/workspace/iojs+any-pr+multi/nodes/iojs-raspbian-wheezy-pi2/test/parallel/test-stringbytes-external.js
 --- TIMEOUT ---

@bnoordhuis please review.

[bnoordhuis]

Minor style issue: function(ms)

[bnoordhuis]

Left some comments.

[silverwind]

In addition to above comments, I'll work on fixing that last timeout from iojs-raspbian-wheezy-pi2 by adding a armv6 specific factor to tools/test.py.

[silverwind]

@bnoordhuis good for another CI run.

iojs-raspbian-wheezy-pi2 should go blue now, and with a bit of luck, all four bots should succeed.

[rvagg]

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.

[silverwind]

@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 iojs-raspbian-wheezy-pi2 is armv7, but it's actually armv6. I suggest including the architecture name for all bots, to avoid confusion.

[shigeki]

😄 Glad to see a blue light on armv8! Wait for a moment for ssl.

[bnoordhuis]

@silverwind https://jenkins-iojs.nodesource.com/view/iojs/job/iojs+any-pr+multi/472/

[shigeki]

Woops, I'll fix this.

[shigeki]

Sorry I missed the issue. I've just abort my job. So 472 will go on right now.

[rvagg]

@silverwind derp! I have an origial pi1 switched with the pi2 and they are reporting themselves as such, in the process of rectifying now

[silverwind]

Almost fully blue 😃

The iojs-raspbian-wheezy-pi2 failure looks to be another unrelated issue:

=== release test-net-settimeout ===
Path: parallel/test-net-settimeout
events.js:141
      throw er; // Unhandled 'error' event
            ^
Error: read ECONNRESET
    at exports._errnoException (util.js:749:11)
    at TCP.onread (net.js:538:26)
Command: out/Release/iojs /home/iojs/build/workspace/iojs+any-pr+multi/nodes/iojs-raspbian-wheezy-pi2/test/parallel/test-net-settimeout.js

@bnoordhuis please review so I can land this.

[bnoordhuis]

LGTM

[rvagg]

https://jenkins-iojs.nodesource.com/job/iojs+any-pr+multi/473/ should be with the right machines running in the right place

[silverwind]

Looks iojs-raspbian-wheezy-pi1 is still in the make stage after 1hr20, which is different than before. I won't let that CI run hold up this PR now, but will check the results later (I expect that armv6 job to take 5-6hrs, because that's what it takes on my RPi1).

[silverwind]

Merged in 7049d7b

[Fishrock123]

@silverwind iirc, ccache is running on those machines, so it should be less than if you are running without.

[silverwind]

Little Pi still going strong after 7hrs:

https://jenkins-iojs.nodesource.com/view/iojs/job/iojs+any-pr+multi/473/nodes=iojs-raspbian-wheezy-pi1/

(I think it's safe to assume there's no cache involved here)

[rvagg]

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