Call Trace V6.4.1


Recommended Posts

Had a call trace error overnight. This is the single call trace entry in the syslog and it relates to btrfs. Is this anything I should be concerned about? Thanks!

 

Feb 17 02:57:14 Tower kernel: ------------[ cut here ]------------
Feb 17 02:57:14 Tower kernel: WARNING: CPU: 30 PID: 23847 at fs/btrfs/inode.c:9561 btrfs_destroy_inode+0x3d/0x1ea
Feb 17 02:57:14 Tower kernel: Modules linked in: xt_CHECKSUM iptable_mangle ipt_REJECT nf_reject_ipv4 ebtable_filter ebtables ip6table_filter ip6_tables vhost_net tun vhost tap xt_nat veth ipt_MASQUERADE nf_nat_masquerade_ipv4 iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 iptable_filter ip_tables nf_nat xfs md_mod nct6775 hwmon_vid bonding e1000e ptp pps_core ipmi_ssif sb_edac x86_pkg_temp_thermal intel_powerclamp coretemp kvm_intel kvm crct10dif_pclmul crc32_pclmul crc32c_intel ghash_clmulni_intel pcbc aesni_intel aes_x86_64 crypto_simd ast ttm glue_helper i2c_algo_bit drm_kms_helper cryptd drm isci libsas intel_cstate intel_uncore agpgart ahci syscopyarea libahci i2c_i801 sysfillrect sysimgblt intel_rapl_perf i2c_core fb_sys_fops scsi_transport_sas wmi ipmi_si button [last unloaded: pps_core]
Feb 17 02:57:14 Tower kernel: CPU: 30 PID: 23847 Comm: dpkg Not tainted 4.14.16-unRAID #1
Feb 17 02:57:14 Tower kernel: Hardware name: To Be Filled By O.E.M. To Be Filled By O.E.M./EP2C602-4L/D16, BIOS P1.80 01/16/2014
Feb 17 02:57:14 Tower kernel: task: ffff8808a3c33800 task.stack: ffffc9000b6d8000
Feb 17 02:57:14 Tower kernel: RIP: 0010:btrfs_destroy_inode+0x3d/0x1ea
Feb 17 02:57:14 Tower kernel: RSP: 0018:ffffc9000b6dbea8 EFLAGS: 00010202
Feb 17 02:57:14 Tower kernel: RAX: 0000000000000000 RBX: ffff8808989245f0 RCX: 0000000000000001
Feb 17 02:57:14 Tower kernel: RDX: 0000000000000047 RSI: 0000000000000001 RDI: ffff8808989245f0
Feb 17 02:57:14 Tower kernel: RBP: ffff880859607000 R08: ffffffff81c05370 R09: ffffffff811e8200
Feb 17 02:57:14 Tower kernel: R10: ffffea0022eab300 R11: ffff8808b8a03e01 R12: 0000000000000000
Feb 17 02:57:14 Tower kernel: R13: ffff880899787200 R14: 000000000085af70 R15: ffff8808989245f0
Feb 17 02:57:14 Tower kernel: FS:  000014b656539800(0000) GS:ffff88105f580000(0000) knlGS:0000000000000000
Feb 17 02:57:14 Tower kernel: CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
Feb 17 02:57:14 Tower kernel: CR2: 0000000000b112a8 CR3: 000000088f338003 CR4: 00000000000626e0
Feb 17 02:57:14 Tower kernel: Call Trace:
Feb 17 02:57:14 Tower kernel: do_unlinkat+0x127/0x1ef
Feb 17 02:57:14 Tower kernel: entry_SYSCALL_64_fastpath+0x24/0x87
Feb 17 02:57:14 Tower kernel: RIP: 0033:0x14b655e29a57
Feb 17 02:57:14 Tower kernel: RSP: 002b:00007ffe23b2d9d8 EFLAGS: 00000297
Feb 17 02:57:14 Tower kernel: Code: 01 00 00 48 8b af 10 fe ff ff 48 85 c0 74 02 0f ff 48 83 bb c8 01 00 00 00 74 02 0f ff 83 7b 94 00 74 02 0f ff 83 7b 98 00 74 02 <0f> ff 48 83 bb 50 ff ff ff 00 74 02 0f ff 48 83 bb 58 ff ff ff 
Feb 17 02:57:14 Tower kernel: ---[ end trace 6c21fc2742d26e69 ]---

 

Link to comment

Was hoping for some other clue but don't see none, you have 3 btrfs filesystem and can't say which one caused the trace, run a read only btrfs check on the cache device, you need to start the in maintenance mode, if no issues there it's likely the docker or libvirt images, see if it happens again or it was a one time thing, if it does docker image is easy to recreate, for libvirt make a backup of it or the xmls in case it's needed.

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.