3 Known Issues
This chapter describes the known issues for the Unbreakable Enterprise Kernel Release 6.
Unusable or Unavailable Arm Features
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.
File System Issues
The following are known file systems issues for this UEK R6 release.
Btrfs: ENOSPC error and aborted transaction when removing many file extents from large file range
In a limited number of cases, removed file extent items that traverse multiple leaves can fail with an ENOSPC error, and the current transaction is aborted. The file system switches to read-only mode.
When this problem occurs, a stack trace error similar to the
following is dumped in syslog
and displayed
in dmesg output:
[ 1500.620938] BTRFS: Transaction aborted (error -28) [ 1500.620973] WARNING: CPU: 2 PID: 30807 at fs/btrfs/inode.c:9724 __btrfs_prealloc_file_range+0x512/0x570 [btrfs] [ 1500.620974] Modules linked in: btrfs intel_rapl_msr intel_rapl_common kvm_intel (...) [ 1500.621010] CPU: 2 PID: 30807 Comm: xfs_io Tainted: G W 5.9.0-rc3-btrfs-next-67 #1 [ 1500.621012] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 [ 1500.621023] RIP: 0010:__btrfs_prealloc_file_range+0x512/0x570 [btrfs] [ 1500.621026] Code: 8b 40 50 f0 48 (...) [ 1500.621028] RSP: 0018:ffffb05fc8803ca0 EFLAGS: 00010286 [ 1500.621030] RAX: 0000000000000000 RBX: ffff9608af276488 RCX: 0000000000000000 [ 1500.621032] RDX: 0000000000000001 RSI: 0000000000000027 RDI: 00000000ffffffff [ 1500.621033] RBP: ffffb05fc8803d90 R08: 0000000000000001 R09: 0000000000000001 [ 1500.621035] R10: 0000000000000000 R11: 0000000000000000 R12: 0000000003200000 [ 1500.621037] R13: 00000000ffffffe4 R14: ffff9608af275fe8 R15: ffff9608af275f60 [ 1500.621039] FS: 00007fb5b2368ec0(0000) GS:ffff9608b6600000(0000) knlGS:0000000000000000 [ 1500.621041] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 1500.621043] CR2: 00007fb5b2366fb8 CR3: 0000000202d38005 CR4: 00000000003706e0 [ 1500.621046] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 1500.621047] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 1500.621049] Call Trace: [ 1500.621076] btrfs_prealloc_file_range+0x10/0x20 [btrfs] [ 1500.621087] btrfs_fallocate+0xccd/0x1280 [btrfs] [ 1500.621108] vfs_fallocate+0x14d/0x290 [ 1500.621112] ksys_fallocate+0x3a/0x70 [ 1500.621117] __x64_sys_fallocate+0x1a/0x20 [ 1500.621120] do_syscall_64+0x33/0x80 [ 1500.621123] entry_SYSCALL_64_after_hwframe+0x44/0xa9 [ 1500.621126] RIP: 0033:0x7fb5b248c477 [ 1500.621128] Code: 89 7c 24 08 (...) . . .
This issue typically triggers when the fallocate() function fails to complete a zero range operation against a large file range (100+ MiB) for which there are many small extents allocated.
(Bug ID 32675999 )
Btrfs: File system corruption occurs in the event of sudden disk failure
A sudden disk failure can result in a corrupted Btrfs file system if the file system has not had a chance to flush logs. The issue is observed when checking the file system after the disk is recovered. Output similar to the following is displayed when running btrfs check <dev> :
root 5 inode 2832 errors 100, file extent discount Found file extent holes: start: 2387968, len: 69632 root 270 inode 266 errors 100, file extent discount Found file extent holes: start: 4145152, len: 45056 root 942 inode 259 errors 100, file extent discount Found file extent holes: start: 4935680, len: 77824 root 945 inode 258 errors 100, file extent discount Found file extent holes: start: 1064960, len: 49152 root 946 inode 259 errors 100, file extent discount Found file extent holes: start: 3895296, len: 73728 ERROR: errors found in fs roots found 936067072 bytes used, error(s) found total csum bytes: 387876 total tree bytes: 19349504 total fs tree bytes: 17235968 total extent tree bytes: 950272 btree space waste bytes: 10670592 file data blocks allocated: 2036375552 referenced 972320768
You can attempt to repair the file system by running the same
command with the --repair
option set, for
example:
sudo btrfs check --repair /dev/sdb1
(Bug ID 30473586 )
ext4: Frequent repeated system shutdowns can cause file system corruption
If a system using
ext4
is repeatedly and frequently shut down, the file system may be
corrupted. This issue is considered to be a corner-case due to the difficulty required to
replicate. The issue exists in upstream code and proposed patches are currently under review.
(Bug ID 27547113)
Serial port console can crash if the serial port baud rate is too low
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)
SELinux "Permission watch" messages displayed
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)
SELinux in enforcing mode with the MLS policy not supported
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)
Spurious xs_tcp_setup_socket: connect messages when using NFS
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)
mstflint command reports core dump when used on Oracle Linux 8
Using the mstflint -i fw-*.bin b command to update certain firmware on an Oracle Linux 8 system results in a core dump.
When this issue occurs, messages similar to the following can be observed in the corresponding output:
mstflint -d 3b:00.0 -i fw-ConnectX3-rel-2_35_6312-45-7046442_7092757.bin b
/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 char; _Alloc = std::allocator<unsigned char>; std::vector<_Tp, _Alloc>::reference = unsigned char&; std::vector<_Tp, _Alloc>::size_type = long unsigned int]: Assertion '__builtin_expect(__n < this->size(), true)' failed. Aborted (core dumped)
Currently, there is no workaround for this issue.
(Bug ID 33212531)
IOMMU kernel option enabled by default
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.
Changing Linux I/O scheduler for NVMe devices fails on hosts with Qlogic HBAs that have more than 250 namespaces
An issue is encountered if you have more than 250 NVMe namespaces
that are created by using the QLogic Fibre Channel
qla2xxx
HBA driver, and you then attempt to
change the Linux I/O scheduler from the default value of
none
to mq-deadline
. The
operation fails, rendering the devices offline.
The following messages are logged:
[ 692.819064] qla2xxx 0000:04:00.1: DMAR: Allocating 2-page iova failed [ 692.819107] qla2xxx 0000:04:00.1: DMAR: Device request: 2@4f309ebfd0 dir 1
The workaround for this issue is to disable the Linux IOMMU driver, which is enabled by default in UEK R6:
sudo grubby --update-kernel=ALL --args="iommu=off"
You must reboot the system for the changes to take effect.
Note that the IOMMU driver is not required in UEK R6 unless the server is hosting single root I/O virtualization (SR-IOV) devices. See IOMMU kernel option enabled by default for additional details.
(Bug ID 33348390)
RoCE connection might fail when multiple netdevices belonging to HCA ports are slaves under bonding master
A bug that might impact RoCE connections on a default GID or an IPv6 link-local address has been observed with certain configurations. Attempts to establish a RoCE connection for these types of configurations might fail when two or more netdevices belonging to HCA ports are slaves under a bonding master.
If this issue occurs, error messages similar to the following are
displayed in dmesg
output:
__ib_cache_gid_add: unable to add gid fe80:0000:0000:0000:f652:14ff:fe46:7391 error=-28.
This issue might be encountered with following configurations:
-
On a bare-metal system with an attached ConnectX-5 Ethernet adapter card, when IPv6 and bonding are configured, during the
ifdown
orifup
bonding interface operation. -
On a host console with an attached ConnectX-6 Ethernet adapter card, when creating or deleting
macvtap
devices.
(Bug ID 31868736)
bnxt_re: probe error: "RoCE is not supported on this device" reported after installing on certain hardware with Broadcom NetXtreme-C/E bnxt_en driver
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)
Messages emitted indicating the route cache is full when using IPv6
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)
IPv6 RDS zcopy may fail when using RoCE
Using the rds-stress command with the -D option on a system that is running UEK R6 may result in IPv6 connection failure when using RoCE, for example:
/usr/bin/rds-stress -r 2001:db8:0:f101::10 -s 2001:db8:0:f101::50 -p 5001 -q 256 -a 256 -D 1048576 -t 8 -d 8 -T 5 -Q 0
connecting to 2001:db8:0:f101::50:5001 negotiated options, tasks will start in 2 seconds Starting up.... tsks tx/s rx/s tx+rx K/s mbi K/s mbo K/s tx us/c rtt us cpu % 8 1111 1138 1124.08 1148754.54 1152849.92 2262.40 166273.84 -1.00 8 0 0 0.00 0.00 0.00 0.00 0.00 -1.00 An incoming message had a header which didn't contain the fields we expected: member expected eq got seq 232 != 233 from_addr 2001:db8:0:f101::50 = 2001:db8:0:f101::10 to_port 5009 = 5009 index 0 != 1 op 2 = 2 header from 2001:db8:0:f101::50:5006 to id 5009 bogus An incoming message had a header which didn't contain the fields we expected: . . .
When this failure occurs, the RDS/IB connection drops and the dmesg command outputs "send completion errors" similar to the following:
[ 1459.672036] RDS/IB: Active conn 000000009390f34a i_cm_id 0000000025fb11f7, frag 16KB, connected <::ffff:10.196.100.10,::ffff:10.196.100.20,0> version 4.1 [ 1525.726700] RDS/IB: Passive conn 0000000004f3adf0 i_cm_id 000000008ed2761a, frag 16KB, connected <2001:db8:0:f101::10,2001:db8:0:f101::20,0> version 4.1 [ 1533.507148] RDS/IB: connection <2001:db8:0:f101::10,2001:db8:0:f101::20,0> dropped due to 'peer ADDR_CHANGE event' [ 1533.520819] RDS/IB: Active conn 0000000004f3adf0 i_cm_id 00000000e4924354, frag 16KB, connected <2001:db8:0:f101::10,2001:db8:0:f101::20,0> version 4.1 [ 6520.413359] perf: interrupt took too long (2512 > 2500), lowering kernel.perf_event_max_sample_rate to 79000 [ 6828.577868] perf: interrupt took too long (3158 > 3140), lowering kernel.perf_event_max_sample_rate to 63000 [11040.701140] perf: interrupt took too long (3957 > 3947), lowering kernel.perf_event_max_sample_rate to 50000 [15759.500697] RDS/IB: Active conn 0000000071070b96 i_cm_id 000000008991e14b, frag 16KB, connected <2001:db8:0:f101::10,2001:db8:0:f101::50,0> version 4.1 [15761.564522] RDS/IB: connection <2001:db8:0:f101::10,2001:db8:0:f101::50,0> dropped due to 'DISCONNECTED event' [15763.206080] RDS/IB: Active conn 0000000071070b96 i_cm_id 0000000078e31285, frag 16KB, connected <2001:db8:0:f101::10,2001:db8:0:f101::50,0> version 4.1 [15763.232934] RDS/IB: connection <2001:db8:0:f101::10,2001:db8:0:f101::50,0> dropped due to 'qp event' [15763.250068] RDS/IB: Active conn 0000000071070b96 i_cm_id 000000002001aa35, frag 16KB, connected <2001:db8:0:f101::10,2001:db8:0:f101::50,0> version 4.1 [15763.284602] RDS/IB: connection <2001:db8:0:f101::10,2001:db8:0:f101::50,0> dropped due to 'recv completion error' [15763.300256] RDS/IB: Active conn 0000000071070b96 i_cm_id 0000000003fdea35, frag 16KB, connected <2001:db8:0:f101::10,2001:db8:0:f101::50,0> version 4.1 [15763.305075] RDS/IB: connection <2001:db8:0:f101::10,2001:db8:0:f101::50,0> dropped due to 'DISCONNECTED event' [15763.307644] infiniband mlx5_0: dump_cqe:275:(pid 0): dump error cqe [15763.307649] 00000000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [15763.307650] 00000010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [15763.307652] 00000020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [15763.307653] 00000030: 00 00 00 00 00 00 88 13 08 00 01 0f 01 4f 94 d2 [15763.322476] RDS/IB: Active conn 0000000071070b96 i_cm_id 00000000f9fd41c3, frag 16KB, connected <2001:db8:0:f101::10,2001:db8:0:f101::50,0> version 4.1 [15763.330022] RDS/IB: connection <2001:db8:0:f101::10,2001:db8:0:f101::50,0> dropped due to 'DISCONNECTED event' . . .
The same issue has also been observed on KVM guests. Note that the issue does not occur for IPv4 connections.
This issue is considered to be a corner-case due to the fact that is not consistently reproducible.
(Bug ID 33078473)
IPv6 failback fails when using RoCE
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)
It is not possible to remove the libpcap package
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)
Network latency may increase on Infiniband fabrics
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)
Packet loss occurs with large MTUs on ConnectX-6Dx vDPA interfaces
ConnectX-6Dx adapters currently have a sensitivity to packet size for vDPA interfaces. As a result, systems with ConnectX-6Dx vDPA interfaces that are configured to use an MTU larger than 1500 bytes may experience packet loss during network transmissions.
To work around this issue, use an MTU size of 1500 for vDPA network interfaces.
(Bug ID 33403579)
Boot times for KVM guests may increase for VMs with vDPA interfaces
VMs with vDPA interfaces that boot by using the BIOS or UEFI/OVMF
may experience increased boot times. This increase in time grows
as the number of vDPA interfaces that are assigned to the VM
increases. A common cause for this issue is when the boot order is
not specified for the guest on the QEMU command line or in the
guest’s libvirt
XML description. In such
cases, the VM must discover all of the devices and then determine
which are bootable, which results in increased boot times.
The workaround for this issue is to ensure that you specify a boot order for any VMs that have vDPA interfaces
(Bug ID 33294034 )
(aarch64) Perf tool can result in application slowdown when profiling some virtualized Arm platforms
Note:
The following issue does not affect bare metal installations.
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)
(aarch64) Kdump fails to allocate crashkernel memory on some Arm systems
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)
The ipmctl-monitor package is no longer required to use ipmctl
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)