Attention

You are viewing an older version of the documentation. The latest version is v3.3.

FAQs and Known Limitations

Frequently Asked Questions

See also

Visit the Edge Controls for Industrial online support forum for questions and answers: https://community.intel.com/t5/Intel-Edge-Software-Hub/bd-p/edge-software-hub

  1. 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.

  2. 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.

  3. 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. Refer to the download procedure.

  4. 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.

  5. 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.

  6. 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.

See also

Visit the Edge Controls for Industrial online support forum for questions and answers: https://community.intel.com/t5/Intel-Edge-Software-Hub/bd-p/edge-software-hub

Limitation #1

When building an ECI image, the build process fails 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

[ECI-A] 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 #3

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 #4

Intel® Ethernet Controller I225 Time-Sensitive Networking (TSN) Linux driver 5.4-backported driver still suffer some of known sched-entry inconsistency when offloading schedules to the hardware

Generally, tc qdisc TAPRIO gate-masks definitions are specified in terms of traffic classes (tc), so sched-entry S 03 5000000 means that the tc 0 and 1 are open for 500us. But when taprio sched-entries are offloaded to hardware, that is, flags 0x2, the gate-masks are specified as hardware queues, which means txq 0 and 1 are open for 500us.

To make sure that the corresponding sched-entries are applied, reload igc kernel module with fully-verbose debug.

rmmod igc
insmod /lib/modules/5.4.59-rt36-intel-pk-preempt-rt/kernel/drivers/net/ethernet/intel/igc/igc.ko debug=16

dmesg -w
    [2967265.790583] igc 0000:02:00.0 eth0: Detected Tx Unit Hang
                       Tx Queue             <0>
                       TDH                  <55>
                       TDT                  <5a>
                       next_to_use          <5a>
                       next_to_clean        <55>
                     buffer_info[next_to_clean]
                       time_stamp           <111ae3b16>
                       next_to_watch        <00000000737c47b3>
                       jiffies              <111af42f0>
                       desc.status          <938000>
    [2967267.790416] igc 0000:02:00.0 eth0: Detected Tx Unit Hang
                       Tx Queue             <0>
                       TDH                  <55>
                       TDT                  <5a>
                       next_to_use          <5a>
                       next_to_clean        <55>
                     buffer_info[next_to_clean]
                       time_stamp           <111ae3b16>
                       next_to_watch        <00000000737c47b3>
                       jiffies              <111af43b8>
                       desc.status          <938000>

Limitation #5

Following is the list of known issues/limitations for Intel® Elkhart Lake Functional Safety (FuSa) Software Package (Revision 0.8.7)

Title

Description

Proof Test not supported

Proof Test not supported in Revision 0.8.7 release

1ms /4ms PST not supported

PST is set to 100ms in in Revision 0.8.7 release

False NOK

ODCC execution could result in a False NOK generation due to timer expiry

Startup STL Test Failure message

Non-fatal message. Recommended to ignore the message