Description of problem: The clock-test.sh test from the CORE2 suite is breaks when it hits the 54'th CPU. It appears the actual bug may be in the taskset utility. I will investigate more deeply but am filing this now as documentation. Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. try taskset with 2^54 (bitmask with 54th bit set) on 64 bit system 2.taskset 18014398509481984 echo hello 3. Actual results: sched_setaffinity: Invalid argument Expected results: Additional info:
Looks like the best fix for the test (avoid what appears to be a taskset bug and also make for a much cleaner script) is to change clock-test.sh old: cur_time=$(/usr/bin/taskset $((2**$cpu)) bash -c "$nanotime") new: cur_time=$(/usr/bin/taskset -c $cpu bash -c "$nanotime") I have another test running now so I cannot verify there are no other issues yet but I will ASAP. - Doug
Unfortunately the -c option to taskset is not available in RHEL3, but we can use this for RHEL4. This is only a problem for RHEL3 if we support more than 32 cpus there. I will investigate that.
I am attaching a suggestion for the replacement of the clock-test.sh script. This is a C program that should be more accurate. The test runs much faster since it does not require a "sleep" between each iteration. This allows it to see if the clocks accross the system are mostly in-sync at the same time. It will need some cleaning up before being used as a real test. Mostly it will need to be generalized for more than 64 cpus. I have run this on my 64cpu ia64 system.
Created attachment 125479 [details] suggestion for replacement of clock-test.sh
Created attachment 125502 [details] updated clocktest.c Updated to use clock_gettime instead of gettimeofday as suggested by wwoods. Note that this must be compiled with -lrt since clock_gettime lives in the real-time lib.
Created attachment 125560 [details] modified clocktest.c This is a modified clocktest.c that can be built on RHEL3. It also checks all processors on each pass, and calculates the jitter as the difference between the minimum and maximum time value found. Does this work on your system?
An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on the solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHBA-2006-0284.html
An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on the solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHBA-2006-0278.html