x/sys/unix: TestSysctlClockinfo failing with "input/output error" on openbsd-arm*-jsing since Aug. 2

[bcmills]

--- FAIL: TestSysctlClockinfo (0.00s)
    syscall_bsd_test.go:73: input/output error
FAIL
FAIL	golang.org/x/sys/unix	2.351s

$ greplogs --dashboard -md -l -e FAIL: TestSysctlClockinfo

2021-08-09T22:24:54-d867a43/1f9c9d8/openbsd-arm-jsing
2021-08-09T22:24:54-d867a43/1f9c9d8/openbsd-arm64-jsing
2021-08-09T22:24:54-d867a43/f1dce31/openbsd-arm-jsing
2021-08-09T22:24:54-d867a43/f1dce31/openbsd-arm64-jsing
2021-08-09T22:13:28-b450225/f1dce31/openbsd-arm-jsing
2021-08-09T22:13:28-b450225/f1dce31/openbsd-arm64-jsing
2021-08-09T20:39:39-8946682/f1dce31/openbsd-arm-jsing
2021-08-09T20:39:39-8946682/f1dce31/openbsd-arm64-jsing
2021-08-06T18:45:41-e5e7981/507cc34/openbsd-arm-jsing
2021-08-06T18:45:41-e5e7981/507cc34/openbsd-arm64-jsing
2021-08-06T18:45:41-e5e7981/63b968f/openbsd-arm64-jsing
2021-08-06T18:45:41-e5e7981/70546f6/openbsd-arm64-jsing
2021-08-06T18:45:41-e5e7981/7aeaad5/openbsd-arm64-jsing
2021-08-06T18:45:41-e5e7981/891547e/openbsd-arm-jsing
2021-08-06T18:45:41-e5e7981/891547e/openbsd-arm64-jsing
2021-08-06T18:45:41-e5e7981/f1dce31/openbsd-arm-jsing
2021-08-06T18:45:41-e5e7981/f1dce31/openbsd-arm64-jsing
2021-06-30T00:52:30-0f9fa26/6e73886/openbsd-arm-jsing
2021-06-30T00:52:30-0f9fa26/6e73886/openbsd-arm64-jsing
2021-06-30T00:52:30-0f9fa26/8a7ee4c/openbsd-arm-jsing
2021-06-30T00:52:30-0f9fa26/8a7ee4c/openbsd-arm64-jsing
2021-06-30T00:52:30-0f9fa26/fd45e26/openbsd-arm-jsing
2021-06-30T00:52:30-0f9fa26/fd45e26/openbsd-arm64-jsing

The last successful run on these builders was at Go commit f9d5095, which was merged June 29, and the first failure was at Go commit 8a7ee4c (Aug. 2). I'm not sure why the dashboard seems to be missing x/sys logs for all of July (CC @golang/release), but that at least gives a range to bisect.

@4a6f656c, any idea what's up with these failures?

[bcmills]

This test is still failing consistently. If there is some reason it cannot be fixed, it should be skipped.

Note that https://golang.org/wiki/PortingPolicy requires that “[a]t least one developer must be named (and agree) to maintain the port, by making required updates in a timely manner as architecture or operating system requirements change.” If no one is actively maintaining this port, it should be removed.

[bcmills]

This is a release-blocker for Go 1.18 via #11811. It may be resolved by fixing the broken functionality, adding a skip to the test on the affected platform(s), or removing these builders entirely (and dropping support for any ports that become untested as a result).

[heschi]

ping @4a6f656c

[4a6f656c]

(cc @tklauser)

The struct clockinfo changed in the OpenBSD 6.9 release, hence the Clockinfo and SizeofClockinfo in unix/ztypes_openbsd_*.go no longer match up. This would have become visible on the openbsd/arm and openbsd/arm64 builders when they were upgraded to OpenBSD 6.9. Unfortunately, since none of the OpenBSD 386 or amd64 builders are running 6.9 (or now 7.0), it is not visible there.

The easy fix is to regenerate the definitions on a supported release - however, this will obviously mean that it will stop working on 6.8 and earlier (which are no longer supported releases).

[dmitshur]

The easy fix is to regenerate the definitions on a supported release - however, this will obviously mean that it will stop working on 6.8 and earlier (which are no longer supported releases).

This seems reasonable to me. Since OpenBSD 6.8 is not supported, I think it makes to fix this issue by regenerating the definitions so that it works on OpenBSD 6.9+, and skipping the test from running on the current OpenBSD builders that are on 6.8. It will be tested by openbsd-arm*-jsing builders with a supported OpenBSD release, and also by 386/amd64 builders once #48977 is resolved.

(If it were inexpensive to keep both OpenBSD 6.9+ and older versions working, then that's certainly preferable, but it doesn't sound that way, and I don't think we should go out way for an unsupported OpenBSD release in the x/sys/unix package. I think we should also prioritize builders with a supported OpenBSD release over those without.)

Does that sound like a good path forward @4a6f656c?