Note that I think some are using inxi 3.3.09 which had a rough patch fix to get the caches right, otherwise we'd be seeing a lot more wrong caches from inxi, basically 3.3.09 and 3.3.10 are 2 parts of the same release process, only most of the extra hacks in 3.3.09 were dropped completely in favor of the real solution which is now running in pinxi. But the hack fix actually did correct some cache ids that were failing before, and there was another crude fix for another issue you won't generally see unless you are runinng virtualized servers, wrong core counts.
Basically as I saw the failure cases for cache roll in, I realized that the old hacks to guess, sometimes with success, at L2 cache, were just not going to cut it now that we have a better method, so those are rolled back, and if cpuinfo only shows 'cache size:' then inxi isn't going to try to guess at what type of cache it is, it's just going to be treated as an anoynmous cache type, no math except for physical cpu multiplication will be done on it. Basically as these examples showed me, if only cache size: shows, that can be L1, L2, or L3, and zero way to know what is what. That's a big reason I did the refactor in the first place, this was only going to get worse.
these updates are all in pinxi 3.3.09-20. Seems closer, but still a few worrying cases that should not be there. The cache fix may have corrected some of those I think, when inxi is simply guessing wrong.
-----------------------------------------
drgibbon, your failure case is concerning, however, that looks like inxi output, not pinxi current. Confirm, your data looked good and produced the correct output. I'm guessing in this case it's inxi, not pinxi, since that has two of the bugs that inxi had, wrong arch: and L2 cache from L3.
-----------------------------------------
mlangdn, model: AMD FX-6300 looks great, this was a case inxi would almost get wrong for cache, now it 'just works', exactly as hoped. Thanks for confirming.
https://www.cpu-world.com/CPUs/Bulld...20FX-6300.html
Level 1 cache size ? 3 x 64 KB 2-way set associative shared instruction caches
6 x 16 KB 4-way set associative data caches
Level 2 cache size ? 3 x 2 MB 16-way set associative shared exclusive caches
Level 3 cache size 8 MB 64-way set associative shared cache
-----------------------------------------
aus9, a small glitch in the arch detection, that was supposed to be:
arch: zen/zen+
because model 18 is ambiguous and I have not seen enough data on it to confirm. Yours is zen+ however, stepping 1. I read that there was a sort of marketing change without a corresponding stepping change, similar to what Intel did a lot of prior to getting Alder Lake shipped. I've corrected that one, that was a small glitch in the ID.
Rest of data looks good, correction will be in 3.3.09-19
-----------------------------------------
Eeel, great stuff, thanks. All 3 are reporting correctly.
-----------------------------------------
MDKDIO, -z option to filter. Looks like I had the architecture name slightly
wrong, it's actually Core Penryn, updated that. Otherwise looks good.
-----------------------------------------
chrisretusn, odd data, can you run:
Code:
pinxi -Ca --dbg 39 --dbg 8 > cpus-dbg.txt
and paste the output somewhere? Like pastebin.com or something. Something definitely glitched with the L3 data there.
https://www.cpu-world.com/CPUs/K10/A...40WFK42GM.html
Level 1 cache size ? 4 x 64 KB 2-way set associative instruction caches
4 x 64 KB 2-way set associative data caches
Level 2 cache size ? 4 x 512 KB 16-way set associative exclusive caches
Level 3 cache size None
-----------------------------------------
JayByrd, thanks for confirming on AMD K6-2, no /sys cache data in there.
The problem there is actually one of cpuinfo being too vague, and failing to differentiate the cache type. It did do that in the past, and Elbrus does it fine today, l1, l2, l3 all reported correctly and separately.
Problem here is that inxi just can't know what the cache is if it just says cache: in proc/cpuinfo. I'm going to call this one unfixable, unfortunately. The assumption was that CPU cache reported, in the past prior to L3 being a thing, was always L2, but this cpu only has L1, so that's what it reports. that's the problem of using vague imprecise field names in data sources unfortunately, so that one I will mark as not fixable. Possible option is to just change L2 to 'cache' in cases where no explicit l1 l2 l3 was detected. I think that is how inxi used to do it by the way, a long time ago. That's probably safest I think.
I realized that it is imply not possible to dynamically 'know' what the 'cache size: ' field in cpuinfo is referring to, so inxi is not going to guess on that anymore, it will just show as 'cache: [cache size]' without any math, no per core/processor logic, except physical cpu since that always refers to only one physical cpu's cache.
This is surrendering, that is, that data source is just not good enough, but all newer systems will have the very good /sys cache data, and will be extremely accurate, but those attempts to force random cache to be L2 aren't working.
this also is going to be a different output value, if you see 'cache:' now with a cache size and no L2 listed, it means inxi has no idea of what it is, and isn't going to try to guess. Those guesses were often wrong anyway.
-----------------------------------------
bw42, the undefined value errors should be fixed in 3.3.09-20. That was just an oversight, forgot to assign a value when I refactored the internal risc error detections. But looks pretty good otherwise, excellent for that being the first riscv inxi has ever run on that I'm aware of.
When you see in
Network:
Device-1:
...
IF:
IF:
that means it's really working internally, it's succesfully matching the IF to the device.
IF-ID means it couldn't, but that looks exactly right in this case, which is a good sign.
I believe the errors should be gone if you run it again.
-----------------------------------------
baumei, looks good, thanks.
Max processor speed is a value that the system provides to inxi, it just takes whatever it is given and shows it.
Intel Core2 Quad Q8300 is a good example of inxi getting cache wrong, and pinxi right. That core duo quad was actually one I knew inxi could never get right without the refactor.
-----------------------------------------
