Description of problem: I was backing up files using rsync to an external USB hard drive. After this kernel error ocurred, I saw many "Input/output error" messages in rsync output. Additional info: reporter: libreport-2.6.2 WARNING: CPU: 0 PID: 13274 at fs/buffer.c:1143 mark_buffer_dirty+0xbe/0xd0() Modules linked in: dm_crypt nls_utf8 udf crc_itu_t loop bnep bluetooth rfkill uas usb_storage fuse ebtable_filter ebtables ip6table_filter ip6_tables it87 hwmon_vid vfat fat snd_hda_codec_realtek snd_hda_codec_generic intel_rapl snd_hda_codec_hdmi iosf_mbi x86_pkg_temp_thermal coretemp snd_hda_intel kvm_intel iTCO_wdt iTCO_vendor_support snd_hda_controller snd_hda_codec kvm snd_hda_core snd_hwdep snd_seq crct10dif_pclmul crc32_pclmul crc32c_intel ghash_clmulni_intel snd_seq_device snd_pcm joydev snd_timer mei_me snd lpc_ich i2c_i801 mei mfd_core soundcore video tpm_infineon tpm_tis shpchp soc_button_array tpm nfsd auth_rpcgss nfs_acl lockd grace sunrpc hid_logitech_hidpp hid_logitech_dj amdkfd amd_iommu_v2 radeon i2c_algo_bit drm_kms_helper ttm drm e1000e serio_raw ptp pps_core CPU: 0 PID: 13274 Comm: rsync Not tainted 4.1.3-201.fc22.x86_64 #1 Hardware name: Gigabyte Technology Co., Ltd. Z87-D3HP/Z87-D3HP-CF, BIOS F5 08/14/2013 0000000000000000 000000005e445430 ffff88011dde33f8 ffffffff8179b4bd 0000000000000000 0000000000000000 ffff88011dde3438 ffffffff810a163a ffff88011dde3448 ffffffff81d2ad00 ffff88001dd95af8 ffff8801c0454400 Call Trace: [<ffffffff8179b4bd>] dump_stack+0x45/0x57 [<ffffffff810a163a>] warn_slowpath_common+0x8a/0xc0 [<ffffffff810a176a>] warn_slowpath_null+0x1a/0x20 [<ffffffff81260b0e>] mark_buffer_dirty+0xbe/0xd0 [<ffffffff812d90d0>] ext4_commit_super+0x170/0x230 [<ffffffff812d9410>] __ext4_error+0x70/0x100 [<ffffffff81377511>] ? bio_put+0x51/0x90 [<ffffffff812b15e4>] ext4_wait_block_bitmap.part.10+0x94/0xc0 [<ffffffff812b1629>] ext4_wait_block_bitmap+0x19/0x20 [<ffffffff812f0814>] ext4_mb_init_cache+0x214/0x770 [<ffffffff811bcacc>] ? lru_cache_add+0x1c/0x50 [<ffffffff812f0e7e>] ext4_mb_init_group+0x10e/0x230 [<ffffffff812f112b>] ext4_mb_good_group+0x18b/0x1a0 [<ffffffff812f442d>] ext4_mb_regular_allocator+0x1bd/0x480 [<ffffffff812f6009>] ext4_mb_new_blocks+0x3d9/0x510 [<ffffffff812e5b46>] ? ext4_find_extent+0x1c6/0x330 [<ffffffff812ea6de>] ext4_ext_map_blocks+0x78e/0xe90 [<ffffffff811ad07c>] ? find_get_pages_tag+0xfc/0x200 [<ffffffff811b0607>] ? oom_kill_process+0x377/0x3c0 [<ffffffff812ba3ff>] ext4_map_blocks+0x18f/0x500 [<ffffffff812bd6b2>] ext4_writepages+0x5e2/0xd90 [<ffffffff812c2c75>] ? dx_release+0x45/0x50 [<ffffffff8126221f>] ? __getblk_gfp+0x2f/0x70 [<ffffffff811ba1ae>] do_writepages+0x1e/0x30 [<ffffffff811add25>] __filemap_fdatawrite_range+0x65/0x90 [<ffffffff811ade0c>] filemap_flush+0x1c/0x20 [<ffffffff812bb0bc>] ext4_alloc_da_blocks+0x2c/0x70 [<ffffffff812c8cfc>] ext4_rename+0x67c/0x8e0 [<ffffffff812c8f7d>] ext4_rename2+0x1d/0x40 [<ffffffff81239062>] vfs_rename+0x5a2/0x8c0 [<ffffffff8123d307>] SYSC_renameat2+0x5b7/0x620 [<ffffffff8122d5e5>] ? __sb_end_write+0x35/0x70 [<ffffffff8124b54f>] ? mnt_drop_write+0x1f/0x30 [<ffffffff81023a15>] ? do_audit_syscall_entry+0x55/0x80 [<ffffffff81024d1b>] ? syscall_trace_enter_phase1+0x14b/0x1b0 [<ffffffff81147366>] ? __audit_syscall_exit+0x1f6/0x290 [<ffffffff81234cb2>] ? path_put+0x22/0x30 [<ffffffff8123e59e>] SyS_rename+0x1e/0x20 [<ffffffff817a1a6e>] system_call_fastpath+0x12/0x71
Created attachment 1060260 [details] File: dmesg
The hard drive in question seems to be dying (bad sectors appeared), so this issue might be disregarded. The only question is whether kernel should crash like that in such situations. That I do not know.
*********** 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 22 kernel bugs. Fedora 22 has now been rebased to 4.2.3-200.fc22. Please test this kernel update (or newer) and let us know if you issue has been resolved or if it is still present with the newer kernel. If you have moved on to Fedora 23, and are still experiencing this issue, please change the version to Fedora 23. If you experience different issues, please open a new bug report for those.
Description of problem: trying to connect a USB wifi Version-Release number of selected component: kernel Additional info: reporter: libreport-2.6.3 cmdline: BOOT_IMAGE=/vmlinuz-4.2.6-200.fc22.x86_64 root=/dev/mapper/fedora-root ro rd.lvm.lv=fedora/swap rd.lvm.lv=fedora/root rhgb quiet LANG=en_US.UTF-8 kernel: 4.2.6-200.fc22.x86_64 runlevel: N 5 type: Kerneloops Truncated backtrace: WARNING: CPU: 1 PID: 1760 at fs/buffer.c:1160 mark_buffer_dirty+0xf3/0x100() Modules linked in: rfcomm fuse xt_CHECKSUM ipt_MASQUERADE nf_nat_masquerade_ipv4 tun nf_conntrack_netbios_ns nf_conntrack_broadcast 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 bnep arc4 uvcvideo iwldvm mac80211 videobuf2_vmalloc snd_hda_codec_hdmi iTCO_wdt iTCO_vendor_support videobuf2_core videobuf2_memops v4l2_common snd_hda_codec_realtek coretemp kvm videodev snd_hda_codec_generic ses snd_hda_intel btusb enclosure btrtl snd_hda_codec iwlwifi btbcm input_polldev media snd_hda_core btintel snd_hwdep snd_seq snd_seq_device snd_pcm bluetooth cfg80211 snd_timer i2c_i801 snd soundcore rfkill fujitsu_laptop lpc_ich tpm_infineon tpm_tis tpm shpchp acpi_cpufreq nfsd auth_rpcgss nfs_acl lockd grace sunrpc binfmt_misc i915 firewire_ohci 8021q i2c_algo_bit garp drm_kms_helper firewire_core stp llc sdhci_pci serio_raw mrp sdhci mmc_core drm yenta_socket crc_itu_t uas usb_storage sky2 video CPU: 1 PID: 1760 Comm: kworker/u4:1 Not tainted 4.2.6-200.fc22.x86_64 #1 Hardware name: FUJITSU LifeBook P8020/FJNB1F4, BIOS Version 1.12 03/16/2009 Workqueue: writeback wb_workfn (flush-8:16) 0000000000000000 00000000af6d36d1 ffff88013a45f448 ffffffff817729ea 0000000000000000 0000000000000000 ffff88013a45f488 ffffffff8109e4b6 ffff88013a45f468 ffffffff81d302c0 ffff880088c32f08 000000000001cb88 Call Trace: [<ffffffff817729ea>] dump_stack+0x45/0x57 [<ffffffff8109e4b6>] warn_slowpath_common+0x86/0xc0 [<ffffffff8109e5ea>] warn_slowpath_null+0x1a/0x20 [<ffffffff81252193>] mark_buffer_dirty+0xf3/0x100 [<ffffffff812c6b98>] ext4_commit_super+0x1a8/0x260 [<ffffffff812c6eb0>] __ext4_error+0x70/0x100 [<ffffffff810df9d0>] ? autoremove_wake_function+0x40/0x40 [<ffffffff8129fefd>] ext4_wait_block_bitmap.part.10+0x8d/0xb0 [<ffffffff8129ff39>] ext4_wait_block_bitmap+0x19/0x20 [<ffffffff812de093>] ext4_mb_init_cache+0x203/0x710 [<ffffffff811b344c>] ? lru_cache_add+0x1c/0x50 [<ffffffff812de6ac>] ext4_mb_init_group+0x10c/0x210 [<ffffffff812de90f>] ext4_mb_good_group+0x15f/0x170 [<ffffffff812e1933>] ext4_mb_regular_allocator+0x283/0x470 [<ffffffff812dc781>] ? ext4_mb_initialize_context+0x81/0x1b0 [<ffffffff812e3321>] ext4_mb_new_blocks+0x391/0x4c0 [<ffffffff812d35b9>] ? ext4_find_extent+0x1b9/0x320 [<ffffffff812d83bf>] ext4_ext_map_blocks+0x76f/0xe20 [<ffffffff811a30f6>] ? find_get_pages_tag+0xf6/0x1e0 [<ffffffff811b0165>] ? zone_dirty_ok+0x35/0x140 [<ffffffff812a872a>] ext4_map_blocks+0x18a/0x4a0 [<ffffffff812ab843>] ext4_writepages+0x593/0xce0 [<ffffffff811b0b1e>] do_writepages+0x1e/0x30 [<ffffffff8124a7c5>] __writeback_single_inode+0x45/0x290 [<ffffffff8124aef2>] writeback_sb_inodes+0x242/0x4e0 [<ffffffff8124b32e>] wb_writeback+0xde/0x290 [<ffffffff8124bb0b>] wb_workfn+0x12b/0x4c0 [<ffffffff810b650e>] process_one_work+0x19e/0x3f0 [<ffffffff810b67ae>] worker_thread+0x4e/0x450 [<ffffffff810b6760>] ? process_one_work+0x3f0/0x3f0 [<ffffffff810bc8b8>] kthread+0xd8/0xf0 [<ffffffff810bc7e0>] ? kthread_worker_fn+0x160/0x160 [<ffffffff817797df>] ret_from_fork+0x3f/0x70 [<ffffffff810bc7e0>] ? kthread_worker_fn+0x160/0x160