CPU Clocktest Failed on HPE XD 665

[mreed8855]

Bug Description

On the HPE XD 665, the clocktest failed with the following error:

Testing for clock jitter on 96 cpus
sched_setaffinity: Invalid argument

There is a similar issue on the S390 but its unknown if they are related.

#422

To Reproduce

1. Install certification-canonical-server
2. Certify-2204

Environment

22.04.2
5.15.0-87-generic

Relevant log output

Error message:

Testing for clock jitter on 96 cpus
sched_setaffinity: Invalid argument

Additional context

There is a private bug opened for this issue: https://bugs.launchpad.net/hp/+bug/2042033

[bladernr]

Need to add info about the CPUs in use here. This failed on s390 for architecture reasons. But this works on any other amd64 CPUs. So which CPUnamd which CPU family as a start.

Then we need someone to look at the fairly simple source code and understand what the deal is with sched_setaffinity on this particular platform.

[rodwsmith]

IBM claims to have found the problem, and a solution. Here's their explanation:

Hi, thanks for the pointer to the source code. I figured out what is wrong.

The test program retroeves the number of cpus using "num_cpus = sysconf(_SC_NPROCESSORS_CONF);". After an
upstream change in the kernel between 22.04 and 24.04, this returns now the number of physical cpus available.
But these cpus do not need to be available to the system right now. Looping over num_cpus, the call to
sched_setaffinity results in an error EINVAL which is explained with:

EINVAL The affinity bit mask mask contains no processors that are currently physi‐
cally on the system and permitted to the thread according to any restrictions
that may be imposed by cpuset cgroups or the "cpuset" mechanism described in
cpuset(7).

The correct way to retrieve the available number of cpus would be "num_cpus = sysconf(_SC_NPROCESSORS_ONLN);", as described here:

man sysconf

• _SC_NPROCESSORS_CONF
  The number of processors configured. See also get_nprocs_conf(3).

• _SC_NPROCESSORS_ONLN
  The number of processors currently online (available). See also get_nprocs_conf(3).

With that change the test program runs as expected, and returns the following output:

root@a35lp52:# gcc clocktest.c
root@a35lp52:# ./a.out
Testing for clock jitter on 16 cpus
PASSED: largest jitter seen was 0.000385

Testing clock direction for 5 minutes...
PASSED: Iteration 0 delta: 0.000099
PASSED: Iteration 1 delta: 0.000096
PASSED: Iteration 2 delta: 0.000059
PASSED: Iteration 3 delta: 0.000055
PASSED: Iteration 4 delta: 0.000065
clock direction test: sleeptime 60 sec per iteration, failed iterations: 0

This is from their certificate request:

https://certification.canonical.com/certificates/2407-15938/

I haven't dug into the source code myself, but this looks like enough information to implement a fix.

[syncronize-issues-to-jira]

Thank you for reporting us your feedback!

The internal ticket has been created: https://warthogs.atlassian.net/browse/CHECKBOX-1534.

This message was autogenerated

[Hook25]

We have decided to clean up our issue tracker to systematize our approach to backlog grooming and planning. If this issue is still relevant to you, please reopen it and tag one of the maintainers or reach out on ~Checkbox on Mattermost. Going forward all issues that have received no activity for more than a year will be marked as 'stale' and closed after one week