A few things, I added these in order of coming across the posters, each one starts with the poster name.
There are some issues with cache on some systems, I've noted the tests that might help pinpoint the issue so it can be resolved, if it can be resolved.
Make sure to update pinxi like so: pinxi -U
before testing again, there are many fixes added today.
Massive response, this took a while to get through, many thanks to all. Still some things failing however, so if you can, scan the list for your name and see if more data is required, thanks.
-----------------------------------------
volkerdi, thanks for checking, all the CPU data appears correct.
https://www.cpu-world.com/CPUs/K10/A...ZFBGRBOX).html
Thanks for all the work you've done for Free Software and Linux over the decades.
-----------------------------------------
truepatriot76, a zen 3, nice, one reason for these fixes, besides alder lake, is zen 4 or 5 may have more complex structures, like split L3 cache, still 1 L3 here though I see.
-----------------------------------------
willysr, looks good, caches being handled correctly, boosts, etc, all look good.
-----------------------------------------
JayByrd, I think that maybe there is no /sys cache data available, that's odd, I thought cache was one of the earliest things to be added to the /sys cpu data. But that is coming from I believe cpuid, and maybe the data isn't in the expected format.
Can you check if:
Code:
ls /sys/devices/system/cpu/cpu*/cache
contains anything, I wonder if they changed the paths on these early cpus?
The Info: Single Core model: Intel Celeron system also seems to have similar issues getting the L1 cache correctly. Can you see on that one too if:
Code:
for i in $(ls /sys/devices/system/cpu/{cpu*/topology,cpu*/cpufreq,cpu*/cache/index*,smt}/*);do echo -n "$i::";cat $i;done > cpu-sys.txt
cat /proc/cpuinfo > cpuinfo.txt
gives a better explanation of the L1 cache failures? And checking:
Code:
ls /sys/devices/system/cpu/cpu*/cache
AMD A8-4555M APU with Radeon HD Graphics looks good.
Intel Pentium D you found a bug, pinxi forgot to test if the i and d caches actually exist, that's where the empty value and the error came from, this one only has L1 Data cache, not instruction as well. Good find, that was just sloppy on my part, I assumed if one was there, both would be.
https://www.cpu-world.com/CPUs/Penti...PE2666FN).html
Level 1 cache size ? 2 x 16 KB 8-way set associative data caches
Level 2 cache size ? 2 x 1 MB 8-way set associative caches
model: Intel Xeon 5160
https://www.cpu-world.com/CPUs/Xeon/...5565160P).html
looks good.
-----------------------------------------
drgibbon, it looks like
Code:
CPU: [3/257]
Info: Quad Core
model: Intel Core i7-8565U
bits: 64
type: MT MCP
arch: Kaby Lake
note: check
family: 6
model-id: 8E (142)
stepping: C (12)
microcode: EA
L2 cache: 8 MiB
Is failing to get any cache data, and using the fallback from cpuinfo, which is the L3.
I'd like to see what's going on here, I suspect there is a syntax variant for the cache path.
Code:
for i in $(ls /sys/devices/system/cpu/{cpu*/topology,cpu*/cpufreq,cpu*/cache/index*,smt}/*);do echo -n "$i::";cat $i;done > cpu-sys.txt
cat /proc/cpuinfo > cpuinfo.txt
See if that shows any cache data, if not:
Code:
ls /sys/devices/system/cpu/cpu*/cache
so we can see what's going on, almost certainly a syntax variant I think.
-----------------------------------------
chrisretusn: 42
https://www.linuxquestions.org/quest...ml#post6304845
Code:
Cpinxi -Cazy
CPU:
Info: Quad Core model: AMD Phenom II X4 840 socket: M2 bits: 64 type: MCP
arch: K10 family: 10 (16) model-id: 5 stepping: 3 microcode: 10000C8 cache:
L1: 512 KiB desc: d-4x64 KiB; i-4x64 KiB L2: 2 MiB desc: 4x512 KiB
L3: 512 KiB
Defininitely some type of syntax error, checking raw data logs for this cpu, but I can't find any syntax variants.
Code:
for i in $(ls /sys/devices/system/cpu/{cpu*/topology,cpu*/cpufreq,cpu*/cache/index*,smt}/*);do echo -n "$i::";cat $i;done > cpu-sys.txt
cat /proc/cpuinfo > cpuinfo.txt
might help show the issues there too.
-----------------------------------------
MDKDIO, that's inxi, not pinxi, but that Mobo: ASUSTeK model: PRIME B450-PLUS system should be fine anyway.
The intel I'd like to see a pinxi -Cay1 for to see if that's right:
Code:
CPU:
Info: Dual Core model: Intel U4100
-----------------------------------------
z80, interesting Epyc, pi looks right. You can actually see how much you have been assigned on the Epyc vm, 4 of the cores, with their L1 and L2, so that is working as hoped, that's nice.
Re the MT (Multithreaded) Intel Core i7 870, yes, that's correct, 4 physical cores running 8 threads, which appear to the system as 8 cores.
https://www.cpu-world.com/CPUs/Core_...605I7870).html
The number of CPU cores 4
The number of threads 8
Floating Point Unit Integrated
Level 1 cache size ? 4 x 32 KB 4-way set associative instruction caches
4 x 32 KB 8-way set associative data caches
Level 2 cache size ? 4 x 256 KB 8-way set associative caches
Level 3 cache size 8 MB 16-way set associative shared cache
-----------------------------------------
aus9, long time no see, thanks! However, that's inxi, not pinxi. Should not be much difference, I don't see ryzen presenting any issues how ever.
-----------------------------------------
GazL, yeah, I agree, it would be better to add a line break there. Vulnerabilities:
I'd initially not wanted to do that to save lines, but it is awkward to read the way it is now.
pinxi 3.3.09-15 has that change.
-----------------------------------------
fskmh, Info: Dual Core model: AMD Athlon 64 X2 3800+, AMD Athlon II Neo N36L look good, thanks.
Info: 2x 64-Core model: AMD EPYC 7742, AMD EPYC 7502P, AMD Ryzen 9 5950X, Intel Core i7-6700 also look good.
Intel Core2 Quad Q6600, I was hoping to see one of these, great, that one looks good.
https://www.cpu-world.com/CPUs/Core_...562Q6600).html
-----------------------------------------
OldHolborn, glad you like it, all distros are helpful and welcome.
The old way was actually just some hacks and oddities based on how cache reporting had been done over years in /proc/cpuinfo, that got increasingly random, sometimes some cpus, like amd, report L2 there, but others, like intel, started reporting L3, but not L2 totals, under the 'cache:', I can't understand at all what they were doing or why, and it wasn't fixable, that's why this refactor had to happen.
If you run inxi as root, and you have dmidecode installed, it will use dmidecode values, which tend to be reasonably right, but not granular, just the totals per cpu for L1, L2, and L3. pinxi should be both right and granular, and doesn't need root or dmidecode for this data, at least not once I get a few cache location detection bugs worked out as seen in the above.
That's one of several bugs that were not fixable without this refactor, that's actually the L3, not the L2.
Code:
CPU:
Info: 8-Core model: AMD FX-8350 socket: AM3 bits: 64 type: MCP
arch: Bulldozer family: 15 (21) model-id: 2 stepping: 0 microcode: 6000852
cache: L1: 384 KiB desc: d-8x16 KiB; i-4x64 KiB L2: 8 MiB desc: 4x2 MiB
L3: 8 MiB desc: 1x8 MiB
https://www.cpu-world.com/CPUs/Bulld...20FX-8350.html
Level 1 cache size ? 4 x 64 KB 2-way set associative shared instruction caches
8 x 16 KB 4-way set associative data caches
Level 2 cache size ? 4 x 2 MB 16-way set associative shared exclusive caches
Level 3 cache size 8 MB 64-way set associative shared cache
Note that the incorrect arch: has been corrected in current pinx, it's actually Piledriver.
This cpu was a good example of one inxi was totally incabable of getting right, and also appears to be wrong in dmidecode, which is interesting,
The 2x is very recent, I think that was part of the first partial fix in inxi 3.3.09, but it wasn't a reliable method, and often could get cache wrong since it didn't know how many of each cache type the cpu had, just the size of each of them.
AMD Athlon 64 X2 4600+ looks good. AMD Phenom 9950 looks good.
https://www.cpu-world.com/CPUs/K8/AM...600BVBOX).html
Thanks, no worries, you aren't spamming, this is exactly what I needed to see.
-----------------------------------------
allend, looks like pinxi got the architecture wrong, arch: Nehalem, shouild have been Westmere. Might be intel using either, but I'm assuming it was an oversight in inxi, a small bug. That's corrected in pinxi 3.3.09-16
Otherwise Intel Core i3 M 350 looks good.
Intel Core2 6300 is a good example of the Intel CPUs that inxi was not going to get right without this refactor.
-----------------------------------------
FTIO, thanks, everything is helpful and appreciated. Except that's inxi, not pinxi. Ryzen however tends to be right, so that's not a big deal.
-----------------------------------------
baumei, inxi will not only run fine in slackware 1.4.2, it should run fine in Slackware-9.0, although I've found there were some bugs in super early Perl 5.008, 9.0 shipped with 5.8.0, but inxi basically is designed to run on anything with 5.008 or newer Perl. Me and a few other people will test on very old installs now and then to make sure it all still works.
I test in vm with Debian 3.1 and 4.0, and on real hardware with Debian 5.0, that's a 1998 laptop with Pentium MMX, runs slow, of course, but it runs fine.
However, you also tested with inxi, which isn't as helpful as pinxi since pinxi has all the fixes being tested, inxi will just show the old unfixed logic, which is sometimes right, and sometimes wrong. The goal here is to see if the fixes are working in pinx, which is next inxi.
"According to my understanding, this processor has two cores and each core has two threads. In the output above I see the speeds of the four threads are not all the same. Is it really possible for two threads on a particular core to run at different speeds?"
I don't know the ins and outs of how threads work re speeds
Code:
Speed (MHz): avg: 2627 high: 3900 min/max: 1550/3400 boost: enabled cores:
1: 2875 2: 3900 3: 3860 4: 2596 5: 1458 6: 3871 7: 2216 8: 1373 9: 2513
10: 1375 11: 1597 12: 3890
Those speeds are grabbed and read almost instantly, though there is a small tiny delay between the reads of each speed file since they are sequential and run in a loop to read the speeds, but that loop is incredibly fast, I could actually time it to see how long it takes,though the logging of it probably takes longer than the reading of it by several factors I'd guess since inxi logs to a file when it's debugging itself. I don't know how fast the cpus actually adjust their speeds, but all the debugger actions that run to see these types of speeds are themselves generating cpu use so it's not very accurate. I have a Perl debugger I could use that I think watches mroe from the outside of the program, but that also is using cpu cycles to run, so I don't know how I could get that information accurately, sort of the problem of watching changing the behavior of the watched.
https://www.cpu-world.com/CPUs/Atom/...m%20N2600.html
Level 1 cache size ? 2 x 32 KB 4-way set associative instruction caches
2 x 24 KB 6-way set associative data caches
Level 2 cache size ? 2 x 512 KB 8-way set associative caches
-----------------------------------------
Paulo2, Intel 585 looks good.
and: model: AMD FX-8320E looks good
thanks
"I tried to run inxi/pinxi in an old Pentium 233 but it seems dmidecode didn't find BIOS information.
It was running a severe crippled Slackware 14.1 install due to the 3GB IDE hard drive."
You don't need dmidecode for much data in inxi/pinxi, old hardware I think doesn't have the right dmi table data, or doesn't have it at all, no smbios, but it should run just fine, although very slowly, on a 233 MHz, I run it on a 200 MHz and it runs fine, takes a while to start printing out data, but it does it fine. I do try to optimize the code, which helps, but inxi keeps growing, adding code to handle odd circumstances and bugs and new features, but overall it keeps running ok on that very old hardware.
-----------------------------------------
marav, looks good, thanks
-----------------------------------------
bw42, your PowerPC and RISCV systems exposed a lot of things that really needed improving, many are now running, the overall general RISC support is now much cleaner and better integrated, instead of random tests for arm or mips or whatever, now the tests are usually for risc in general, and for variants when it matters, this is much easier to maintain and keep solid.
The riscv was unexpected, but should show more than it did before, but I have to take a look at its dataset more closely to see what is there to get, there were a a lot of things it probably could have gotten if I had all the switches done the way they are now in pinxi, so you may get more out of it, but you may also get some new bugs, it will depend, that type of device tree data is very tricky and convoluted to work with, sometimes new platforms or devices 'just work', other times they take a lot of debugging.
-----------------------------------------
