The following features are known to not work, remain untested, or have issues that cause the feature to be unusable or unavailable on the 64-bit Arm (aarch64) platform:

• InfiniBand

  InfiniBand hardware is currently not supported for Arm architecture using UEK R6.

• FibreChannel

  FibreChannel hardware is currently not supported for Arm architecture using UEK R6.

• RDMA

  RDMA and any of its subfeatures are not supported for the Arm architecture.

• Secure Boot and Lockdown

  The Secure Boot feature and the Kernel Lockdown functionality are not supported or available for the Arm architecture.

On systems that use a physical serial console to monitor system output, such as on an ILOM console interface, it is possible that high levels of output can introduce abnormal system behavior such as kernel deadman timer events that indicate processes are unable to obtain CPU scheduler time. This is typically experienced if the serial console speed is set too low and a log level of 6 or higher is configured for the system. To reduce the likelihood of this issue occurring, either reduce the log level or configure the console for the maximum possible baud rate, 115200.

Starting with UEK R6U1, a warning is displayed in the dmesg output if the baud rate is set too low:

dmesg | grep -A4 -i baud

[  369.777802] Serial console is set to the default of 9600 baud. This can
[  369.778852] result in stalls or lockups in error conditions requiring a
[  369.779892] large number of console system messages. Please increase the
[  369.780889] rate to the highest your system will allow (for instance,
115200
[  369.781918] or 57600). See Oracle KM Note 2648582.1 for more information.

The current console speed for a running Oracle Linux 7 or Oracle Linux 8 system can be set for a configured serial port by running:

stty -F /dev/ttyS0 speed 115200

To change the serial console speed that is used when the system boots, you must edit the GRUB configuration. Edit /etc/sysconfig/grub in a text editor and append console=ttyS0,115200 to the line starting with GRUB_CMDLINE_LINUX, for example:

GRUB_CMDLINE_LINUX="crashkernel=auto resume=/dev/mapper/linux1-swap rd.lvm.lv=linux1/root \
  rd.lvm.lv=linux1/swap rhgb quiet console=ttyS0,115200"

Note that in the above examples, the serial console is assumed to be ttyS0, you may need to change this if you have used an alternate serial port.

To update your grub configuration with the changes so that they are used on the next boot if you are using legacy BIOS, run:

sudo grub2-mkconfig -o /boot/grub2/grub.cfg

Alternately, if you are booting by using the Unified Extensible Firmware Interface (UEFI), run the following command:

sudo grub2-mkconfig -o /boot/efi/EFI/redhat/grub.cfg

If you are using Oracle Server hardware, or a system that provides an ILOM interface to the serial console, make sure that you update the serial console configuration on the ILOM to match the speed that you have set within the host operating system. You can set the serial port on the ILOM CLI by running:

sudo set /SP/serial/host pendingspeed=115200 commitpending=true

To check the current console port speed on the ILOM, using the CLI, run:

sudo show /SP/serial/host

For more information about ILOM configuration, see https://docs.oracle.com/cd/E19203-01/820-1188-12/core_ilom_managing.html.

(Bug ID 30487830, 30439170)

Booting UEK R6 in either the SELinux permissive mode or the enforcing mode produces messages similar to the following:

SELinux:  Permission watch in class filesystem not defined in policy. 
SELinux:  Permission watch in class file not defined in policy. 
SELinux:  Permission watch_mount in class file not defined in policy. 
SELinux:  Permission watch_sb in class file not defined in policy.
SELinux: the above unknown classes and permissions will be allowed

These messages are displayed because no definitions currently exist for these classes in SELinux policy. Per the last line of the message, classes and permissions are allowed by default; and therefore, the messages can be safely ignored.

(Bug ID 30687021, 30687021)

When SELinux is configured to use the Multilevel Security (MLS) policy and it is in the enforcing mode, several issues can prevent normal functioning of the operating system, including permissions errors when attempting to mount file systems and the likelihood of a Systemd freeze when booting the operating system.

SELinux in the enforcing mode with the MLS policy is not supported. Note that you can continue to use SELinux in the enforcing mode by using the targeted policy.

(Bug ID 30797389, 30609238)

When using NFS, inaccurate messages regarding socket connection errors may be emitted. Messages may appear as follows:

xs_tcp_setup_socket: connect returned unhandled error -107

The underlying connection issue is resolved and any connections that fail are now automatically reopened. Provided no associated functional impact is experienced, this error message may be ignored. Note that this message may also appear as a result of a genuine ongoing connection issue.

(Bug ID 30339848)

The mstlink command crashes when run on an Oracle Linux 8 system running Unbreakable Enterprise Kernel Release 6. The following output is typical:

sudo mstlink -d 13:00.1

/usr/include/c++/8/bits/stl_vector.h:932: std::vector<_Tp, _Alloc>::reference
std::vector<_Tp, _Alloc>::operator[](std::vector<_Tp, _Alloc>::size_type)
[with _Tp = unsigned int; _Alloc = std::allocator<unsigned int>;
std::vector< Tp, _Alloc>::reference = unsigned int& std::vector<_Tp,
_Alloc>::size_type = long unsigned int]: Assertion '__builtin_expect(__n <
this->size(), true)' failed.
Aborted (core dumped)

This issue is related to system-wide hardening changes introduced upstream and present in Oracle Linux 8. The upstream tools in the mstflint package, including mstlink do not adequately cater for these hardening changes. Alternate tools can be used to gather and configure link information, including ip link, ethtool, ifstat, and ibv_devinfo.

(Bug ID 30993407)

Starting with UEK R5U1, IOMMU functionality is enabled by default in the x86_64 kernel. This change better facilitates single root input-output virtualization (SR-IOV) and other virtualization extensions; however, it is also known to result in boot failure issues on certain hardware that cannot complete discovery when IOMMU is enabled. The status of this feature no longer appears in /proc/cmd reporting as iommu=on, which means it may need to be explicitly disabled as a kernel cmdline option if boot failure occurs. As an alternative workaround, you can disable IOMMU or Intel-Vtd in your system ROM by following your vendor instructions.

These boot failure issues have been observed on equipment with certain Broadcom network devices, such HP Gen8 servers. For more detailed information, see https://support.hpe.com/hpsc/doc/public/display?docId=emr_na-c04565693.

On some hardware that includes the NetXtreme-C/E bnxt_en driver, messages similar to the following can be observed in the system log (var/log/messages) immediately following a fresh installation:

grep bnxt /var/log/messages

Apr 26 12:00:30 ca-ostest644 kernel: Broadcom NetXtreme-C/E driver bnxt_en
v1.10.1
Apr 26 12:00:30 ca-ostest644 kernel: bnxt_en 0000:18:00.0 (unnamed
net_device) (uninitialized): Firmware does not support TC flower offload.
Apr 26 12:00:30 ca-ostest644 kernel: bnxt_en 0000:18:00.0 eth1: Broadcom
BCM57417 NetXtreme-E 10GBase-T Ethernet found at mem 381c01210000, node addr
00:10:e0:d8:33:09
Apr 26 12:00:30 ca-ostest644 kernel: bnxt_en 0000:18:00.0: 63.008 Gb/s
available PCIe bandwidth (8 GT/s x8 link)
Apr 26 12:00:30 ca-ostest644 kernel: bnxt_en 0000:18:00.1 (unnamed
net_device) (uninitialized): Firmware does not support TC flower offload.
Apr 26 12:00:30 ca-ostest644 kernel: bnxt_en 0000:18:00.1 eth2: Broadcom
BCM57417 NetXtreme-E 10GBase-T Ethernet found at mem 381c01200000, node addr
00:10:e0:d8:33:0a
.
.
.

The dmesg command reports similar messages:

dmesg | grep bnxt

[    2.703443] Broadcom NetXtreme-C/E driver bnxt_en v1.10.1
[    2.720552] bnxt_en 0000:18:00.0 (unnamed net_device) (uninitialized):
Firmware does not support TC flower offload.
[    2.961037] bnxt_en 0000:18:00.0 eth1: Broadcom BCM57417 NetXtreme-E
10GBase-T Ethernet found at mem 381c01210000, node addr 00:10:e0:d8:33:09
[    2.961044] bnxt_en 0000:18:00.0: 63.008 Gb/s available PCIe bandwidth (8
GT/s x8 link)
[    2.986775] bnxt_en 0000:18:00.1 (unnamed net_device) (uninitialized):
Firmware does not support TC flower offload.
[    2.996323] bnxt_en 0000:18:00.1 eth2: Broadcom BCM57417 NetXtreme-E
10GBase-T Ethernet found at mem 381c01200000, node addr 00:10:e0:d8:33:0a
[    2.996331] bnxt_en 0000:18:00.1: 63.008 Gb/s available PCIe bandwidth (8
GT/s x8 link)
[    3.011390] bnxt_en 0000:18:00.0 eno2np0: renamed from eth1
[    3.260089] bnxt_en 0000:18:00.1 eno3np1: renamed from eth2
[    9.038400] bnxt_re: Broadcom NetXtreme-C/E RoCE Driver
[    9.038472] bnxt_en 0000:18:00.0: bnxt_re: probe error: RoCE is not 

These error messages are reported because RDMA support is disabled in the bnxt_en card's firmware on some Oracle servers; however, note that the issue does not impact all Broadcom NetXtreme-C/E cards.

To work around the issue, you must enable RDMA support in the card's firmware prior to the installation.

(Bug ID 32819934)

On some systems, error messages indicating that the route cache is full, are emitted when using IPv6. An error similar to the following example may be returned:

[ 5523.456447] Route cache is full: consider increasing sysctl
net.ipv[4|6].route.max_size.

It is unclear what causes these errors or to what size /proc/sys/net/ipv6/route/max_size should be increased; but, on a test system, the issue could not be replicated after running the following command:

sudo sysctl net.ipv6.route.max_size=32768

Because the issue is currently under investigation, increasing this value is a viable workaround.

(Bug ID 30976607)

The rdmaip driver does not send IPv6 address change notification to RDS, which can delay or prevent IPv6 fail over when using RoCE. This is apparent when active bonding is enabled and only occurs for IPv6. The IPv4 failover continues to work correctly.

When the issue is triggered, the following messages may appear in the kernel log:

kernel: rdmaip: could not add 2001:db8:0:f101::50%4/64 to ens2f0 (port 1)
kernel: IPv6: ens2f0: IPv6 duplicate address 2001:db8:0:f101::50 used by 
        50:6b:4b:cb:ef:23 detected!

A fix is in development but is not available at the time of this release. The fix may become available as an errata update.

(Bug ID 31021418)

Attempting to remove the libpcap package or performing an action that would attempt to remove the package results in an error because the dependency chain would require the removal of the systemd package and this would break the system.

This is expected behavior in Oracle Linux 8; however, the behavior is mentioned here because in previous Oracle Linux releases, it was possible to remove the libpcap package

In some circumstances, such as when installing the RDMA packages, libpcap may be upgraded to a newer version than the version provided for the operating system. If you remove these packages, you may wish to also downgrade the libpcap package to match the highest version provided for the operating system in the BaseOS channel or repository. Typically, this might be most easily done by reverting the installation using the dnf history undo command. See the DNF(8) manual page for more information.

(Bug ID 30979601)

If the TCP write size is close to the size of the Infiniband (IB) Maximum Transmission Unit (MTU), applications may experience higher latencies on packet transfers. For example, the default IB MTU is 65520 bytes. An application that also uses a TCP write size between 65520 bytes to 128 KB may experience this issue. The issue does not appear when applications use larger (for example, 256 KB) or smaller (for example, 4 KB or 32 KB) TCP write sizes.

Note that Ethernet networks are not affected by this issue.

The default values for the IB MTU and TCP write sizes in Oracle Linux and UEK R6 do not expose the issue. Applications with modified TCP window sizes, or systems with modified MTU values, could overlap and expose this issue.

The workaround for this issue is to tune either the MTU of the IB interface, or the TCP write size of the application, so that the TCP write size is smaller than the IB MTU or the TCP write size is greater than 2x the IB MTU. You can tune MTUs dynamically by using the ip link command. Note that tuning of the TCP write size is application specific.

(Bug ID 31830430)

On virtual machines (VMs) that are running on a multi-socket aarch64 platform, if the perf top or perf record command is invoked, it is possible that application slowdowns may occur. In certain cases, the following message is emitted in a terminal window:

kernel:watchdog: BUG: soft lockup

You can mitigate this problem as follows:

• To avoid lockup situations and reduce probe effect, you can specify a sample period by using the -c flag with the perf record command, rather than a frequency by using the -F flag. For example, you would use the perf record -c command instead of the perf record -F 100 command.

• Do not use the perf command with the --all-cpus flag. Instead, specify a minimal number of CPUs by using the perf -C command.

(Bug ID 32834324)

On some 64-bit Arm (aarch64) systems, where insufficient low contiguous memory is available, Kdump may fail due to the system's inability to allocate the minimum crashkernel memory that is typically reserved when the auto value is set.

This issue results in Kdump failing to start and the following errors appearing in the logs:

kdumpctl[3812]: No memory reserved for crash kernel
...
systemd[1]: Failed to start Crash recovery kernel arming.

To work around this issue, manually set the crashkernel low and high values and attempt to set a low value that is below 256 MB. For example, replace crashkernel=auto with crashkernel=800M,high crashkernel=200M,low.

(Bug ID 31554906)

When using UEK R6 with RDS or RDMA, the system emits messages similar to the following:

[  136.066002] **********************************************************
[  136.068731] **   NOTICE NOTICE NOTICE NOTICE NOTICE NOTICE NOTICE   **
[  136.071346] **                                                      **
[  136.074893] ** trace_printk() being used. Allocating extra memory.  **
[  136.078505] **                                                      **
[  136.082337] ** This means that this is a DEBUG kernel and it is     **
[  136.086093] ** unsafe for production use.                           **
[  136.089887] **                                                      **
[  136.093682] ** If you see this message and you are not debugging    **
[  136.097192] ** the kernel, report this immediately to your vendor!  **
[  136.100615] **                                                      **
[  136.104239] **   NOTICE NOTICE NOTICE NOTICE NOTICE NOTICE NOTICE   **
[  136.108005] **********************************************************
[  136.209499] NET: Registered protocol family 21
[  136.229371] Registered RDS/tcp transport

These messages are displayed because the Resilient RDMAIP kernel module currently uses trace_print() for debugging infrastructure. On RDS/RDMA systems, these messages can be safely ignored and do not mean that the kernel is unsafe for production use.

(Bug ID 31066169)

The ipmctl-monitor package is not required for the ipmctl version 2.0 available for UEK R6U2. If you are updating the system from an earlier version of ipmctl or you attempt to install the ipmctl-monitor package along with other ipmctl utilities, you may see conflicts such as the following:

Error:
 Problem: cannot install both libipmctl-02.00.00.3852-1.0.1.el8.x86_64 and
libipmctl-01.00.00.3467-1.0.1.el8.x86_64
  - package ipmctl-monitor-01.00.00.3467-1.0.1.el8.x86_64 requires
libipmctl.so.3()(64bit), but none of the providers can be installed
  - package ipmctl-monitor-01.00.00.3467-1.0.1.el8.x86_64 requires
libipmctl(x86-64) = 01.00.00.3467-1.0.1.el8, but none of the providers can be
installed
  - cannot install the best candidate for the job
  - conflicting requests

If you are updating the system, remove the ipmctl-monitor package before performing the update:

sudo dnf remove ipmctl-monitor
sudo dnf update

If you are installing these packages for the first time, do not include the ipmctl-monitor package in your install command.

(Bug ID 32818557, 32516965)