Hide Forgot
Description of problem: cpuscaling took too much time and finally the beaker job watchdogged on a Westmere-EX machine with RHEL5.7 i386 arch. https://beaker.engineering.redhat.com/recipes/310933 http://beaker-archive.app.eng.bos.redhat.com/beaker-logs/2011/10/1491/149141/310933/3410206/TESTOUT.log https://beaker.engineering.redhat.com/recipes/308845 http://beaker-archive.app.eng.bos.redhat.com/beaker-logs/2011/10/1481/148133/308845/3386579/TESTOUT.log Version-Release number of selected component (if applicable): v7-1.4-36 How reproducible: Not sure. Above 2 beaker jobs produced the issue on the same machine intel-sunriseridge-02.lab.bos.redhat.com. Seemingly often. Steps to Reproduce: 1. 2. 3. Actual results: Expected results: cpuscaling can succeed. Additional info: I'll try other Westmere-EX machines.
WSM-EX systems has too many CPUs, thus it's not a bug, I just increased the testing time.
The package data looks like rubbish on that box. It shows every core as being in it's own package which is incorrect. I've seen -xen do this, but the baremetal kernel should not. <snip> package 210 has cpus: 27 package 194 has cpus: 19 package 178 has cpus: 29 package 192 has cpus: 3 package 114 has cpus: 30 package 130 has cpus: 17 package 64 has cpus: 2 package 66 has cpus: 18 <snip> E7-4870 is a 10 core with hyperthreading or 20 cores in one package. This also caused it to fail the tests as the package cores need to be changed in sync to have the desired effect.
Re-open it... do some more investigation and see which component is suitable for this bug... seen on intel-sunriseridge-02.lab.bos.redhat.com, RHEL5 i386 https://beaker.engineering.redhat.com/recipes/315218 https://beaker.engineering.redhat.com/recipes/310933 RHEL5 x86_64 seems have correct packages: CPU 0 Model: Intel(R) Xeon(R) CPU E7- 4870 @ 2.40GHz System has 80 cpus package 1 has cpus: 78, 74, 70, 66, 62, 58, 54, 50, 46, 42, 38, 34, 30, 26, 22, 18, 14, 10, 6, 2 package 0 has cpus: 76, 72, 68, 64, 60, 56, 52, 48, 44, 40, 36, 32, 28, 24, 20, 16, 12, 8, 4, 0 package 3 has cpus: 79, 75, 71, 67, 63, 59, 55, 51, 47, 43, 39, 35, 31, 27, 23, 19, 15, 11, 7, 3 package 2 has cpus: 77, 73, 69, 65, 61, 57, 53, 49, 45, 41, 37, 33, 29, 25, 21, 17, 13, 9, 5, 1
RHEL6 is normal as well: CPU 0 Model: Intel(R) Xeon(R) CPU E7- 4870 @ 2.40GHz System has 32 cpus package 1 has cpus: 2, 6, 10, 14, 18, 22, 26, 30 package 0 has cpus: 0, 4, 8, 12, 16, 20, 24, 28 package 3 has cpus: 3, 7, 11, 15, 19, 23, 27, 31 package 2 has cpus: 1, 5, 9, 13, 17, 21, 25, 29
Recently cpuscaling was local watchdogged on intel-s3e37-01.rhts.eng.rdu.redhat.com with RHEL5.8-Server-20111121.0_nfs-i386 baremetal kernel: https://beaker.engineering.redhat.com/recipes/349303 Also, package data is abnormal: <snip> CPU 0 Model: Intel(R) Xeon(R) CPU E7- 4870 @ 2.40GHz System has 32 cpus package 210 has cpus: 27 package 194 has cpus: 19 package 178 has cpus: 29 package 192 has cpus: 3 package 114 has cpus: 30 package 130 has cpus: 17 </snip>
intel-s3e37-01.rhts.eng.rdu.redhat.com has 40 cores according to beaker; likely this is expected behavior as the kernel doesn't have full control of all of the system cores.
So those package data of intel-sunriseridge-02.lab.bos.redhat.com in comment 0 are also expected and acceptable for lack of full control of all system cores, right? If so, close it NOTABUG?