Apollo lake support for Centos 6.8

Issues related to hardware problems
User avatar
TrevorH
Site Admin
Posts: 33191
Joined: 2009/09/24 10:40:56
Location: Brighton, UK

Re: Apollo lake support for Centos 6.8

Post by TrevorH » 2017/03/14 14:23:52

The cpu capabilities will be determined by running the cpuid instruction and looking at the bitmap of supported things like aesni. It won't make any difference if the "unsupported cpu" message comes out, it still looks at the flags to determine what it can use and aesni is one of those.

Using VT-d is not something for the faint of heart and virtio without VT-d comes close to real hardware speeds anyway.
The future appears to be RHEL or Debian. I think I'm going Debian.
Info for USB installs on http://wiki.centos.org/HowTos/InstallFromUSBkey
CentOS 5 and 6 are deadest, do not use them.
Use the FAQ Luke

Observation2017
Posts: 6
Joined: 2017/03/14 12:36:15

Re: Apollo lake support for Centos 6.8

Post by Observation2017 » 2017/03/14 15:20:03

Good reminder on CPUID.

I would say case closed except the original poster said that CPUID thing had apparently failed in this case for some features like AES. I did verify Ark says AES supported. If I had not seen several reviews also say AES was present and tested, I might say Intel ARK is wrong. I have had to notify Intel engineers before that Ark was wrong on an obsolete part (just once).

And I have seen that sort of comment before about CPUID needing update a few times in the past. Not blaming the code so much as Intel maybe making a minor CPUID format change to which the code has not yet been adapted.

Saw a couple references that I cannot confirm about this being an Atom architecture CPU slippping into "mainstream" line. Which if true might account for a CPUID code detection failure.

Any case that murkiness was why I was wonder if CentOS (or any important mainstream *NIX family distribution) had picked up official support.

P.S. Oh yeah VT-d is not full speed by far. But I have also heard that it can be faster than some emulations, especially compared to when you misconfigured your VMsand VM support due to thinking you had VT-d but its not enabled. Or am I wrong and misconfiguration cannot slow you down? That would be nice.

Observation2017
Posts: 6
Joined: 2017/03/14 12:36:15

Re: Apollo lake support for Centos 6.8

Post by Observation2017 » 2017/03/14 15:23:10

Just sounded to me like the original poster was configured to try to use VT-d. Not crucial to me. Not even going to start by running pfsense as a VM. Just hoping AES enabled was gonna leak from CentOS to BSD to Pfsense.

User avatar
TrevorH
Site Admin
Posts: 33191
Joined: 2009/09/24 10:40:56
Location: Brighton, UK

Re: Apollo lake support for Centos 6.8

Post by TrevorH » 2017/03/14 16:02:31

You can only look at /proc/cpuinfo for the flags line to see what is supported. The cpuid instruction is a hardware machine instruction executed by the cpu and returns the capabilities of that cpu. It can't be changed by the o/s as it's unprivileged and anyone can run it. These days even VirtualBox passes the aes flag through to the VMs run by it (new in 5.1 I believe).
The future appears to be RHEL or Debian. I think I'm going Debian.
Info for USB installs on http://wiki.centos.org/HowTos/InstallFromUSBkey
CentOS 5 and 6 are deadest, do not use them.
Use the FAQ Luke

Observation2017
Posts: 6
Joined: 2017/03/14 12:36:15

Re: Apollo lake support for Centos 6.8

Post by Observation2017 » 2017/03/14 17:08:59

Understood that CPUID is hardware instruction for x86 family architectures. But I was referring to reading the flags returned. Even for x86 there are Once in blue moon changes in how CPUID returns flags. https://en.wikipedia.org/wiki/CPUID

The J3355 is Atom/ARM architecture NOT true x86 family -- even though Intel is branding J3355 as Celeron. Thus CPUID hardware instruction probably does not exist. http://www.anandtech.com/show/10635/int ... o-lake-soc

Yes similar capability Flag registers do exist. But flag registers might be changing do some hybriding of ARM into low end Celeron line (IDK). Have to read more sometime. But don't have time for even searching 300+ page CPU programming manual now. Not sure I could get one free anymore either.



My often faulty memory is backed up by https://en.wikipedia.org/wiki/CPUID (roughly on topic -- not the technical end all nor directly answering how CentOS queries and handles flags over the full range of processors).

For instance I got an old 2003 copy of CPUZ that does not work right with newer processors. Not just new flags also a couple old flags. Codewise I would guess newer CPUID causes Overflow, flags inserted in middle, or reordered.



Bottomline: are we absolutely sure Intel is not changing registers/instructions again to accomodate more capability flags? Changes to data length and formats can mess existing code up. I could also accept that J3355 CPU would never work at full capability because its too fringe for development effort. But its nice to know when that is not the case and code updates are in pipeline.

User avatar
TrevorH
Site Admin
Posts: 33191
Joined: 2009/09/24 10:40:56
Location: Brighton, UK

Re: Apollo lake support for Centos 6.8

Post by TrevorH » 2017/03/14 17:50:40

Bottomline: are we absolutely sure Intel is not changing registers/instructions again to accomodate more capability flags?
Yes, the flags are defined and the ones you're interested in for things like AES are fixed across all models.Those flags are common across all intel x86 chips though of course bits that are marked as 'reserved' in earlier models can sometimes be assigned a meaning in later ones but once a bit is defined as meaning something, it stays that way.
The future appears to be RHEL or Debian. I think I'm going Debian.
Info for USB installs on http://wiki.centos.org/HowTos/InstallFromUSBkey
CentOS 5 and 6 are deadest, do not use them.
Use the FAQ Luke

Observation2017
Posts: 6
Joined: 2017/03/14 12:36:15

Re: Apollo lake support for Centos 6.8

Post by Observation2017 » 2017/03/15 22:42:07

FYI to anyone using that J3355 chip -- the 104+ C temps are legit.

The normal Tjunction operating temp is like 104C (check Intel ARK for exact temp). So if you are aircooled and not doing some "supercooling" setup you will see some sensor readings that would be unhealthy to unbelievable in the x86 CPUs.

Observation2017
Posts: 6
Joined: 2017/03/14 12:36:15

Re: Apollo lake support for Centos 6.8

Post by Observation2017 » 2017/03/16 00:25:13

Yes I had some bad info about Atom Apollo Lake chips. Happens when you quick scan material and pick a wrong source. Yes they do execute x86 instructions internally. Even 64-bit instructions set if done right.

But apparently external support chips and BIOS have much heavier effects on whether small things like 64 bit code will run. So I guess problems with AES could lie in particular MB design as well as BIOS settings. So multiple MB reviews will be important.

Not sure but if you can find CoreBoot implementations that may help give more software control over potential BIOS settings, that may be of less interest to motherboard manufacturers who are more focused on specialized server applications for industry and HTPC. Not sure if off the cuff mention of Pfsense means a dedicated router-OS combo can seize control from a standard BIOS (Clover style) or if that refers only to some hardware offerings where they replace the entire BIOS.

Any case it looks like the topic is well out of the CentOS scope of concern for the foreseeable future. Just a borderline case where a particular x86 CPU may or may not fully work due to motherboard maker decisions.

matrix2020
Posts: 21
Joined: 2016/11/11 07:42:01

Re: Apollo lake support for Centos 6.8

Post by matrix2020 » 2017/03/20 10:37:02

Just a heads up.
After updating bios to 1.2, vt-d support is enabled.
I have enabled in bios and rebooted.
Now dmesg shows that indeed vt-d is present.
Haven't tried using it yet though.

AreebSooYasir
Posts: 1
Joined: 2017/05/08 20:16:28
Contact:

Re: Apollo lake support for Centos 6.8

Post by AreebSooYasir » 2017/05/08 20:22:09

I've used a J3455 successfully on Centos 7.3 (with C-States disabled as this tends to cause big performance/freezing issues unless you have a more recent 4.x kernel) and plan to test Centos 6.9 later today and will report back. Note even Centos 7.3 says the CPU is unsupported but with C-States disabled works perfectly fine. I am surprised at the issues with these chips as it is almost like they don't work as normal X86 CPUs in many cases.
Cheers

Areeb

Post Reply