reqwest: Request never connects on `armhf`

Hi, this was originally discussed in https://github.com/tokio-rs/mio/issues/1089 where we decided that it probably made sense to migrate the discussion to here.

In brief – A friend (@cjwatson) and I have been diagnosing a fault in rustup on armhf in Snapcraft’s build environment. It seems to sit for 30s trying to connect and then fails. This only seems to happen on armhf – on other platforms it connects just fine.

An strace of the attempt shows:

[pid  3517] 06:37:57.516581 futex(0xf933b8, FUTEX_WAIT_PRIVATE, 0, {tv_sec=29, tv_nsec=990974355} <unfinished ...>
[pid  3518] 06:37:57.516671 <... fcntl64 resumed> ) = 0x2 (flags O_RDWR)
[pid  3518] 06:37:57.516762 fcntl64(7, F_SETFL, O_RDWR|O_NONBLOCK) = 0
[pid  3518] 06:37:57.516894 connect(7, {sa_family=AF_INET, sin_port=htons(8222), sin_addr=inet_addr("10.10.10.1")}, 16) = -1 EINPROGRESS (Operation now in progress)
[pid  3518] 06:37:57.521838 epoll_ctl(4, EPOLL_CTL_ADD, 7, {EPOLLIN|EPOLLPRI|EPOLLOUT|EPOLLET, {u32=0, u64=0}}) = 0
[pid  3517] 06:38:27.507984 <... futex resumed> ) = -1 ETIMEDOUT (Connection timed out)

(Further straces show the epoll_ctl() call takes microsecnds, so it’s not actually stuck in it for 30s, but the thread which did the epoll_ctl() call subsequently did nothing. (Trace attached to the mio bug so I won’t reattach it here).

Interestingly in that strace we never get to epoll_wait() on armhf.

I had previously assumed it was probably mio at fault, but the discussion there suggests it’s more likely in the reqwest/tokio interfacing, so I brought the issue to here to discuss further.