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)
Red Hat logoGithubRedditYoutubeTwitter

Learn

Try, buy, & sell

Communities

About Red Hat Documentation

We help Red Hat users innovate and achieve their goals with our products and services with content they can trust.

Making open source more inclusive

Red Hat is committed to replacing problematic language in our code, documentation, and web properties. For more details, see the Red Hat Blog.

About Red Hat

We deliver hardened solutions that make it easier for enterprises to work across platforms and environments, from the core datacenter to the network edge.

© 2024 Red Hat, Inc.