Last Modified: Jun 08, 2022
See more info
Known Affected Versions:
14.1.0, 184.108.40.206, 220.127.116.11, 18.104.22.168, 22.214.171.124, 126.96.36.199, 14.1.2, 188.8.131.52, 184.108.40.206, 220.127.116.11, 18.104.22.168, 22.214.171.124, 126.96.36.199, 188.8.131.52, 184.108.40.206, 14.1.3, 220.127.116.11, 14.1.4, 18.104.22.168, 22.214.171.124, 126.96.36.199, 188.8.131.52, 184.108.40.206, 220.127.116.11, 14.1.5, 15.0.0, 15.0.1, 18.104.22.168, 22.214.171.124, 126.96.36.199, 188.8.131.52, 15.1.0, 184.108.40.206, 220.127.116.11, 18.104.22.168, 22.214.171.124, 126.96.36.199, 15.1.1, 15.1.2, 188.8.131.52, 15.1.3, 184.108.40.206, 15.1.4, 220.127.116.11, 15.1.5, 18.104.22.168, 15.1.6
Opened: Nov 21, 2019
Despite having free memory, the BIG-IP system logs kernel page allocation failures to the /var/log/kern.log file. The first line of the output appears similar to the following example: swapper/13: page allocation failure: order:2, mode:0x204020 After that, a stack trace follows. The process name in the line ('swapper/16', in this example). 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 issue is known to occur on the appliance 10350V-F D112.
You can work around this issue by increasing the value of the min_free_kbytes kernel parameter. This controls the amount of memory that is kept free for use by special reserves. It is recommend to increase this to 128 MB (131072 KB). When instantiating this workaround, you must consider whether you want the workaround to survive only reboots, or to survive reboots, upgrades, RMAs, etc. This is an important consideration to make, as you should stop using this workaround when this issue is fixed in a future version of BIG-IP software. So consider the pros and cons of each approach before choosing one. -- 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 system. 2) Run the following commands (with the desired amount in KB): # clsh "sysctl -w vm.min_free_kbytes=131072" # clsh "echo -e '\n# Workaround for ID 851785' >> /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 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 ID851785' >> /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 the BIG-IP appliance 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 BIG-IP appliance 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 excessive kernel page allocation failures.