Description of problem: Not sure what happened -- ABRT just popped up. I was working on an external USB3.0 hard drive. The filesystem had an odd history: - another disk was dying, so I ddrescued as much as I could to the new disk - I used ddrescue to feed a bad block list into e2fsck applied to the new disk (Of course those blocks weren't bad on the new disk, but they were "holes" left by dead blocks on the original disk's filesystem.) - the new filesystem seemed good, albeit some files had damage - the ABRT seemed to happen while I was copying files from another source to the new filesystem. - I think that I had used e2label on that partition. But that might have been after the ABRT. Interestingly, ABRT did not offer to submit this report. I later manually invoked it to make this report. Additional info: reporter: libreport-2.1.5 kernel BUG at fs/inode.c:1435! invalid opcode: 0000 [#1] SMP Modules linked in: tcp_lp ebtable_nat fuse nf_conntrack_netbios_ns nf_conntrack_broadcast ipt_MASQUERADE ip6table_nat nf_nat_ipv6 ip6table_mangle ip6t_REJECT nf_conntrack_ipv6 nf_defrag_ipv6 iptable_nat nf_nat_ipv4 nf_nat iptable_mangle bnep nf_conntrack_ipv4 nf_defrag_ipv4 bluetooth xt_conntrack nf_conntrack rfkill ebtable_filter ebtables ip6table_filter ip6_tables iTCO_wdt iTCO_vendor_support snd_hda_codec_hdmi snd_hda_codec_realtek acpi_cpufreq mperf coretemp kvm_intel kvm microcode i2c_i801 lpc_ich mfd_core ses snd_hda_intel enclosure snd_hda_codec snd_hwdep snd_seq snd_seq_device snd_pcm e1000e snd_page_alloc snd_timer snd ptp soundcore pps_core uinput radeon i2c_algo_bit drm_kms_helper firewire_ohci ttm firewire_core crc_itu_t drm i2c_core usb_storage CPU: 0 PID: 42 Comm: kswapd0 Not tainted 3.10.3-300.fc19.x86_64 #1 Hardware name: HP-Pavilion GV465AA-ABA a6245n/Berkeley, BIOS 5.13 10/24/2007 task: ffff8801a6a0adc0 ti: ffff8801a678e000 task.ti: ffff8801a678e000 RIP: 0010:[<ffffffff811b1207>] [<ffffffff811b1207>] iput+0x147/0x180 RSP: 0018:ffff8801a678fbb8 EFLAGS: 00010202 RAX: 0000000000000000 RBX: ffff8800901370f0 RCX: dead000000200200 RDX: 0000000000000000 RSI: ffffc900004d5698 RDI: ffff8800901370f0 RBP: ffff8801a678fbd8 R08: ffff880090067150 R09: 000000000000000c R10: 0000000000000000 R11: 0000000000000000 R12: ffff880090067140 R13: ffff8801a678fc38 R14: ffff8800900670c0 R15: ffff8800901370f0 FS: 0000000000000000(0000) GS:ffff8801afc00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b CR2: 00000000019bb0e0 CR3: 0000000148944000 CR4: 00000000000007f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 Stack: ffff8800932d8780 ffff880090067140 ffff8801a678fc38 ffff8800900670c0 ffff8801a678fc18 ffffffff811ad81e ffff880090067140 ffff88009019cc5c ffff8801a3ee2800 0000000000000000 ffff8801a3ee28d0 ffff88009019cc80 Call Trace: [<ffffffff811ad81e>] shrink_dentry_list+0x38e/0x3d0 [<ffffffff811ae31b>] prune_dcache_sb+0x12b/0x150 [<ffffffff8119b060>] prune_super+0x160/0x1a0 [<ffffffff8113f8e5>] shrink_slab+0x165/0x300 [<ffffffff8114308e>] balance_pgdat+0x45e/0x5b0 [<ffffffff8114333b>] kswapd+0x15b/0x410 [<ffffffff81081890>] ? wake_up_bit+0x30/0x30 [<ffffffff811431e0>] ? balance_pgdat+0x5b0/0x5b0 [<ffffffff81080b00>] kthread+0xc0/0xd0 [<ffffffff81080a40>] ? insert_kthread_work+0x40/0x40 [<ffffffff8165176c>] ret_from_fork+0x7c/0xb0 [<ffffffff81080a40>] ? insert_kthread_work+0x40/0x40 Code: 00 00 00 eb a0 0f 1f 80 00 00 00 00 48 81 8b 98 00 00 00 00 01 00 00 48 89 df e8 35 fe ff ff 80 83 88 00 00 00 01 e9 f8 fe ff ff <0f> 0b be 70 05 00 00 48 c7 c7 e1 0f a1 81 e8 b6 b0 ea ff e9 06 RIP [<ffffffff811b1207>] iput+0x147/0x180 RSP <ffff8801a678fbb8>
Created attachment 781452 [details] File: dmesg
*********** MASS BUG UPDATE ************** We apologize for the inconvenience. There is a large number of bugs to go through and several of them have gone stale. Due to this, we are doing a mass bug update across all of the Fedora 19 kernel bugs. Fedora 19 has now been rebased to 3.11.1-200.fc19. Please test this kernel update and let us know if you issue has been resolved or if it is still present with the newer kernel. If you experience different issues, please open a new bug report for those.
This bug is being closed with INSUFFICIENT_DATA as there has not been a response in 2 weeks. If you are still experiencing this issue, please reopen and attach the relevant data from the latest kernel you are running and any data that might have been requested previously.