389-ds-base
component, BZ#1008013
Under certain conditions, when the server is processing multiple outgoing replication or windows sync agreements using the TLS or SSL protocol, and processing incoming client requests that use TLS or SSL, and incoming BIND requests where the password used is hashed using SSHA512, the server becomes unresponsive to new incoming client requests. A restart of the dirsrv
service is required. As the server is unresponsive, restarting can require terminating the ns-slapd
process by running the kill -9
command.
kernel
component
In cluster environment, the multicast traffic from the guest to a host can be unreliable. To work around this problem, enable multicast_querier for the bridge. The setting is located in the /sys/class/net/<bridge_name>/bridge/multicast_querier
file. Note that if the setting is not available, the problem should not occur.
kernel
component
A missing part of the bcma
driver causes the brcmsmac
driver not to load automatically when the bcma
driver scans the for devices. This causes the kernel not to load the brcmsmac
module automatically on boot. Symptoms can be confirmed by running the lspci -v
command for the device and noting the driver to be bmca
, not brcmsmac
. To load the driver manually, run modprobe brcmsmac
on the command line.
389-ds-base
component
Under certain conditions, when the server is processing multiple outgoing replication or windows sync agreements using the TLS or SSL protocol, and processing incoming client requests that use TLS or SSL and Simple Paged Results, the server becomes unresponsive to new incoming client requests. The dirsrv
service will stop responding to new incoming client requests. A restart of the dirsrv
service is required to restore service.
kernel
component, BZ#1003475
When some Fibre Channel over Ethernet (FCoE) switch ports connected to the bfa host bus adapter go offline and then return in the online state, the bfa port may not re-establish the connection with the switch. This is due to a failure of the bfa driver's retry logic when interacting with certain switches. To work around this problem, reset the bfa link. This can be done either by running:
]# echo 1 > /sys/class/fc_host/host/issue_lip
or by running:
]# modprobe -r bfa && modprobe bfa
anaconda
component, BZ#984129
For HP systems running in HP FlexFabric mode, the designated iSCSI function can only be used for iSCSI offload related operations and will not be able to perform any other Layer 2 networking tasks, for example, DHCP. In the case of iSCSI boot from SAN, the same SAN MAC address is exposed to both the corresponding ifconfig record and the iSCSI Boot Firmware Table (iBFT), therefore, Anaconda will skip the network selection prompt and will attempt to acquire the IP address as specified by iBFT. If DHCP is desired, Anaconda will attempt to acquire DHCP using this iSCSI function, which will fail and Anaconda will then try to acquire DHCP indefinitely. To work around this problem, if DHCP is desired, the user must use the asknetwork
installation parameter and provide a "dummy" static IP address to the corresponding network interface of the iSCSI function. This prevents Anaconda from entering an infinite loop and allows it to request the iSCSI offload function to perform DHCP acquisition instead.
iscsi-initiator-utils
component, BZ#825185
If the corresponding network interface has not been brought up by dracut or the tools from the iscsi-initiator-utils package, this prevents the correct MAC address from matching the offload interface, and host bus adapter (HBA) mode will not work without manual intervention to bring the corresponding network interface up. To work around this problem, the user must select the corresponding Layer 2 network interface when anaconda prompts the user to choose "which network interface to install through". This will inherently bring up the offload interface for the installation.
kernel
component
When an igb
link us up, the following ethtool fields display incorrect values as follows:
Supported ports: [ ] - for example, an empty bracket can be displayed.
Supported pause frame use: No - however, pause frame is supported.
Supports auto-negotiation: No - auto-negotiation is supported.
Advertised pause frame use: No - advertised pause frame is turned on.
Advertised auto-negotiation: No - advertised auto-negotiation is turned on.
Speed: Unknown! - the speed is known and can be verified using the dmesg tool.
linuxptp
component
End-to-End (E2E) slaves that communicated with an E2E master once can synchronize to Peer-to-Peer (P2P) masters and vice versa. The slaves cannot update their path delay value because E2E ports reject peer delay requests from P2P ports. However, E2E ports accept SYNC messages from P2P ports and the slaves keep updating clock frequency based on undesired offset values that are calculated by using the old path delay value. Therefore, a time gap will occur if the master port is started with an incorrect delay mechanism. The "delay request on P2P" or "pdelay_req on E2E port" message can appear. To work around these problems, use a single delay mechanism for one PTP communication path. Also, because E2E and P2P mismatch can trigger a time gap of slave clock, pay attention to the configuration when starting or restarting a node on a running domain.
samba4
component, BZ#878168
If configured, the Active Directory (AD) DNS server returns IPv4 and IPv6 addresses of an AD server. If the FreeIPA server cannot connect to the AD server with an IPv6 address, running the ipa trust-add
command will fail even if it would be possible to use IPv4. To work around this problem, add the IPv4 address of the AD server to the /etc/hosts
file. In this case, the FreeIPA server will use only the IPv4 address and executing ipa trust-add
will be successful.
kernel
component
Destroying the root port before any NPIV ports can cause unexpected system behavior, including a full system crash. Note that one instance where the root port is destroyed before the NPIV ports is when the system is shut down. To work around this problem, destroy NPIV ports before destroying the root port that the NPIV ports were created on. This means that for each created NPIV port, the user should write to the sysfs vport_delete
interface to delete that NPIV port. This should be done before the root port is destroyed. Users are advised to script the NPIV port deletion and configure the system such that the script is executed before the fcoe
service is stopped, in the shutdown sequence.
kernel
component
A Linux LIO FCoE target causes the bfa
driver to reset all FCoE targets which might lead to data corruption on LUN. To avoid these problems, do not use the bfa
driver with a Linux FCoE target.
kernel
component
Typically, on platforms with no Intelligent Platform Management Interface (IPMI) hardware the user can see the following message the on the boot console and in dmesg log:
Could not set up I/O space
This message can be safely ignored, unless the system really does have IPMI hardware. In that case, the message indicates that the IPMI hardware could not be initialized. In order to support Advanced Configuration and Power Interface (ACPI) opregion access to IPMI functionality early in the boot, the IPMI driver has been statically linked with the kernel image. This means that the IPMI driver is "loaded" whether or not there is any hardware. The IPMI driver will try to initialize the IPMI hardware, but if there is no IPMI hardware present on the booting platform, the driver will print error messages on the console and in the dmesg log. Some of these error messages do not identify themselves as having been issued by the IPMI driver, so they can appear to be serious, when they are harmless.
fcoe-utils
component
After an ixgbe Fibre Channel over Ethernet (FCoE) session is created, server reboot can cause some or all of the FCoE sessions to not be created automatically. To work around this problem, follow the following steps (assuming that eth0 is the missing NIC for the FCoE session):
ifconfig eth0 down
ifconfig eth0 up
sleep 5
dcbtool sc eth0 dcb on
sleep 5
dcbtool sc eth0 pfc e:1 a:1 w:1
dcbtool sc eth0 app:fcoe e:1 a:1 w:1
service fcoe restart
libibverbs
component
The InfiniBand UD transport test utility could become unresponsive when the ibv_ud_pingpong
command was used with a packet size of 2048 or greater. UD is limited to no more than the smallest MTU of any point in the path between point A and B, which is between 0 and 4096 given that the largest MTU supported (but not the smallest nor required) is 4096. If the underlying Ethernet is jumbo frame capable, and with a 4096 IB MTU on an RoCE device, the max packet size that can be used with UD is 4012 bytes.
bind-dyndb-ldap
component
IPA creates a new DNS zone in two separate steps. When the new zone is created, it is invalid for a short period of time. A/AAAA
records for the name server belonging to the new zone are created after this delay. Sometimes, BIND attempts to load this invalid zone and fails. In such a case, reload BIND by running either rndc reload
or service named restart
.
bind-dyndb-ldap
component, BZ#1142176
The bind-dyndb-ldap
library incorrectly compares current time and the expiration time of the Kerberos ticket used for authentication to an LDAP server. As a consequence, the Kerberos ticket is not renewed under certain circumstances, which causes the connection to the LDAP server to fail. The connection failure often happens after a BIND
service reload is triggered by the logrotate
utility, and you need to run the pkill -9 named
command to terminate BIND after a deadlock occurs. To work around this problem, set the validity period of the Kerberos ticket to be at least 10 minutes shorter than the logrotate period.
bind-dyndb-ldap
component, BZ#1142152
The BIND
service incorrectly handles errors returned by dynamic databases (from dyndb API). As a consequence, BIND
enters a deadlock situation on shutdown under certain circumstances. No workaround is available at the moment. If the deadlock occurs, terminate BIND
by running the pkill -9 named
command and restart the service manually.
kernel
component
The latest version of the sfc NIC driver causes lower UDP and TX performance with large amounts of fragmented UDP packets. This problem can be avoided by setting a constant interrupt moderation period (not adaptive moderation) on both sides, sending and receiving.
kernel
component
Some network interface cards (NICs) might fail to get an IPv4 address assigned after the system is booted. The default time to wait for the link to come up is 5 seconds. To work around this issue, increase this wait time by specifying the LINKDELAY directive in the interface configuration file. For example, add the following line to the /etc/sysconfig/network-scripts/ifcfg-<interface>
file:
LINKDELAY=10
In addition, check STP settings on all network switches in the path of the DHCP server as the default STP forward delay is 15 seconds.
samba
component
Current Samba versions shipped with Red Hat Enterprise Linux 6 are not able to fully control the user and group database when using the
ldapsam_compat
back end. This back end was never designed to run a production LDAP and Samba environment for a long period of time. The
ldapsam_compat
back end was created as a tool to ease migration from historical Samba releases (version 2.2.x) to Samba version 3 and greater using the new
ldapsam
back end and the new LDAP schema. The
ldapsam_compat
back end lack various important LDAP attributes and object classes in order to fully provide full user and group management. In particular, it cannot allocate user and group IDs. In the
Red Hat Enterprise Linux Reference Guide, it is pointed out that this back end is likely to be deprecated in future releases. Refer to Samba's
documentation for instructions on how to migrate existing setups to the new LDAP schema.
When you are not able to upgrade to the new LDAP schema (though upgrading is strongly recommended and is the preferred solution), you may work around this issue by keeping a dedicated machine running an older version of Samba (v2.2.x) for the purpose of user account management. Alternatively, you can create user accounts with standard LDIF files. The important part is the assignment of user and group IDs. In that case, the old Samba 2.2 algorithmic mapping from Windows RIDs to Unix IDs is the following: user RID = UID * 2 + 1000, while for groups it is: group RID = GID * 2 + 1001. With these workarounds, users can continue using the ldapsam_compat
back end with their existing LDAP setup even when all the above restrictions apply.
kernel
component
Because Red Hat Enterprise Linux 6 defaults to using Strict Reverse Path filtering, packets are dropped by default when the route for outbound traffic differs from the route of incoming traffic. This is in line with current recommended practice in RFC3704. For more information about this issue please refer to
/usr/share/doc/kernel-doc-<version>/Documentation/networking/ip-sysctl.txt
and
https://access.redhat.com/site/solutions/53031.