FAQs, Known Limitations, Support¶
Intel Edge Software Support Forum¶
Expand your knowledge of Intel Edge Software through participating in the Intel Edge Software Support Forum community.
Submit Edge Control for Industrial questions to Intel Technical Support and find answers to your support issues: Intel® Edge Software Hub - Intel Communities.
Frequently Asked Questions¶
- I used my personal email address while requesting for access, and it has been more than two working days. I have not yet received the product key. What should I do?
It is recommended to use an official email address instead of your personal email address.
- I used my official email address while requesting for access. It has been more than two working days, and I have not yet received the product key. What should I do?
Downloading of Intel® Edge Control for Industrial involves a manual approval process. Make sure your company has a CNDA before submitting the request for access. If you have any questions regarding the CNDA with Intel®, contact the Intel® Sales Representatives.
- I received the email with the product key. What should I do next?
After receiving the product key, you can download the ECI Release Package.
- My colleague had requested for access and received the email with the product key. However, I am unable to download. Do I need to request for access again?
Yes. The access is granted for the email address and not the company. So, if you want to download using a different email address, you need to request for access for that email address.
- What is the minimum free space required to build Intel® ECI?
A minimum of 150 GB free space is required to build Intel® ECI. For more details, refer to system requirements.
- Building of Yocto is time consuming. How can I speed up the compilation?
To speed up the compilation, create a local cache.
Known Limitations¶
This section lists the known limitations with ECI. Fixes to these limitations are expected in the future releases of ECI. Refer to your ECI distribution channel to learn more about updates on ECI.
For other issues, go to https://premiersupport.intel.com/ (Login with your Intel account) and create a new Intel Edge Software Recipes Case under the Software/Driver/OS category and the Industrial Edge Control Software sub-category.
Limitation #1 - ECI Build errors¶
When building ECI, the build process may fail due to do_fetch errors. These errors occur when the build engine is unable to reach external dependencies via the network. Most often, these errors occur due to network instability, broken mirrors, or proxy server instability.
Mitigation Actions
It is recommended to avoid environments with network proxies and heavy network congestion.
Often, repeating the build process will eventually result in a complete build.
Outages and offline mirrors tend to be intermittent. Attempt the build again after waiting a few hours for the issues to subside.
Limitation #2 - core-bullseye & core-jammy VM RAM¶
The ECI core-bullseye core-jammy images require at least 3GB of RAM to boot in a VM environment.
Limitation #3 - ACRN Service VM monitor output¶
On some hardware platforms, the ACRN Service VM may not output anything to the attached monitor. Only the GRUB warning “WARNING: no console will be available to OS” will be visible upon booting.
Limitation #4 - ACRN VM filesystem read-only¶
When intensive storage I/O is sustained within a virtual machine (VM) running on the ACRN hypervisor, some I/O requests may be dropped. Linux kernels will interpret this behavior as faulty storage hardware and automatically remount the affected storage partition as read-only. This situation may occur if storage benchmarks are performed within the VM.
Mitigation Actions
Avoid sustained intensive storage I/O within the VM.
Assign more virtual CPUs to the VM to increase the effective I/O bandwidth.
Limit the number of VMs running simultaneously.
Avoid sharing physical CPUs between VMs.
Limitation #5 - No results from msi-jitter benchmark¶
Benchmark msi-jitter /opt/benchmarking/msi-jitter does not provide results on certain devices. Known, affected devices are Karbon 700 and Karbon 300.
************ RESULTS (ns) ************ [79774.994363] * Max: 0 [79774.994363] * Avg: 0 [79774.994364] * Min: 0 [79774.994364] *********** *********** ***********
This behavior is currently observed only for i210 Ethernet NICs connected to cascading PCI bridges. The following is an lspci -t example from a Karbon 700 device:
lspci -t -[0000:00]-+-00.0 +-02.0 +-08.0 +-12.0 +-14.0 +-14.2 +-15.0 +-15.1 +-16.0 +-16.3 +-17.0 +-1b.0-[01]----00.0 +-1b.6-[02-08]----00.0-[03-08]--+-01.0-[04]----00.0 | +-02.0-[05]----00.0 | +-03.0-[06]----00.0 | +-04.0-[07]----00.0 | \-05.0-[08]-- +-1c.0-[09]----00.0 +-1c.6-[0a]----00.0 +-1c.7-[0b]----00.0 +-1e.0 +-1f.0 +-1f.3 +-1f.4 +-1f.5 \-1f.6 lscpi 00:00.0 Host bridge: Intel Corporation 8th Gen Core 8-core Desktop Processor Host Bridge/DRAM Registers [Coffee Lake S] (rev 0d) ... 00:1b.6 PCI bridge: Intel Corporation Cannon Lake PCH PCI Express Root Port #23 (rev f0) 00:1c.0 PCI bridge: Intel Corporation Cannon Lake PCH PCI Express Root Port #3 (rev f0) 00:1c.6 PCI bridge: Intel Corporation Cannon Lake PCH PCI Express Root Port #7 (rev f0) 00:1c.7 PCI bridge: Intel Corporation Cannon Lake PCH PCI Express Root Port #8 (rev f0) ... 02:00.0 PCI bridge: Pericom Semiconductor PI7C9X2G608GP PCIe2 6-Port/8-Lane Packet Switch 03:01.0 PCI bridge: Pericom Semiconductor PI7C9X2G608GP PCIe2 6-Port/8-Lane Packet Switch 03:02.0 PCI bridge: Pericom Semiconductor PI7C9X2G608GP PCIe2 6-Port/8-Lane Packet Switch 03:03.0 PCI bridge: Pericom Semiconductor PI7C9X2G608GP PCIe2 6-Port/8-Lane Packet Switch 03:04.0 PCI bridge: Pericom Semiconductor PI7C9X2G608GP PCIe2 6-Port/8-Lane Packet Switch 03:05.0 PCI bridge: Pericom Semiconductor PI7C9X2G608GP PCIe2 6-Port/8-Lane Packet Switch 04:00.0 Ethernet controller: Intel Corporation I210 Gigabit Network Connection (rev 03) 05:00.0 Ethernet controller: Intel Corporation I210 Gigabit Network Connection (rev 03) 06:00.0 Ethernet controller: Intel Corporation I210 Gigabit Network Connection (rev 03) 07:00.0 Ethernet controller: Intel Corporation I210 Gigabit Network Connection (rev 03) 09:00.0 Non-Volatile memory controller: Silicon Motion, Inc. Device 2263 (rev 03) 0a:00.0 Ethernet controller: Intel Corporation I210 Gigabit Network Connection (rev 03) 0b:00.0 Ethernet controller: Intel Corporation I210 Gigabit Network Connection (rev 03)
In the above example, Ethernet controller 04:00.0, 05:00.0, 06:00.0, 07:00.0 would be affected as they connect
to 00:1c.6 PCI bridge: Intel Corporation Cannon Lake PCH PCI Express Root Port #7 (rev f0)
and PCI bridge: Pericom Semiconductor PI7C9X2G608GP PCIe2 6-Port/8-Lane Packet Switch.
Mitigation Actions
Run msi-jitter benchmark on non-cascading PCI bridged Ethernet controllers. E.g.
./run_msijitter.sh "0000:0a:00.0" 1 10 10, for Karbon 700. This behavior is unique to the msi-jitter benchmark and does not affect regular operation of the Ethernet controller. The msi-jitter benchmark kernel driver has to be fixed with upcoming releases.
Limitation #6 - Cannot start CODESYS Linux runtime¶
The CODESYS Linux Runtime may not start correctly on +12th Generation Intel CPUs. This behavior seems to be related to the split “efficiency” and “performance” cores on newer processors.
Mitigation Actions
Try restarting the CODESYS Linux runtime:
$ sudo systemctl restart codesyscontrolVerify that the CODESYS Linux runtime is active (running):
$ sudo systemctl status codesyscontrolUse the kernel boot parameter
isolcpusto isolate the “efficiency” cores.Enable
Intel(R) TCC Modein the BIOS to affect Linux task CPU affinity:
Setting Name
Option
Setting Menu
Intel(R) TCC Mode
Enabled
Intel Advanced Menu ⟶ Intel Time Coordinated Computing