Red Hat Bugzilla – Bug 1259296
[abrt] kernel paging request at dentry_free
Last modified: 2015-09-04 03:38:58 EDT
Additional info: reporter: libreport-2.6.2 BUG: unable to handle kernel paging request at ffff88080e9ca328 IP: [<ffffffff812431a0>] dentry_free+0x70/0xb0 PGD 2039067 PUD 0 Oops: 0002 [#1] SMP Modules linked in: usblp vfat fat bnep bluetooth fuse xt_CHECKSUM ipt_MASQUERADE nf_nat_masquerade_ipv4 tun nf_conntrack_netbios_ns nf_conntrack_broadcast ccm ip6t_rpfilter ip6t_REJECT nf_reject_ipv6 xt_conntrack ebtable_nat ebtable_broute bridge ebtable_filter ebtables ip6table_nat nf_conntrack_ipv6 nf_defrag_ipv6 nf_nat_ipv6 ip6table_mangle ip6table_security ip6table_raw ip6table_filter ip6_tables iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack iptable_mangle iptable_security iptable_raw ipheth snd_usb_audio snd_usbmidi_lib snd_rawmidi intel_rapl iosf_mbi x86_pkg_temp_thermal coretemp kvm_intel kvm crct10dif_pclmul crc32_pclmul crc32c_intel gpio_ich iTCO_wdt snd_hda_codec_conexant snd_hda_codec_generic snd_hda_codec_hdmi arc4 ghash_clmulni_intel iTCO_vendor_support snd_hda_intel snd_hda_controller snd_hda_codec snd_seq snd_seq_device ath9k ath9k_common ath9k_hw ath mac80211 cfg80211 rfkill snd_hda_core snd_hwdep snd_pcm mei_me dcdbas mei shpchp i8k lpc_ich mfd_core snd_timer snd soundcore i2c_i801 nfsd auth_rpcgss nfs_acl lockd grace sunrpc amdkfd amd_iommu_v2 radeon i2c_algo_bit drm_kms_helper ttm drm 8021q garp stp llc uas mrp r8169 ata_generic serio_raw pata_acpi usb_storage mii CPU: 2 PID: 1777 Comm: umount Not tainted 4.1.6-200.fc22.x86_64 #1 Hardware name: Dell Inc. Vostro 260 /0GDG8Y , BIOS A04 11/21/2011 task: ffff880229c19da0 ti: ffff8802333c8000 task.ti: ffff8802333c8000 RIP: 0010:[<ffffffff812431a0>] [<ffffffff812431a0>] dentry_free+0x70/0xb0 RSP: 0018:ffff8802333cbd18 EFLAGS: 00010206 RAX: ffff88080e9ca338 RBX: ffff88000e9ca300 RCX: 0000000000000004 RDX: ffff88000e9ca338 RSI: ffff88019befac98 RDI: ffff88000e9ca300 RBP: ffff8802333cbd28 R08: ffff88000e9ca390 R09: 0000000000000246 R10: ffffffff811bef4b R11: 0000000000000000 R12: ffff88019befac10 R13: ffff88000e9ca358 R14: ffff88000e9ca300 R15: ffff88000e9ca358 FS: 00007fb6a2e5f840(0000) GS:ffff88023f500000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffff88080e9ca328 CR3: 0000000232a7c000 CR4: 00000000000406e0 Stack: ffff88000e9ca358 ffff88000e9ca300 ffff8802333cbd58 ffffffff81243bb1 ffff8802333cbd58 ffff880118990840 ffff88000e9ca380 ffff8802333cbdc8 ffff8802333cbda8 ffffffff8124414c ffffffff81243040 ffff8802333cbdc0 Call Trace: [<ffffffff81243bb1>] __dentry_kill+0x151/0x1f0 [<ffffffff8124414c>] shrink_dentry_list+0x10c/0x2e0 [<ffffffff81243040>] ? d_lru_del+0xb0/0xb0 [<ffffffff81244498>] shrink_dcache_parent+0x38/0x90 [<ffffffff81104f10>] ? __call_rcu+0x370/0x370 [<ffffffff81244506>] do_one_tree+0x16/0x50 [<ffffffff8124565f>] shrink_dcache_for_umount+0x2f/0x90 [<ffffffff8122d1ac>] generic_shutdown_super+0x2c/0x100 [<ffffffff8122d587>] kill_block_super+0x27/0x80 [<ffffffff8122d8f9>] deactivate_locked_super+0x49/0x80 [<ffffffff8122dd6c>] deactivate_super+0x6c/0x80 [<ffffffff8124c853>] cleanup_mnt+0x43/0xa0 [<ffffffff8124c902>] __cleanup_mnt+0x12/0x20 [<ffffffff810beff4>] task_work_run+0xc4/0xe0 [<ffffffff81014d1d>] do_notify_resume+0x9d/0xa0 [<ffffffff817a20fc>] int_signal+0x12/0x17 Code: 5d c3 66 0f 1f 84 00 00 00 00 00 48 8b 3d 69 d5 ae 00 48 89 de e8 71 84 fc ff 48 83 c4 08 5b 5d c3 66 2e 0f 1f 84 00 00 00 00 00 <f0> ff 48 f0 74 22 eb b0 0f 1f 84 00 00 00 00 00 be 35 01 00 00 RIP [<ffffffff812431a0>] dentry_free+0x70/0xb0 RSP <ffff8802333cbd18> CR2: ffff88080e9ca328
Created attachment 1069380 [details] File: dmesg
The failing instruction is: f0 ff 48 f0 lock decl -0x10(%rax) Looking at some registers, it may be that you had a single bit flip. I'd try running memtest. RAX: ffff88080e9ca338 RDX: ffff88000e9ca338 RDI: ffff88000e9ca300
I had tested the memory extensively with Memtest86+ from the Fedora Live media (over night, multiple passes) a few months ago, when I bought it from Crucial, without finding any problems. I tested it again now, and you were right: it immediately found 3 faulty bits in the first 256MB, always the same bits, a few thousand occurences. I didn't think it can go bad after inserting and testing it. Thanks for looking into this!