In addition to Weibo, there is also WeChat
Please pay attention
WeChat public account
Shulou
2025-02-22 Update From: SLTechnology News&Howtos shulou NAV: SLTechnology News&Howtos > Servers >
Share
Shulou(Shulou.com)06/02 Report--
Problem description
Recent machines have the following warning messages at different times of the day:
Mar 26 20:55:03 host1 kernel: WARNING: at fs/xfs/xfs_aops.c:1045 xfs_vm_releasepage+0xcb/0x100 [xfs] () Mar 26 20:55:03 host1 kernel: Modules linked in: nf_conntrack_ipv4 nf_defrag_ipv4 xt_conntrack nf_conntrack iptable_filter ip_tables ebtable_filter ebtables ip6table_filter ip6_tables devlink bridge stp llc xt_multiport sunrpc dm_mirror dm_region_hash dm_log dm_mod intel_powerclamp coretemp intel_rapl iosf_mbi kvm_intel kvm irqbypass crc32 _ pclmul ghash_clmulni_intel aesni_intel lrw gf128mul glue_helper ablk_helper cryptd iTCO_wdt iTCO_vendor_support dcdbas ipmi_devintf ipmi_si sg pcspkr ipmi_msghandler shpchp i2c_i801 lpc_ich nfit libnvdimm acpi_power_meter kgwttm (OE) xfs libcrc32c sd_mod crc_t10dif crct10dif_generic crct10dif_pclmul crct10dif_common crc32c_intel mgag200 drm_kms_helper igb syscopyarea sysfillrect sysimgblt ptp fb_sys_fops ttm pps_core dca ahci drm i2c_algo_bit libahci megaraid_sas i2c_core libataMar 26 20:55:03 host1 Kernel: fjes [last unloaded: nf_defrag_ipv4] Mar 26 20:55:03 host1 kernel: CPU: 10 PID: 224 Comm: kswapd0 Tainted: G OE-3.10.0-514.21.2.el7.x86_64 # 1Mar 26 20:55:03 host1 kernel: Hardware name: Dell Inc. PowerEdge R640/0W23H8 BIOS 1.3.7 02/08/2018Mar 26 20:55:03 host1 kernel: 0000000000000000 00000000e02a0d05 ffff88103c7ebaa0 ffffffff81687073Mar 26 20:55:03 host1 kernel: ffff88103c7ebad8 ffffffff81085cb0 ffffea0000687620 ffffea0000687600Mar 26 20:55:03 host1 kernel: ffff88004a71daf8 ffff88103c7ebda0 ffffea0000687600 ffff88103c7ebae8Mar 26 20:55:03 host1 kernel: Call Trace:Mar 26 20:55:03 host1 kernel: [] dump_stack+0x19/0x1bMar 26 20:55:03 host1 kernel: [] warn_slowpath_common+0x70/0xb0Mar 26 20:55:03 host1 kernel: [] warn_slowpath_null+0x1a/0x20Mar 26 20 : 55:03 host1 kernel: [] xfs_vm_releasepage+0xcb/0x100 [xfs] Mar 26 20:55:03 host1 kernel: [] try_to_release_page+0x32/0x50Mar 26 20:55:03 host1 kernel: [] shrink_active_list+0x3d6/0x3e0Mar 26 20:55:03 host1 kernel: [] shrink_lruvec+0x3f1/0x770Mar 26 20:55:03 host1 kernel: [] shrink_zone+0x76/0x1a0Mar 26 20:55:03 host1 kernel: [] balance_pgdat+0x48c/0x5e0Mar 26 20:55:03 host1 kernel : [] kswapd+0x173/0x450Mar 26 20:55:03 host1 kernel: []? Wake_up_atomic_t+0x30/0x30Mar 26 20:55:03 host1 kernel: []? Balance_pgdat+0x5e0/0x5e0Mar 26 20:55:03 host1 kernel: [] kthread+0xcf/0xe0Mar 26 20:55:03 host1 kernel: []? Kthread_create_on_node+0x140/0x140Mar 26 20:55:03 host1 kernel: [] ret_from_fork+0x58/0x90Mar 26 20:55:03 host1 kernel: []? Kthread_create_on_node+0x140/0x140Mar 26 20:55:03 host1 kernel:-[end trace 24823c5c7a1ea2be]-
The crash information such as kernel and applications of these machines is taken over by the abrtd service. You can view the summary information through abrt-cli:
# abrt-cli list-- since 1547518209id 2181dce8f72761585cb6a904dbff1806c1315c27reason: WARNING: at fs/xfs/xfs_aops.c:1045 xfs_vm_releasepage+0xcb/0x100 [xfs] () time: Sat 23 Mar 2019 08:30:45 PM CSTcmdline: BOOT_IMAGE=/boot/vmlinuz-3.10.0-514.16.1.el7.x86_64 root=/dev/sda1 ro crashkernel=auto net.ifnames=0 biosdevname=0package: kerneluid: 0 (root) count: 1Directory: / var/spool/abrt / oops-2019-03-23-20:30:45-163925-0
The kernel version is as follows:
Centos7
Linux host1 3.10.0-514.21.2.el7.x86_64
Analysis and treatment
Red Hat knowledge Base
Referring to the Red Hat knowledge base document, this kind of warning message of xfs will be printed when the xfs module traverses the code path, which does not affect the use of the host. Upgradeable kernel to kernel-3.10.0-693.el7 version avoids this warning, see redhat-access-2893711 for details
Root Cause:
The messages were informational and they do not affect the system in a negative manner. They are seen because the XFS module is traversing through XFS code path.
Code analysis
The memory recovery information is not mentioned in the Red Hat knowledge base, but from the stack information, it looks like it is caused by memory recovery by the kernel. Check the memory usage at the corresponding time point as follows:
04:30:01 PM kbmemfree kbmemused% memused kbbuffers kbcached kbcommit% commit kbactive kbinact kbdirty.08:40:01 PM 513940 130976220 99.61876 104616380 28610584 21.7692439660 34840920 52408 PM 479896 131010264 99.64876 104666496 28557292 21.72 92513872 34804240 40009V 0001 PM 455948131034212 99.65104675712 28588852 21.74 92418724 34926132 5720912 1001 PM 556980130933180 99.58104610552 28552656 21.71 9287212 32983892 sysctl Vm.min_free_kbytesvm.min_free_kbytes = 90112
The available memory has not increased between 20:50 and 21:00, which means that the system may not have done a memory recycling operation. Let's look at the function call relationship according to the stack information of the kernel log:
Shrink_active_list-> try_to_release_page-> xfs_vm_releasepage//source/mm/filemap.c3225 int try_to_release_page (struct page * page, gfp_t gfp_mask) 3226 {3227 struct address_space * const mapping = page- > mapping;.3233 if (mapping & & mapping- > astatops-> releasepage) 3234 return mapping- > apocops-> releasepage (page, gfp_mask); xfs_vm_releasepage3235 return try_to_free_buffers (page) 3236} / / source/fs/xfs/xfs_aops.c1034 STATIC int1035 xfs_vm_releasepage (1036 struct page * page,1037 gfp_t gfp_mask) 1038 {1039 int delalloc, unwritten;1040 1041 trace_xfs_releasepage (page- > mapping- > host, page, 0,0); 1042 1043 xfs_count_page_state (page, & delalloc, & unwritten); 1044 1045 if (WARN_ON_ONCE (delalloc)) 1046 return 0 1047 if (WARN_ON_ONCE (unwritten)) 1048 return 0 *
Corresponding to the kernel log kernel: WARNING: at fs/xfs/xfs_aops.c:1045, you can see that line 1045 of the source file source/fs/xfs/xfs_aops.c prints out the stack information, but in fact, it has been returned without executing try_to_free_buffers:
1045 if (WARN_ON_ONCE (delalloc)) 1046 return 0
WARN_ON_ONCE is relatively simple, which can be found in the source file source/include/asm-generic/bug.h:
73 # define _ _ WARN () warn_slowpath_null (_ _ FILE__, _ LINE__) 85 # define WARN_ON (condition) ({\... 88 _ WARN ();\ 136 # define WARN_ON_ONCE (condition) ({\. 140 if (unlikely (_ _ ret_warn_once)\ 141if (WARN_ON (! _ warned))\
The _ _ WARN function calls the warn_slowpath_null function in the stack information, and then calls the warn_slowpath_common function to print the stack information:
/ source/kernel/panic.c517 void warn_slowpath_null (const char * file, int line) 518 {519 warn_slowpath_common (file, line, _ builtin_return_address (0), 520 TAINT_WARN, NULL); 521} 463 static void warn_slowpath_common (const char * file, int line, void * caller,464 unsigned taint, struct slowpath_args * args) 465 {466 disable_trace_on_warning () 467 468 printk (KERN_WARNING "- [cut here] -\ n"); 469 printk (KERN_WARNING "WARNING: at% SV% d% pS ()\ n", file, line, caller); 470 471 if (args) 472 vprintk (args- > fmt, args- > args); .485 print_modules (); 486 dump_stack (); 487 print_oops_end_marker ()
We can roughly see that this stack message is just a warning, which is consistent with the description in the Red Hat knowledge base and does not affect the use of the host.
Summary description
From the function of the source file above, it is possible to print stack information as long as xfs_vm_releasepage is called when kswapd memory is reclaimed, and try_to_free_buffers operation is not performed if the stack is printed, so there is no increase in available memory when checking memory usage. If you do not want the stack message to appear, you can turn on the kernel.traceoff_on_warning kernel parameter corresponding to the disable_trace_on_warning function to turn off the stack prompt, but other kernel information will not be printed after it is turned off, so from this point of view, only upgrading the kernel version can avoid this message.
Well, the above is the whole content of this article. I hope the content of this article has a certain reference and learning value for your study or work. Thank you for your support.
Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.
Views: 0
*The comments in the above article only represent the author's personal views and do not represent the views and positions of this website. If you have more insights, please feel free to contribute and share.
Continue with the installation of the previous hadoop.First, install zookooper1. Decompress zookoope
"Every 5-10 years, there's a rare product, a really special, very unusual product that's the most un
Ftp 20 (data port) 21 (control port) ssh 22telnet 23DN
© 2024 shulou.com SLNews company. All rights reserved.