Chapter 57. Kernel
Application performance suffers after the kernel update
Previously, the
CONFIG_RCU_NOCB_CPU_ALL kernel configuration option was set for RHEL 7 kernels. From RHEL 7.3 onwards, CONFIG_RCU_NOCB_CPU_ALL is no longer set. Consequently, in an environment where Interrupt Requests (IRQs) are pinned to specific CPUs, application performance suffers after the kernel update from version 3.10.0-327 to 3.10.0-514 or 3.10.0-693. To work around this problem, set the rcu_nocbs kernel command-line parameter at boot for all available CPU cores. As a result, the workaround will produce the same behavior as having CONFIG_RCU_NOCB_CPU_ALL set at build time.
For more information, see the following Solution article Increased softirq usage in RHEL 7.3 and RHEL 7.4 kernels. (BZ#1551632)
Improved SCTP performance and better transfer rates
The Stream Control Transmission Protocol (SCTP) implementation is known to consume a large amount of CPU resources. Consequently, insufficient CPU resources often make it impossible to reach high transfer rates, such as 10Gbps on a single association. This update provides improvements that reduce CPU usage on certain SCTP handling, which improves SCTP performance and results in better transfer rates in some situations.
Note that this update does not ensure that SCTP is now able to achieve a 10Gbps transfer rate. (BZ#1058148)
Looking up transport or association can lead to kernel panic
Due to a use-after-free bug, the kernel's stream control transmission protocol (SCTP) implementation does not hold the pointer to the transport path while it is in use. As a consequence, another CPU can free the pointer, access the memory which should be unavailable, and a kernel panic occurs. Work to address this issue is being tracked in https://bugzilla.redhat.com/show_bug.cgi?id=1368884. (BZ#1368884)
dracut displays a harmless error message about a non-existent /etc/hba.conf
When
dracut creates an initial RAM file system (initramfs) with Fibre Channel over Ethernet (FCoE) support, if the /etc/hba.conf file does not exist, dracut displays an error message. You can safely ignore this message. (BZ#1373129)
kdump does not work with legacy Type 12 persistent memory
Systems with legacy Type 12 Non-Volatile Dual In-line Memory Modules (NVDIMMs), either real dual in-line memory modules (DIMMs), or emulated using the _memmap=XG!YG kernel command line parameter, are unable to successfully capture a kernel crash dump. For systems with real NVDIMMs, attempts to capture a kernel crash dump result in data corruption in some cases. Users can work around this problem by disabling the
kdump feature on such systems. (BZ#1351098)
The update of megaraid_sas can lead to a performance decrease
The
megaraid_sas driver has been updated to version 06.811.02.00-rh1, which brings a number of performance improvements over the previous version. However, in some cases, with configurations based on Solid-state Drives (SSD) a performance decrease has been observed. To work around this problem, set the corresponding queue_depth parameter in the /sys/ directory to a higher value up to 256, which brings the performance back to its original level. (BZ#1367444)
xgene-enet does not handle situations with low free memory
The
xgene_enet driver currently does not handle out-of memory errors properly. When such an error occurs, the driver sometimes terminates unexpectedly and returns a kernel backtrace to the serial console and to dmesg logs. Consequently, the system becomes unable to communicate over the network and has to be restarted. (BZ#1248185)
Certain NIC firmware can become unresponsive with bnx2x
Due to a bug in the unload sequence of the pre-boot drivers, the firmware of some internet adapters can become unresponsive after the
bnx2x driver takes over the device. The bnx2x driver detects the problem and returns the message storm stats were not updated for 3 times in the kernel log. To work around this problem, apply the latest NIC firmware updates provided by your hardware vendor. As a result, unloading of the pre-boot firmware now works as expected and the firmware no longer hangs after bnx2x takes over the device. (BZ#1315400)
Change of default settings on FCoE servers to reach the correct functionality of the kdump mechanism
Disks on Fibre Channel over Ethernet (FCoE) servers use the multipath storage system, which allows the disks to connect to system from a different interface. Several logical disks are present in the system, but they are mapped to only one real disk. Consequently, with the default settings, the FCoE servers are not able to start on a kdump kernel. To reach the correct functionality of the kdump mechanism, users are advised to specify the Universally Unique Identifier (UUID) of the FCoE disks. Users are also advised to enable the
multipath option so that disks can be managed in a more efficient way. (BZ#1293520)
iSCSI connection produces I/O errors
Red Hat Enterprise Linux 7.3 no longer caps I/O requests for SCSI disks at a maximum of 512Kib. As a consequence, when a guest running on Red Hat Enterprise Linux 7.3 connects to an iSCSI target configured to use the
fileio backstore and running on an older version of Red Hat Enterprise Linux, some warning messages appear in the logs, and performance is also affected negatively. To work around this problem, install a udev rule on the system to limit the I/O request size to the maximum of 4096Kib. The problem with the fileio backstore can also be fixed by upgrading the iSCSI target to Red Hat Enterprise Linux 7.3. (BZ#1387858)
MST displays become unresponsive when display port cable is plugged in
Previously, DEll MST displays became unresponsive when display port cable was plugged in, because unrelated dp-aux messages interrupted a sequence of dp-aux messages that implemented an I2C device read or write. This update prevents the I2C-over-dp-aux sequence from being interrupted by unrelated MST setup messages. As a result, MST displays no longer become unresponsive in the described scenario. (BZ#1274157)
On IBM Power Systems, kdump fails if fadump was used previously and both use a network target
The
kdump kernel crash dumping mechanism will fail to save dumps to a network location if the same system was previously configured to instead use firmware-assisted dumping (fadump) and also save dumps remotely. This is because when the mechanism is switched back to kdump, the kdump- prefix is added to the configured network interface, but configuring fadump already added the same prefix before. The resulting interface name becomes kdump-kdump-eth0, and the final 0 is then truncated. This results in an invalid interface name kdump-kdump-eth, and kdump then fails to access the interface and save crash dumps to a remote target.
To work around this problem:
1. Replace the current
/boot/initramfs-$kver.img initrd with the the /boot /initramfs-$kver.img.default file.
2. Run the
touch /etc/kdump.conf command to force rebuilding the kdump initrd after reboot.
3. Reboot the system. (BZ#1372464)
