Additional info: reporter: libreport-2.3.0 WARNING: CPU: 3 PID: 2451 at kernel/sched/core.c:7300 __might_sleep+0xbd/0xd0() do not call blocking ops when !TASK_RUNNING; state=2 set at [<ffffffff81871a85>] wait_for_completion_io+0xf5/0x150 Modules linked in: bnep bluetooth rfkill xt_CHECKSUM tun nf_log_ipv6 nf_log_ipv4 nf_log_common xt_LOG nf_conntrack_netbios_ns nf_conntrack_broadcast ipt_MASQUERADE nf_nat_masquerade_ipv4 ip6t_rpfilter ip6t_REJECT nf_reject_ipv6 xt_conntrack ebtable_nat ebtable_broute bridge stp llc 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 xpad ppdev uvcvideo videobuf2_vmalloc videobuf2_core joydev videobuf2_memops snd_usb_audio v4l2_common snd_usbmidi_lib videodev snd_rawmidi media kvm_amd kvm raid1 fuse serio_raw k10temp edac_core edac_mce_amd snd_hda_codec_hdmi snd_hda_codec_realtek snd_hda_codec_generic sp5100_tco snd_hda_intel i2c_piix4 snd_hda_controller snd_hda_codec snd_hwdep snd_seq snd_seq_device snd_pcm snd_timer snd parport_pc soundcore parport tpm_infineon tpm_tis tpm shpchp wmi acpi_cpufreq nfsd auth_rpcgss nfs_acl lockd grace binfmt_misc sunrpc ata_generic pata_acpi radeon pata_atiixp i2c_algo_bit drm_kms_helper ttm drm r8169 mii CPU: 3 PID: 2451 Comm: xfce4-taskmanag Not tainted 3.19.0-0.rc6.git3.1.fc22.x86_64 #1 Hardware name: MICRO-STAR INTERNATIONAL CO.,LTD MS-7596/760GM -E51 (MS-7596), BIOS V1.8 09/03/2010 0000000000000000 00000000ab60e38c ffff8800ba8c3608 ffffffff8186dcb7 0000000000000000 ffff8800ba8c3660 ffff8800ba8c3648 ffffffff810aca3a ffff8800ba8c36f8 ffffffff81ce4a5a 00000000000002e9 0000000000000000 Call Trace: [<ffffffff8186dcb7>] dump_stack+0x4c/0x65 [<ffffffff810aca3a>] warn_slowpath_common+0x8a/0xc0 [<ffffffff810acac5>] warn_slowpath_fmt+0x55/0x70 [<ffffffff81028c3a>] ? native_sched_clock+0x2a/0xa0 [<ffffffff81871a85>] ? wait_for_completion_io+0xf5/0x150 [<ffffffff81871a85>] ? wait_for_completion_io+0xf5/0x150 [<ffffffff810dd85d>] __might_sleep+0xbd/0xd0 [<ffffffff816a0d55>] md_super_wait+0x35/0xc0 [<ffffffff816a8673>] bitmap_unplug+0x1c3/0x1d0 [<ffffffff81028c3a>] ? native_sched_clock+0x2a/0xa0 [<ffffffffa049a540>] raid1_unplug+0xe0/0x160 [raid1] [<ffffffff813edf5a>] blk_flush_plug_list+0x9a/0x260 [<ffffffff818712e7>] io_schedule_timeout+0x87/0x110 [<ffffffff81877070>] ? _raw_spin_unlock_irq+0x30/0x50 [<ffffffff81871aa7>] wait_for_completion_io+0x117/0x150 [<ffffffff810e6c60>] ? wake_up_state+0x20/0x20 [<ffffffff813f5dc7>] __blkdev_issue_zeroout+0x227/0x270 [<ffffffff818719dc>] ? wait_for_completion_io+0x4c/0x150 [<ffffffff813f5ef9>] blkdev_issue_zeroout+0xe9/0xf0 [<ffffffff81106f3e>] ? __lock_is_held+0x5e/0x90 [<ffffffff81340e7c>] ext4_ext_zeroout.isra.33+0x4c/0x60 [<ffffffff81346f57>] ext4_ext_handle_unwritten_extents+0x6a7/0x10c0 [<ffffffff81106f3e>] ? __lock_is_held+0x5e/0x90 [<ffffffff813482be>] ext4_ext_map_blocks+0x91e/0x13b0 [<ffffffff81315293>] ? ext4_map_blocks+0x123/0x580 [<ffffffff81315293>] ? ext4_map_blocks+0x123/0x580 [<ffffffff813152b6>] ext4_map_blocks+0x146/0x580 [<ffffffff81318f60>] ext4_writepages+0x810/0x13b0 [<ffffffff81028c3a>] ? native_sched_clock+0x2a/0xa0 [<ffffffff81028c3a>] ? native_sched_clock+0x2a/0xa0 [<ffffffff811f35a1>] do_writepages+0x21/0x40 [<ffffffff811e507d>] __filemap_fdatawrite_range+0x5d/0x80 [<ffffffff811e519d>] filemap_write_and_wait_range+0x2d/0x70 [<ffffffff8130e413>] ext4_sync_file+0x173/0x650 [<ffffffff812afc21>] do_fsync+0x51/0x80 [<ffffffff812aff10>] SyS_fsync+0x10/0x20 [<ffffffff81877ca9>] system_call_fastpath+0x12/0x17
Created attachment 986849 [details] File: dmesg
I don't think that this is a file system problem. The problem is somewhere further down, amongst the scheduler, blk, and md: 1) wait_for_common_io() calls __wait_for_commom() with io_schedule_timeout() as its action 2) __wait_for_common()->do_wait_for_common() sets the current state and calls the action function. 3) io_schedule_timeout() calls blk_flush_plug(). 4) raid1_unplug() isn't called with from_schedule, so it calls bitmap_unplug() which waits. Dunno how the layers want to get out of this mess, but it might be easy to have io_schedule_timeout() call blk_schedule_flush_plug() so that unplug functions know to defer and schedule io instead of waiting themselves. I poked around a bit and didn't see upstream discussion of this stack in particular, but I might have missed something.
*********** 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 21 kernel bugs. Fedora 21 has now been rebased to 3.19.5-200.fc21. 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 22, and are still experiencing this issue, please change the version to Fedora 22. If you experience different issues, please open a new bug report for those.
https://bugzilla.kernel.org/show_bug.cgi?id=98191 https://bugzilla.redhat.com/show_bug.cgi?id=1220519
This message is a reminder that Fedora 21 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 21. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '21'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 21 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 21 changed to end-of-life (EOL) status on 2015-12-01. Fedora 21 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.