Last Modified: Jan 30, 2024
Affected Product(s):
BIG-IP All, Install/Upgrade
Known Affected Versions:
13.1.0, 13.1.0.1, 13.1.0.2, 13.1.0.3, 13.1.0.4, 13.1.0.5, 13.1.0.6, 13.1.0.7, 13.1.0.8, 13.1.1, 13.1.1.2, 13.1.1.3, 13.1.1.4, 13.1.1.5, 13.1.3, 13.1.3.1, 13.1.3.2, 13.1.3.3, 13.1.3.4, 13.1.3.5, 13.1.3.6, 13.1.4, 13.1.4.1, 13.1.5, 13.1.5.1, 14.1.0, 14.1.0.1, 14.1.0.2, 14.1.0.3, 14.1.0.5, 14.1.0.6, 14.1.2, 14.1.2.1, 14.1.2.2, 14.1.2.3, 14.1.2.4, 14.1.2.5, 14.1.2.6, 14.1.2.7, 14.1.2.8, 14.1.3, 14.1.3.1, 14.1.4, 14.1.4.1, 14.1.4.2, 14.1.4.3, 15.0.0, 15.0.1, 15.0.1.1, 15.0.1.2, 15.0.1.3, 15.0.1.4, 15.1.0, 15.1.0.1, 15.1.0.2, 15.1.0.3, 15.1.0.4, 15.1.0.5, 15.1.1, 15.1.2, 15.1.2.1, 15.1.3, 16.0.0, 16.0.0.1, 16.0.1, 16.0.1.1, 16.0.1.2
Fixed In:
16.1.0, 15.1.3.1, 14.1.4.4
Opened: Oct 03, 2020 Severity: 2-Critical
Despite having free memory, the BIG-IP system frequently logs kernel page allocation failures on B4450N blades to the /var/log/kern.log file like the following: swapper/16: page allocation failure: order:2, mode:0x104020 After that, a stack trace follows. Note that the process name in the line ('swapper/16', in this example) varies. You may see generic Linux processes or processes specific to F5 in that line.
As different processes can experience this issue, the system may behave unpredictably. For example, it is possible for a TMOS installation to fail as a result of this issue. Other processes may not exhibit any side effect as a result of this issue. The exact impact depends on which process becomes affected and how this process is designed to handle such a failure to allocate memory.
This occurs on B4450N blades regardless of configuration.
You must perform the workaround on each blade installed in the system. -- If you want the workaround to survive reboots only, perform the following procedure: 1) Log on to the advanced shell (BASH) of the primary blade of the affected VIPRION system. 2) Run the following commands: # clsh "sysctl -w vm.min_free_kbytes=131072" # clsh "echo -e '\n# Workaround for ID950849' >> /etc/sysctl.conf" # clsh "echo 'vm.min_free_kbytes = 131072' >> /etc/sysctl.conf" -- If you want the workaround to survive reboots, upgrades, RMAs, etc., perform the following procedure: 1) Log on to the advanced shell (BASH) of the primary blade of the affected VIPRION system. 2) Run the following commands (with the desired amount in KB): # clsh "sysctl -w vm.min_free_kbytes=131072" # echo -e '\n# Workaround for ID950849' >> /config/startup # echo 'sysctl -w vm.min_free_kbytes=131072' >> /config/startup Note that the last two commands are not wrapped inside 'clsh' because the /config/startup file is already automatically synchronized across all blades. Once the issue is fixed in a future BIG-IP version, remove the workarounds: -- To remove the first workaround: 1) Edit the /etc/sysctl.conf file on all blades and remove the added lines at the bottom. 2) Reboot the system by running 'clsh reboot'. This will restore the min_free_kbytes kernel parameter to its default value for the BIG-IP version you are running. -- To remove the second workaround: 1) Edit the /config/startup file on the primary blade only, and remove the extra lines at the bottom. 2) Reboot the system by running 'clsh reboot'. This restores the min_free_kbytes kernel parameter to its default value for the BIG-IP version you are running. To verify the workaround is in place, run the following command (this should return the desired amount in KB): # clsh "cat /proc/sys/vm/min_free_kbytes"
The BIG-IP system no longer experiences kernel page allocation failures on B4450 (A114) blades.