This is a release-blocker for Go 1.18 via #11811.

--- FAIL: TestIoctlGetRTCWkAlrm (0.00s)
    syscall_linux_test.go:121: failed to perform ioctl: invalid argument
FAIL
FAIL	golang.org/x/sys/unix	0.589s

Given the timing of the first recent failures, I suspect that CL 340369 may be related (CC @mdlayher , @tklauser).

That CL changed ioctls related to ifreq, but the failing test doesn't involved such an ioctl. I suspect it's rather CL 340915 which may be related.

If this syscall is not supported on linux-ppc64le, then the test should be skipped on that platform.

AFAIK that syscall should be supported on linux-ppc64le and it previously worked without problems.

CL 340915 changed the way pointer arguments are passed to Syscall and incidentially on linux/ppc64le (and linux/ppc64), Syscall` is not implemented in assembly as on other platforms, see

https://github.com/golang/sys/blob/437939a70204d143b964abe4ee5e6662d973a384/unix/syscall_unix_gc_ppc64x.go#L14-L16

I suspect this might lead to problems considering the following in unsafe.Pointer docs:

The compiler handles a Pointer converted to a uintptr in the argument list of a call to a function implemented in assembly by arranging that the referenced allocated object, if any, is retained and not moved until the call completes, even though from the types alone it would appear that the object is no longer needed during the call.

see https://pkg.go.dev/unsafe#Pointer, point (4).

This specific implementation of Syscall and related functions for linux/ppc64{,le} was added in CL 146518 for #16662. /cc @laboger

The first failure in the August logs was from CL 340369, which was just before CL 340915 was merged.

I'm afraid we are beyond my area of expertise here. I'm not sure how 340369 could have impacted an unrelated ioctl call which does not use ifreq under the hood.

We'll take a look.

I did a few experiments on some systems and I think this is kernel related. I didn't see any failures on power8, only power9 just
as on the dashboard. I have one power9 where I can make it fail consistently:
(4.18.0-305.3.1.el8_4.ppc64le #1 SMP Mon May 17 10:03:20 EDT 2021 ppc64le ppc64le ppc64le GNU/Linux)

and another where it passes consistently:
(4.15.0-91-generic #92-Ubuntu SMP Fri Feb 28 11:08:26 UTC 2020 ppc64le ppc64le ppc64le GNU/Linux)

Could there have been a kernel update on the power9 builder systems recently?

On the system where it fails the strace shows this:
ioctl(3, RTC_WKALM_RD, 0xc0001d4e90) = -1 EINVAL (Invalid argument)

When it passes I see this:
ioctl(3, RTC_WKALM_RD, {enabled=0, pending=0, time={tm_sec=0, tm_min=0, tm_hour=0, tm_mday=1, tm_mon=0, tm_year=70, ...}}) = 0

Almost like the first one doesn't like the pointer argument.

I think the rtc alarm ioctls return EINVAL if the device does not support an alarm feature. I think the generic PPC rtc driver is one such case. Should the test be ignored in these cases?

Change https://golang.org/cl/352090 mentions this issue: unix: skip TestIoctlGetRTCWkAlrm if unsupported