Description of problem: CORE2 Parsing error with RHEL4 U2 (x86_64), on a 4x2.20, 32GB memory, AMD-64 processor Version-Release number of selected component (if applicable): rhr2-2.0-1.EL4 How reproducible: always Steps to Reproduce: 1. Run CORE2 on 4-way 32-GB AMD64 system 2. wait for "Watching the system clock for 600 seconds." 3. watch all the parse errors that follow. Actual results: [root@RHCert-test 0]# more output.log + automated_CORE2 + /usr/share/rhr/external/clock-test.sh Watching the system clock for 600 seconds. /usr/bin/taskset: invalid option -- c (standard_in) 1: parse error (standard_in) 1: illegal character: : (standard_in) 1: parse error (standard_in) 1: illegal character: | (standard_in) 1: parse error (standard_in) 1: parse error (standard_in) 1: parse error (standard_in) 1: parse error (standard_in) 1: illegal character: T (standard_in) 1: illegal character: : (standard_in) 1: parse error (standard_in) 1: parse error (standard_in) 1: illegal character: Y (standard_in) 1: illegal character: : (standard_in) 1: parse error (standard_in) 1: illegal character: O (standard_in) 1: illegal character: : (standard_in) 1: parse error Expected results: Test runs to completion Additional info: Reproduceable on multiple AMD64-based systems.
Please run: bash -x /usr/share/rhr/external/clock-test.sh &> clock-test.log & sleep 5; kill %1 and attach the output file to this bug.
Created attachment 123935 [details] Log of clock-test from CORE2 test RHEL3 Upd 4 Please Note: that this was observed on an egenera pblade with RHEL 3 Upd, and reproduced on a AMD64 whitebox running RHEL3 Upd 3. Mike Gahagan requested the info in the included log file. Here is the output from an egenera pblade running RHEL4 Upd 2: more clock-test.log + LIMIT=600 ++ grep '^processor' /proc/cpuinfo ++ wc -l + NUM_CPUS=8 + nanotime='date "+%s+(%N/1000000000)" | bc -l' + echo 'Watching the system clock for 600 seconds.' Watching the system clock for 600 seconds. ++ eval date '"+%s+(%N/1000000000)"' '|' bc -l +++ date '+%s+(%N/1000000000)' +++ bc -l + cur_time=1138738030.60730400000000000000 + (( s=0 )) + (( s < LIMIT )) + sleep 1 + cpu=0 + prev_time=1138738030.60730400000000000000 ++ /usr/bin/taskset 1 bash -c 'date "+%s+(%N/1000000000)" | bc -l' + cur_time=1138738031.61461700000000000000 ++ echo 1138738031.61461700000000000000 - 1138738030.60730400000000000000 - 1 ++ bc -l + jitter=.00731300000000000000 ++ echo '(-1.1<.00731300000000000000) && (.00731300000000000000<1.1)' ++ bc -l + '[' 1 == 0 ']' + (( s++ )) + (( s < LIMIT )) + sleep 1 + cpu=1 + prev_time=1138738031.61461700000000000000 ++ /usr/bin/taskset 2 bash -c 'date "+%s+(%N/1000000000)" | bc -l' + cur_time=1138738032.62658200000000000000 ++ echo 1138738032.62658200000000000000 - 1138738031.61461700000000000000 - 1 ++ bc -l + jitter=.01196500000000000000 ++ echo '(-1.1<.01196500000000000000) && (.01196500000000000000<1.1)' ++ bc -l + '[' 1 == 0 ']' + (( s++ )) + (( s < LIMIT )) + sleep 1 + cpu=2 + prev_time=1138738032.62658200000000000000 ++ /usr/bin/taskset 4 bash -c 'date "+%s+(%N/1000000000)" | bc -l' + cur_time=1138738033.63763900000000000000 ++ echo 1138738033.63763900000000000000 - 1138738032.6265820
(In reply to comment #2) > Created an attachment (id=123935) [edit] > Log of clock-test from CORE2 test RHEL3 Upd 4 > > Please Note: that this was observed on an egenera pblade with RHEL 3 Upd 4, and > reproduced on a AMD64 whitebox running RHEL3 Upd 3. > > Mike Gahagan requested the info in the included log file. > > Here is the output from an egenera pblade running RHEL4 Upd 2: > > more clock-test.log > + LIMIT=600 > ++ grep '^processor' /proc/cpuinfo > ++ wc -l > + NUM_CPUS=8 > + nanotime='date "+%s+(%N/1000000000)" | bc -l' > + echo 'Watching the system clock for 600 seconds.' > Watching the system clock for 600 seconds. > ++ eval date '"+%s+(%N/1000000000)"' '|' bc -l > +++ date '+%s+(%N/1000000000)' > +++ bc -l > + cur_time=1138738030.60730400000000000000 > + (( s=0 )) > + (( s < LIMIT )) > + sleep 1 > + cpu=0 > + prev_time=1138738030.60730400000000000000 > ++ /usr/bin/taskset 1 bash -c 'date "+%s+(%N/1000000000)" | bc -l' > + cur_time=1138738031.61461700000000000000 > ++ echo 1138738031.61461700000000000000 - 1138738030.60730400000000000000 - 1 > ++ bc -l > + jitter=.00731300000000000000 > ++ echo '(-1.1<.00731300000000000000) && (.00731300000000000000<1.1)' > ++ bc -l > + '[' 1 == 0 ']' > + (( s++ )) > + (( s < LIMIT )) > + sleep 1 > + cpu=1 > + prev_time=1138738031.61461700000000000000 > ++ /usr/bin/taskset 2 bash -c 'date "+%s+(%N/1000000000)" | bc -l' > + cur_time=1138738032.62658200000000000000 > ++ echo 1138738032.62658200000000000000 - 1138738031.61461700000000000000 - 1 > ++ bc -l > + jitter=.01196500000000000000 > ++ echo '(-1.1<.01196500000000000000) && (.01196500000000000000<1.1)' > ++ bc -l > + '[' 1 == 0 ']' > + (( s++ )) > + (( s < LIMIT )) > + sleep 1 > + cpu=2 > + prev_time=1138738032.62658200000000000000 > ++ /usr/bin/taskset 4 bash -c 'date "+%s+(%N/1000000000)" | bc -l' > + cur_time=1138738033.63763900000000000000 > ++ echo 1138738033.63763900000000000000 - 1138738032.6265820
Okay, it looks like taskset 1.3.0 (in RHEL3) needs different arguments from taskset 1.4.0 (in RHEL4). clock-test.sh does not work properly on RHEL3 *but* still returns success. I will attach a fixed clock-test.sh shortly.
Created attachment 123995 [details] fixed clock-test.sh This should work properly on RHEL3 and RHEL4 (tested on i386)
I installed the fixed clock-test.sh on my RHEL3 U4 pblade and it looks like its fixed. Thanks. Any estimates when the hwcert kit will be respun to pick this up? We're automating the set up and it will require re-work later to use this workaround now.
We anticipate releasing updated errata this month, depending on how testing goes. Thanks for the bug report!
fix confirmed.
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
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