[SOLVED] - Fix for Kaby Lake vs Amber Lake Hardware Mismatch Mint 20

[h2-1]

Keep in mind that whiskey/comet lake are the same, one of the model steppings IDs both of them, same model number, but other model IDs id each specifically and correctly.

However, since inxi can't resolve Intel's internal psychological problems or failures [your comments roughly confirm that what we are seeing in this 8E model series is something very similar to windows and their 98 / ME junk, ME being released due to failure to deliver consumer W2K on time], I'm satisfied with this solution, where I no longer have to care if intel does this silly stuff, and I will just let users know the microarch name is ambiguous, showing both when both are known, and just showing note: check when inxi wasn't able to make a positive stepping ID, but can guess at the model name anyway just based on the model ID.

So it looks like the solution I came up with is a decent one, inxi is not going to try to resolve Intel's internal problems and failures, and won't care if intel can't make up their minds what a specific model ID/stepping is. It is worth noting that when marketing takes over from engineering, that is rarely a good sign of where a corporation is headed.

I have been totally unable to find the AMD Ryzen family 17 model 18 steppings to differentiate Zen and Zen+ in model 18, unfortunately my main source site does not list the CPUID data with steppings for AMD cpus the way they do for Intels.... and now that I type that, maybe the reason for that is that it's simply in general not necessary with the single exception of the case of the 18 model of zen.

So I'm going to call this good, it removes something that has irked me for a while, when another device line, usually intel graphics, shows a different microarch name than the cpu arch: item shows.

However, comet lake latest shows some signs of improvement, since it's got its own model ID now, and is no longer trapped in the 8E mess.

[h2-1]

By the way, model 55hex suffers a similar microarch / stepping issue, though so far I have not found any actual ambiguities, steppings 5-7 are cascade lake, stepping 8 and maybe > are cooper lake, allegedly, unconfirmed so far, it's too new, and pre 5 are skylake, also not confirmed, but it has to be that. skylake also has model IDs 4E and 5E [skylake-s].

I also found a /sys thing that works for intel but it's got the same exact actual correct id failures as inxi has, but I'm going to use it as a fallback in case a new cpu that is not yet handled by inxi appears on a frozen inxi, or before I learn about it.

Code: Select all

cat /sys/devices/cpu/caps/pmu_name

https://unix.stackexchange.com/question ... mmand-line

as you can see in the comments, that leads to the same exact issues, calling whiskey or kaby lake skylake. this is probably an OEM completed field, and someone probably just is copy/pasting the wrong value in there, or maybe in terms of the real tech, these cpus are all actually pretty much the same, I don't know, don't care.

The new note: check will handle all the ambiguities and known issues, as well as the cases where there's a cascade of tests for a model id ending in a default assignment. This will help correct the case where inxi is pretending to be 'right' when it's actually not accurate, so now it lets people know about the issue.

But I'm using that as a fallback in case of detection failure using the hardcoded rules, mainly for new cpus, or cpus whose model ID isn't available in inxi.

[64bitguy]

I think EAX string still plays here... all of the steppings are listed, even for those China AMD CPUs.

https://en.wikichip.org/wiki/amd/cpuid

https://en.wikichip.org/wiki/intel/cpuid

They do a good job identifying the stepping for every family too.

Like this for Kaby Lake.:

Kaby Lake

Screenshot from 2020-11-17 21-35-39.png (13.92 KiB) Viewed 444 times

And Amber Lake:

Amber Lake

Screenshot from 2020-11-17 21-39-08.png (7.88 KiB) Viewed 444 times

[h2-1]

yes, I use that site, I think I mentioned it upthread, and a few others, for more legacy stuff. But it takes them a while usually to get the cpuid data, you won't generally see that on new cpus. Takes work. And for amd, they don't seem to show steppings, but I suspect that with one exception, amd does not rely on steppings for new microarchitectures, they are new models. Don't be fooled by a cursory overview however, they don't have the steppings for every family/model, there's often gaps, simply because they didn't get the complete data yet, sometimes they forget or don't get data for a long time, it varies.

Going through all the variants is a slow and tedious process, for intel, for example, you have to do the client section, then go down, and fill in from the server section, it's a lot of work to catch up and fill in, I just did that over the last few days, so inxi is now pretty up to date.

I just went through literally ALL the intel items, checked each one, luckily most of them you don't need to go to the details page, since the model/family ID are all you need to locate new or changed or updated stuff. But some you have to cross reference, make sure they got the info right and consistent, change the match tests to update to whatever it is now, etc. It's totally empirical.

I was able to find a single dataset that had the Zen+ model 18, and it was stepping 1, so I'm assuming only stepping 0 was Zen, then it moved to zen+.

If you for example look at cooper lake, you'll see that they currently have not gotten the cpuid data for it yet. I know I found that information somewhere because I list a stepping, but I don't remember where I got that information over the past few days. Sometimes other sources are wrong, I've had that happen too, then I have to wait for wikichips to fill in the missing information for that model, which is also hard to track.

Basically they first list the known or suspected upcoming releases, with no data, then they will fill out a placeholder page with some of the early data, but no cpuid, but you have the model id, which is often enough, but not always, then later, you have to go back and see which sections were updated since your last visit. It's quite tedious to do that since you have to go through many different items to find all the possible variants.Sometimes they will list the steppings they were aware of, but then you have to go back in later, manually, and check each variant again to see if they have added steppings, or gotten more steppings and linked them to more things. It's time consuming, to put it mildly, which is why I don't do it very often.

There used to be a few other sites where I could get very early data, but as I noted previously, those locked down and can't be accessed by the public anymore, but I used to be able to find the upcoming stuff sometimes there.

I can say that currently, as with my primary harddisk model string source, if it were not for that single wikichips site, I would probably have to drop any attempt at supporting cpu microarchitectures, but even as it is, it takes hours for any real update, like I did over the past 2 days, and frequent tweaks now and then as new data appears. This data should be provided by intel, amd, etc, in an easy to locate format and location, it should not be left up to someone who does it probably because they enjoy it for some weird reason.

[64bitguy]

Since inxi can't resolve Intel's internal psychological problems or failures...

Sign me up for the app that does. LOL

It's pretty sad when I have to wait for some guy in China to leak the data from TMSC to find out information that can be queried out of the damn CPU anyway. Stranger yet, as someone that grew up at DEC, I don't understand the unwillingness to make this "obviously it should be published" data "private" or "Proprietary" when in reality, it is so ridiculously neither.

This used to be in the standard spec docs in ARK. Now just asking for it gets looks from Intel people like you're trying to steal their daughter's virginity. Someone mentioned that AMD seems to be acting in a similar manner since the Zen 2 (though I don't have any first hand experience in that regard).

[h2-1]

the site I mentioned that closed its data was some development stuff, it's not related to intel or amd etc, was just some website connected to some tech group or person, no idea whose it was/is, it just happened that they had datasets of raw data available, but then they closed it off at some point, probably because it's proprietary or related to their business model or something, I don't know, it was just a fluke that I ever found it in the first place, might have been something similar to the CIA setting up AWS storage instances and neglecting to apply any security to it, thus allowing anyone to download it all, which has happened several times. In other words, the data was actually never supposed to be public in the first place.

Linux users could obviously help this by just posting their /proc/cpuinfo files in one place, which contain all the data you need, except for the annoying feature of showing the family/model ID in integer, not hex, format, sort of like the linux lite hardware database, which wouldn't exist if linux-lite hadn't made it and keeps it up and running. But that would require coordination and cooperation lol so I guess we can count that one out... "someone else will do it..." I believe is the operative term.

It's also slightly odd that some group that is very invested in cpu stuff doessn't make that type of data available since they have it all from a very early point, the linux kernel project. But much of this data doesn't matter to them I believe in terms of the actual kernel and how it works with various vendor cpus.

In the old days, tech firms took pride in making this type of data very easy to find, since they were run by engineers, who understood why you want somewhere a way to access engineering data in an engineer friendly way, not marketing bs etc.

Re AMD, so far it's been super easy, Zen 3 is its own amd family ID, that will probably get more granular as zen 3 real data appears, but it seems like amd is still following reasonably rational policies when linking microarchitectures with family/model/stepping data, which is kind of obvious to do since marketing should be selling real changes to drive sales, not some rebranding / renaming of the same exact cpu die...

[64bitguy]

the site I mentioned that closed its data was some development stuff, it's not related to intel or amd etc, was just some website connected to some tech group or person, no idea whose it was/is, it just happened that they had datasets of raw data available, but then they closed it off at some point, probably because it's proprietary or related to their business model or something, I don't know, it was just a fluke that I ever found it in the first place, might have been something similar to the CIA setting up AWS storage instances and neglecting to apply any security to it, thus allowing anyone to download it all, which has happened several times. In other words, the data was actually never supposed to be public in the first place.

I really hate is when "Anonymous" keeps CPU datasets secret.. someone should write them a letter.

Linux users could obviously help this by just posting their /proc/cpuinfo files in one place, which contain all the data you need, except for the annoying feature of showing the family/model ID in integer, not hex, format, sort of like the linux lite hardware database, which wouldn't exist if linux-lite hadn't made it and keeps it up and running. But that would require coordination and cooperation lol so I guess we can count that one out... "someone else will do it..." I believe is the operative term.

It's also slightly odd that some group that is very invested in cpu stuff doessn't make that type of data available since they have it all from a very early point, the linux kernel project. But much of this data doesn't matter to them I believe in terms of the actual kernel and how it works with various vendor cpus.

In the old days, tech firms took pride in making this type of data very easy to find, since they were run by engineers, who understood why you want somewhere a way to access engineering data in an engineer friendly way, not marketing bs etc.

I worked at DEC MK1/MK2 R&D Labs in Merrimack. I understand that concept better than most.

Re AMD, so far it's been super easy, Zen 3 is its own amd family ID, that will probably get more granular as zen 3 real data appears, but it seems like amd is still following reasonably rational policies when linking microarchitectures with family/model/stepping data, which is kind of obvious to do since marketing should be selling real changes to drive sales, not some rebranding / renaming of the same exact cpu die...

Except the China stuff. I'm a little flustered by that decision.

At one point, MIT was keeping track.. I can't remember which lab; but there was a DB (I might drive down and see if I can find it)... I think the DB is still there; but the subdomain hosting it went dark. Stanford was keeping track too, in fact they has some really obscure CPUs in their DB; but I think they stopped somewhere around 5 or 6 years ago. Again, sub-domain is probably dark.

I think your comments about data collection are valid. I had a quick idea (thinking) of an inxi flag -send to package and feedback the CPU construct data back to a DB somewhere; but that's just me making more work for ... ahem.. someone unnamed.

[h2-1]

I was wrong about the Zen+ amd, it turned out that family 17, model 18, also can be either Zen or Zen+, I found, by somewhat painful, online searching, two outputs of I think /proc/cpuinfo, then I was able to look up the models, and sadly at least for stepping 1, it could be either Zen or Zen+. That's the only zen cpu that shared that odd ambiguity, but my feeling there since it does not appear to have repeated, is that amd was probably adding features to zen, and then sort of randomly, in model 18, decided to start calling the same die zen+, just guessing.

Inxi has a very good and effective debugger data collector, but it's not really intended for public use, and I'm definitely not going to add more.

I've been rewriting big chunks of pinxi, to resolve some of the oldest bugs and lingering feature requests, and am getting closer to implementing the new -L option, which will, if I can get it working and stable, make for a 3.2.0 release.

I was debating doing a point release because there are so many huge internal and many external changes, but the inxi numbering rule is no major version bumps without a new line item, -L in this case, which isn't ready yet, I have to keep rewriting more of the logic to prepare the guts of inxi to handle that logic. Note that a side benefit of all this refactoring is that even though it's doing more, pinxi is actually running slightly faster than inxi stable. It was running faster, but the latest features I added ended up slowing it down a touch, which is to say, with some large new internal features required to do some advanced disk/block logic, it's _still_ faster than inxi stable.

I believe by the time I have -L done, it will run at roughly the same speed as current stable inxi. I didn't think there was more optimizations left that would create a measurable difference, but I think I got about 4-5% improvement, and that's with new features already added in, now it's less because there are bigger more complex new features that take more processing, but it's still remarkable.

The biggest area changes can be seen are in block devices: partitions, unmounted, raid, drives, and the most obvious new ones are in -R, for mdraid or zfs.

Mint should see these changes in a few years, lol, unless you run pinxi and just call it good.