Reported via http://libcpuid.sourceforge.net/bugreport.php
The test in particular has no brand string, which was causing the
misdetection (as is the case with a lot of other models, libcpuid
relies on accurate brand string being programmed by the BIOS in
order to do the detection).
The actual CPU was a Pentium-III based Celeron (SL54Q), but it
was detected as "Pentium III (Coppermine)".
A bit of historical trivia: for the related Tualatin models, if
the BIOS doesn't enter a brand string, there might be NO WAY to
tell a regular P-3 and a P-3 Celeron apart: P-3s have variants
with 256KiB and 512KiB L2 cache, while the Celerons are 256 KiB, so
a 256KiB regular P3 is no different than its corresponding Celeron.
Only the FSB is different, but there's no way to detect this via
CPUID.
For the Coppermines its an easier case: Celerons are always 128KiB,
and Pentia are 256KiB, so I've added this distinction in the tables.
Add support for detecting Coffee Lake i[357]s. Test included.
Thanks to @X0rg for reporting and to @exdeus for the raw cpu data.
The detection here relies on Kaby and Coffee lakes having different
number of cores for the equivalent brand:
i3: 2 cores in Kaby, 4 in Coffee
i5 and i7: 4 cores in Kaby, 6 in Coffee.
Add support for detecting RDSEED and ADX instructions.
Use RDSEED instead of RTM to ascertain that the CPU is
Broadwell or later in recog_intel.c. This fixes
detection discrepancies on Linux, where RTM is not
made available (I guess there's no kernel support for it).
The two new flags are also now detected in the Broadwell
and Skylake tests. Update them as well.
Improved parsing of brand strings for both Pineview and Cedarview
Atoms.
Add tests for both the Pineview Atom, and also Broadwell-E
(forgotten in a previous commit).
The test is a snapshot of a Haswell i7 (a.k.a. "Crystalwell") core.
This is the only test in the test DB right now which has lines for
L4 cache size, associativity and cacheline size different than "-1".
Also update create_test.py to accommodate for the new fields.
According to wikipedia, cpu-world and some cpu-z screenshots, these processors
do have a code name and it's willamette, northwood, prescott or cedar mill
Signed-off-by: Veselin Georgiev <anrieff@gmail.com>
The reason was that the invocation of the cpuid_tool through the makefile
was using LD_LIBRARY_PATH=. to force link&use of the latest-build libcpuid
library. This doesn't seem to work, so using LD_PRELOAD to explicitly load
libcpuid.so into cpuid_tool.
The committed approach of course doesn't work on Mac OS X, where
make test-old should be used.
Priously all fields in the matchtable were treated equal in importance.
With this change, the cache size a taken with half the weight in the decision.
Also add detection entries for some more recent Haswells, and the respective
tests. These are an i5 Haswell from a Mac Book Pro, and a i7 Haswel from
Thinkpad T540.
- Detect AVX and AVX2 on both Intel and AMD CPUs
- Detect BMI1 and BMI2 instruction sets (BMI2 is only on Haswell, BMI1 is
also present on Bulldozers).
- Fix tests to reflect changes.
The last change to flags detection caused a bunch of tests to fail.
The reason is that they are bogus, all recent Intel chips don't have
RDTSCP indicated in the test files, whereas they have it in reality.
I figured it will be easier to add "--fix" option to run_tests.py,
rather than fixing each testfile by hand.
This is also extended in the Makefile:
"make test" runs the tests and reports discrepancies.
"make fix-tests" fixes any offending tests. This blindly assumes that
libcpuid is sane.
- Atom Dual-core (Diamondville) is renamed to just Atom (Diamondville)
- The test with Atom D425 is named "Pineview", while the one with
Atom D525 was incorrectly named "Cedarview". Moving the latter to
atom-pineview-2.test and fixing its codename.
