Calgary IOMMU default detection has been disabled in this release. If you require Calgary IOMMU support add 'iommu=calgary' as a boot parameter.

The kdump service fails on systems with large amounts of memory and crashkernel=auto enabled, returning the error message kdump: kexec: failed to load kdump kernel in /var/log/messages.

To workaround this issue, change the crashkernel parameter to 128M (on x86_64 and x86 architectures) or 256M (on the ppc64 architecture).

If the kdump crash recovery technology is enabled and in use on a given system, minimum memory requirements should be raised by the amount of memory reserved for kdump usage. This value is determined by the user, and specified on the kernel command line, via the crashkernel parameter. The default value for this setting is 128MB.

When using the DIF/DIX hardware checksum features of a storage path behind a block device, errors will occur if the block device is used as a general purpose block device.

Buffered I/O or mmap(2) based IO will not work reliably as there are no interlocks in the buffered write path to prevent overwriting cached data while the hardware is performing DMA operations. An overwrite during a DMA operation will cause a torn write and the write will fail checksums in the hardware storage path. This problem is common to all block device or file system based buffered or mmap(2) I/O, so the problem of I/O errors during overwrites cannot be worked around.

DIF/DIX enabled block devices should only be used with applications that use O_DIRECT I/O. Applications should use the raw block device, though it should be safe to use the XFS file system on a DIF/DIX enabled block device if only O_DIRECT I/O is issued through the file system. In both cases the responsibility for preventing torn writes lies with the application, so only applications designed for use with O_DIRECT I/O and DIF/DIX hardware should enable this feature.

The memory controller in Red Hat Enterprise Linux 6 beta may encounter stability issues when under heavy stress testing or memory pressure.

The i686 debug kernel may crash on some systems when starting the udev service.

Systems configured with Intel 82578DM NICs may not be recognized during boot/install resulting in driver load failure, (driver probe fails with error -2).

This pre-release version of Red Hat Enterprise Linux 6 provides automated Physical CPU Socket and Memory Hot-Add support. Note, however, that CPU Socket and Memory Hot-Remove actions are not supported. Additionally, only single CPU Socket add events are supported at this time, and tsc support is disabled after a CPU Socket add event.

In Beta releases of Red Hat Enterprise Linux 6, PCIe ASPM would be enabled on PCIe hierarchies even if they lacked an _OSC method as defined in section 4.5 of the PCI firmware specification, release 3.0. Post Beta, firmware must provide an appropriate _OSC method on all PCI roots in order to allow PCIe ASPM to be enabled. The "pcie_aspm=force" boot parameter may be passed in order to enable PCIe ASPM.

Use of the cciss and hpsa drivers with some controllers (e.g. P400, P400i, E500, P800, P700m and 6402/6404) may cause kdump to fail.

The top-level makefile to of the kernel in Red Hat Enterprise Linux 6 includes the -Werror option as part of the standard kernel build. Consequently, all kernel compile warnings are reported as errors. In non-production environments, the -Werror flag can be disabled by removing the following two lines from the top-level kernel Makefile:

KBUILD_CFLAGS   += $(shell if [ $(CPP_VERS) -ge 4004004 ]; then \
                 echo "-Wno-array-bounds -Werror"; else echo ""; fi)

Note, however, that Red Hat does not support custom built kernels or custom built modules.

Some SystemTap probes require the additional module, uprobes.ko at run time. This additional module is usually built automatically when the script is compiled. However, in the client-server case, the uprobes.ko module is not returned by the server to the client. Consequently, missing symbols are reported when the module representing the script is loaded. To work around this issue, use the following command to manually build the uprobes.ko module on the client host.

  make -C <prefix>/share/systemtap/runtime/uprobes

Note that "<prefix>" is the install prefix for systemtap, and that this manual build of uprobes.ko will only need to be done once.

Due to the way ftrace works when modifying the code during startup, the NMI watchdog causes too much noise and ftrace can not find a quiet period to instrument the code. Consequently, machines with more than 512 cpus will encounter issues with the NMI watchdog. Such issues will return error messages similar to "BUG: NMI Watchdog detected LOCKUP" and have either 'ftrace_modify_code' or 'ipi_handler' in the backtrace. To work around this issue, disable nmi_watchdog using the command:

nmi_watchdog=0

Under some circumstances, a kernel panic on installation or boot may occur if the "Interrupt Remapping" feature is enabled in the BIOS. To work around this issue, disable interrupt remapping in the BIOS.

The kernel will panic when booting the kdump kernel on a s390 system with an initramfs that contains an odd number of bytes. To work around this this issue, generate an initramfs with sufficient padding such that it contains an even number of bytes.

Creating many 'cpu' control groups (cgroups) on a system with a large number of CPUs will slow down the machine when the control groups feature is enabled. To work around this issue, disable control groups.

Under certain circumstances, the Linux kernel makes an erroneous assumption about where to reserve memory for the kdump kernel on large-memory POWER systems. Consequently, a newly installed POWER system may return the following message during the initial post installation bootup:

returning from prom_init
 Kernel panic - not syncing: ERROR: Failed to allocate 0x4000 bytes below 0x10000000.
 Rebooting in 180 seconds..

Complete the following steps to work around this issue. Note, however, that this work around disables the kdump feature.

On 64-bit POWER systems the EHEA NIC driver will fail when attempting to dump a vmcore via NFS. To work around this issue, utilize other kdump facilities, for example dumping to the local filesystem, or dumping over SSH.

A BIOS emulated floppy disk might cause the installation or kernel boot process to hang. To avoid this, disable emulated floppy disk support in the BIOS.

The preferred method to enable nmi_watchdog on 32-bit x86 systems is to use either nmi_watchdog=2 or nmi_watchdog=lapic parameters. The parameter nmi_watchdog=1 is not supported.

The module loading operation of certain crypto libraries will not be successful. Consequently, the modules required for in-kernel crypto cannot be loaded. In-kernel crypto cannot be used with Red Hat Enterprise Linux 6 until this issue is resolved.

A BIOS issue on some platforms incorrectly indicates that the system busmastering flag must be checked before entering the deep C state. Consequently, some systems might spend a significantly lower percentage of time in deep C states (C3 and lower) in Red Hat Enterprise Linux 6 compared to Red Hat Enterprise Linux 5.5. Updated the BIOS on affected systems will resolve this issue.

IMA in Red Hat Enterprise Linux 6.0 GA is enabled by loading an IMA policy. However, future updates will require the boot parameter "ima=on" in addition to loading an IMA policy to enable IMA. This change reduces overhead on systems not using IMA.