BITest v3 1007 running under Linux debian question/problem

[JimB]

Hi, As title says I'm running burnintest v3 rev 1007 under debian squeeze. We were running rev 1004 with good success. Decided to try rev 1007 today and found that the CPU-Maths tests don't report any operations. This works fine in rev 1004 (I can run both revs on the same machine). I loaded the same config file for both and tried from scratch with the same results. All other tests (i.e. graphics, ram, hd etc) seem to be run fine with either rev.

Any ideas?

[Tim (PassMark)]

We can't seem to reproduce this, could you please send us a copy of the config file so we could test it here.

If you go into the test preferences and check the settings for the CPU test is at least one of the test options checked (general purpose, floating point etc)?

[JimB]

We can't seem to reproduce this, could you please send us a copy of the config file so we could test it here.

If you go into the test preferences and check the settings for the CPU test is at least one of the test options checked (general purpose, floating point etc)?

It doesn't seem to matter if I load a configuration or not - the results are the same. Also all options under cpu-maths are checked (by default I believe). I've tried un-checking all but one and it doesn't make any difference. As I said the older version on the same system works fine.

[Tim (PassMark)]

Could you please run BurnInTest in debug mode using the command line parameter -d, start the test, let it run for a minute or two before stopping and exiting BurnInTest and then send us a copy of the debug.log file that is created.

[JimB]

Could you please run BurnInTest in debug mode using the command line parameter -d, start the test, let it run for a minute or two before stopping and exiting BurnInTest and then send us a copy of the debug.log file that is created.

Done - thanks.

[Tim (PassMark)]

Thanks, it appears there is an issue with Debian (32bit build date Sun May 6 04:01:19 2012) not reporting the correct information about the Intel Core2 Quad Q9550, no information about the number of cores, siblings or processor ID is reported. This meant BurnInTest was not starting any CPU test threads.

The 6.0.6 64bit live boot version of Debian does not have the same issue.

For the next build of BurnInTest we'll make some changes so if it detects 0 CPUs/cores a warning message will be logged and at least one test thread started, so the test will still run (though not at full capacity).

[JimB]

Thanks, it appears there is an issue with Debian (32bit build date Sun May 6 04:01:19 2012) not reporting the correct information about the Intel Core2 Quad Q9550, no information about the number of cores, siblings or processor ID is reported. This meant BurnInTest was not starting any CPU test threads.

The 6.0.6 64bit live boot version of Debian does not have the same issue.

For the next build of BurnInTest we'll make some changes so if it detects 0 CPUs/cores a warning message will be logged and at least one test thread started, so the test will still run (though not at full capacity).

Thanks for the help. If I may make a suggestion - see what changed between versions 1005 and 1007 for this test. My version of 1005 appears to run the CPU-Maths tests without any problems. It's only the 1007 version (I never tried 1006) that exhibits this problem. I'd prefer the full functionality I had with 1005 over a limited capacity test.

Thanks again,

Jim

[Tim (PassMark)]

Some changes were made to CPU detection between these builds which could have resulted in 1007 returning a CPU/Core count of 0 while 1005 could have returned CPU/Core count of 1 so 1005 would still not have been running 4 test CPU threads as expected for a quad core CPU.

The Debian version in question is not returning any of the cpuinfo fields we can use to determine how many cores are available (currently we use the physical id and cpu cores fields to determine how many physical CPUs are installed and how many cores they have).

[victorz]

Some changes were made to CPU detection between these builds which could have resulted in 1007 returning a CPU/Core count of 0 while 1005 could have returned CPU/Core count of 1 so 1005 would still not have been running 4 test CPU threads as expected for a quad core CPU.

The Debian version in question is not returning any of the cpuinfo fields we can use to determine how many cores are available (currently we use the physical id and cpu cores fields to determine how many physical CPUs are installed and how many cores they have).

I am also not seeing any CPU tests run under 1007 with a Celeron 440 CPU, below is the log file output. System is running 64 bit CentOS 5.x


PassMark BurnInTest Log file - http://www.passmark.com
================================================== ======

BurnInTest v3.0 (1007) Linux 64bit
Logging detail level: Normal

******************
SYSTEM SUMMARY
******************
Linux 2.6.18-274.7.1.el5
0 x Intel(R) Celeron(R) CPU 440 @ 2.00GHz
1.0 GB RAM

GENERAL
System Name: sa2500
Motherboard Manufacturer: Supermicro
Motherboard Model: PDSMP-JN1
Motherboard Version: PCB Version
Bios Manufacturer: Phoenix Technologies LTD
Bios Version: 1.13
Bios Release Date: 10/06/2008

CPUCPU Manufacturer: GenuineIntel
CPU Type: Intel(R) Celeron(R) CPU 440 @ 2.00GHz
Speed: 1995.0 MHz
CPUID: Family 6, Model 22, Stepping 1
Socket: LGA775/U1
Physical CPU's: 0
Cores per CPU: 1
Hyperthreading: No
CPU Features: MMX SSE SSE2 SSE3 PAE
Cache per CPU package:
L1 Cache: 16 kB
L2 Cache: 512 kB

[Tim (PassMark)]

There is an updated build now ready for download from http://www.passmark.com/ftp/bitlinux3.0.1008.tar.gz, if the number of CPUs cannot be detected then at
least 1 CPU thread will be started and a warning will be added to the log.

Could you please post the cpuinfo for your CPU (cat /proc/cpuinfo) so we can see why BurnInTest isn't calculating the correct number of test threads to start.

[victorz]

Here is the cpuinfo.

# cat /proc/cpuinfo
processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 22
model name : Intel(R) Celeron(R) CPU 440 @ 2.00GHz
stepping : 1
cpu MHz : 1994.997
cache size : 512 KB
fpu : yes
fpu_exception : yes
cpuid level : 10
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss tm syscall nx lm constant_tsc up pni monitor ds_cpl tm2 ssse3 cx16 xtpr lahf_lm
bogomips : 3989.99
clflush size : 64
cache_alignment : 64
address sizes : 36 bits physical, 48 bits virtual
power management:

[victorz]

There is an updated build now ready for download from http://www.passmark.com/ftp/bitlinux3.0.1008.tar.gz, if the number of CPUs cannot be detected then at
least 1 CPU thread will be started and a warning will be added to the log.

Could you please post the cpuinfo for your CPU (cat /proc/cpuinfo) so we can see why BurnInTest isn't calculating the correct number of test threads to start.

Thank you! build 1008 works for my CPU test now.

[JimB]

Thank you! build 1008 works for my CPU test now.

It works for me as well - Thanks!