Chapter 10. Kernel
Reservation of memory for crashkernel no longer fails
Previously, the reservation of memory for crashkernel in some cases failed with the following error message:
Crashkernel reservation failed. Found area can not be reserved: start=0x4000000, size=0x34000000.
This update fixes the step down mechanism so that the upper limit set in the
KEXEC_RESERVE_UPPER_LIMIT parameter is not exceeded, which makes the reservation succeed. As a result, the memory reservation for crash kernel now proceeds as expected. (BZ#1349069)
The mbind call now allocates memory on the specified NUMA node
Previously, using the
mbind call for allocation of memory on a Non-Uniform Memory Access (NUMA) node with particular number worked only for the very first invocation. On subsequent calls, the memory was always allocated on NUMA node 0. This update fixes the interaction of the mbind_range() function and the vma_adjust() function. As a result, mbind now allocates memory on the NUMA node with specified number in all cases. (BZ#1277241)
The system no longer hangs due to the tasklist_lock variable starvation
In a situation with a lot of concurrent processes taking the
tasklist_lock variable for reading, the operating system sometimes became unresponsive when it was trying to take tasklist_lock for writing. This update fixes the underlying source code, so that a writer excludes the new readers to prevent the system hang. (BZ#1304864)
Intel Xeon v5 no longer causes GPU to hang
Previously, on GT3 and GT4 architectures, Intel Xeon v5 integrated graphics could experience problems with GPU lock-up, leading to GPU hang. This bug has been fixed. (BZ#1323945)
Kernel no longer panics when loading Intel Xeon v5 integrated graphic cards
When loading Intel Xeon v5 integrated graphic cards, a kernel panic sometimes occurred due to a race condition in the kernel firmware loader. This update adds a separate lock that is held throughout the life time of the firmware device, thus protecting the area where the device is registered. As a result, the kernel no longer panics in the described situation. (BZ#1309875)
NFS no longer uses FS-Cache when -o fsc is not set
Previously, when an NFS share was mounted, FS-Cache was always erroneously enabled even when the
-o fsc option was not used in the mount command. Consequently, the cachefilesd service stored files on the NFS share, and other severe problems, such as the kernel becoming unresponsive or terminating unexpectedly, sometimes occurred. With this update, NFS no longer uses FS-Cache if -o fsc is not set. As a result, NFS now uses FS-Cache only when explicitly requested. Note that FS-Cache is provided as a Technology Preview in Red Hat Enterprise Linux 6. (BZ#1353844)
