search for: schedule_timeout

...eventually see the copying stop, and any attempts to access /tmp fail - if I even do ls /tmp the command will hang. I suspect kjournald because of the following ps output: PID PPID WCHAN:20 PCPU %MEM PSR COMM 8847 99 start_this_handle 1.1 0.0 28 pdflush 8853 99 schedule_timeout 0.2 0.0 7 pdflush 188 1 kswapd 0.0 0.0 19 kswapd0 8051 1 mtd_blktrans_thread 0.0 0.0 22 mtdblockd 8243 1 kjournald 0.0 0.0 0 kjournald 8305 1 schedule_timeout 0.0 0.0 2 udevd 8378 1 kjournald...

Description: Use schedule_timeout_{,un}interruptible() instead of set_current_state()/schedule_timeout() to reduce kernel size. Also use helper functions to convert between human time units and jiffies rather than constant HZ division to avoid rounding errors. Signed-off-by: Nishanth Aravamudan <nacc@us.ibm.com> --- fs/ci...

...cciss_ioctl D 16579 ? 00:35:55 vbda lock_page R 17333 ? 00:00:00 ps - R 17356 ? 00:00:00 ps - XXX ALL PROCESSES ================= STAT PID TT TIME COMMAND WCHAN S 1 ? 00:00:04 init schedule_timeout SW 2 ? 00:00:00 keventd context_thread SW 3 ? 00:00:00 keventd context_thread SW 4 ? 00:00:00 keventd context_thread SW 5 ? 00:00:00 keventd context_thread SWN 6 ? 00:00:03 ksoftirqd_CPU0 ksoftirqd...

worker_loop() uses schedule_timeout() without setting state to STATE_(UN)INTERRUPTIBLE. As it is called in cycle without checking of pending signals, use schedule_timeout_uninterruptible(). Signed-off-by: Kulikov Vasiliy <segooon@gmail.com> --- fs/btrfs/async-thread.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-...

...000000000 Apr 1 21:22:58 sg1 kernel: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 Apr 1 21:22:58 sg1 kernel: ffff88063208dab8 ffff88011257bfd8 000000000000fbc8 ffff88063208dab8 Apr 1 21:22:58 sg1 kernel: Call Trace: Apr 1 21:22:58 sg1 kernel: [<ffffffff81528dd5>] schedule_timeout+0x215/0x2e0 Apr 1 21:22:58 sg1 kernel: [<ffffffff81330968>] ? extract_entropy+0x108/0x1f0 Apr 1 21:22:58 sg1 kernel: [<ffffffff81528a53>] wait_for_common+0x123/0x180 Apr 1 21:22:58 sg1 kernel: [<ffffffff81065df0>] ? default_wake_function+0x0/0x20 Apr 1 21:22:58 sg1 kernel: [...

Hi Chris, This is the extent of my current queue of Btrfs snapshot/subvol/commit stuff. Most of these were posted several months ago. Can be sent upstream during this merge window? Not having this functionality is becoming a bit of a roadblock for our efforts to keep the Ceph data in a consistent state. These patches are also available from

...el: [142441.721130] Call Trace: Apr 22 09:11:49 daisy kernel: [142441.721139]? [<ffffffff8114f130>] ? sync_page+0x0/0x50 Apr 22 09:11:49 daisy kernel: [142441.721144]? [<ffffffff8107c851>] ? update_curr+0xe1/0x1f0 Apr 22 09:11:49 daisy kernel: [142441.721149]? [<ffffffff81566c55>] schedule_timeout+0x215/0x2f0 Apr 22 09:11:49 daisy kernel: [142441.721155]? [<ffffffff81067432>] ? check_preempt_curr+0x82/0xa0 Apr 22 09:11:49 daisy kernel: [142441.721159]? [<ffffffff815669b4>] wait_for_completion+0xe4/0x120 Apr 22 09:11:49 daisy kernel: [142441.721162]? [<ffffffff81071ce0>] ? d...

We calculate timeout (either 1 or MAX_SCHEDULE_TIMEOUT) based on whether num_writers > 1 or should_grow at the top of the loop. Then, much much later, we wait for that timeout if either num_writers or should_grow is true. However, it''s possible for a racing process (calling btrfs_end_transaction()) to decrement num_writers such that we wa...

Hello, I just noticed an error in the current version of Klaus-Peter Junghanns bristuff package, especially in the HFC module. Everytime I try to unload the HFC module with "modprobe -r" I got a kernel panic and the complete server hangs up so I need to do a hard reset. Regards, Julian Pawlowski

...: > Apr 22 09:11:49 daisy kernel: [142441.721139]? [<ffffffff8114f130>] ? > sync_page+0x0/0x50 > Apr 22 09:11:49 daisy kernel: [142441.721144]? [<ffffffff8107c851>] ? > update_curr+0xe1/0x1f0 > Apr 22 09:11:49 daisy kernel: [142441.721149]? [<ffffffff81566c55>] > schedule_timeout+0x215/0x2f0 > Apr 22 09:11:49 daisy kernel: [142441.721155]? [<ffffffff81067432>] ? > check_preempt_curr+0x82/0xa0 > Apr 22 09:11:49 daisy kernel: [142441.721159]? [<ffffffff815669b4>] > wait_for_completion+0xe4/0x120 > Apr 22 09:11:49 daisy kernel: [142441.721162]? [<...

...49 daisy kernel: [142441.721139]? [<ffffffff8114f130>] ? >> sync_page+0x0/0x50 >> Apr 22 09:11:49 daisy kernel: [142441.721144]? [<ffffffff8107c851>] ? >> update_curr+0xe1/0x1f0 >> Apr 22 09:11:49 daisy kernel: [142441.721149]? [<ffffffff81566c55>] >> schedule_timeout+0x215/0x2f0 >> Apr 22 09:11:49 daisy kernel: [142441.721155]? [<ffffffff81067432>] ? >> check_preempt_curr+0x82/0xa0 >> Apr 22 09:11:49 daisy kernel: [142441.721159]? [<ffffffff815669b4>] >> wait_for_completion+0xe4/0x120 >> Apr 22 09:11:49 daisy kernel: [1...

Hi, everyone And we have the blocked cluster several times, and the log is always, we have to reboot all the node of the cluster to avoid it. Is there any patch that had fix this bug? [<ffffffff817539a5>] schedule_timeout+0x1e5/0x250 [<ffffffff81755a77>] wait_for_completion+0xa7/0x160 [<ffffffff8109c9b0>] ? try_to_wake_up+0x2c0/0x2c0 [<ffffffffa0564063>] __ocfs2_cluster_lock.isra.30+0x1f3/0x820 [ocfs2] As we test with a lot of node in one cluster, may be ten or twenty nodes, the cluster is always...

Hi, everyone And we have the blocked cluster several times, and the log is always, we have to reboot all the node of the cluster to avoid it. Is there any patch that had fix this bug? [<ffffffff817539a5>] schedule_timeout+0x1e5/0x250 [<ffffffff81755a77>] wait_for_completion+0xa7/0x160 [<ffffffff8109c9b0>] ? try_to_wake_up+0x2c0/0x2c0 [<ffffffffa0564063>] __ocfs2_cluster_lock.isra.30+0x1f3/0x820 [ocfs2] As we test with a lot of node in one cluster, may be ten or twenty nodes, the cluster is always...

...8013703ea40 ffff88013eb877f8 0000000000004000 00000000001d0a80 000000000000cb10 0000000000000000 ffffffffa0240af0 ffff88013703ea40 ffff88007ffee340 Call Trace: [<ffffffffa022bdbf>] ? dlm_put_lockspace+0x18/0x2b [dlm] [<ffffffff804f13e4>] schedule+0x9/0x1d [<ffffffff804f171d>] schedule_timeout+0x24/0x15e [<ffffffff804f1559>] ? wait_for_common+0x3c/0x123 [<ffffffff804f15ec>] wait_for_common+0xcf/0x123 [<ffffffff8023616f>] ? default_wake_function+0x0/0xf [<ffffffff804f16ca>] wait_for_completion+0x18/0x1a [<ffffffffa02d3755>] ocfs2_cluster_lock+0x91f/0x93e...

...2441.721139]? [<ffffffff8114f130>] ? >>> sync_page+0x0/0x50 >>> Apr 22 09:11:49 daisy kernel: [142441.721144]? [<ffffffff8107c851>] ? >>> update_curr+0xe1/0x1f0 >>> Apr 22 09:11:49 daisy kernel: [142441.721149]? [<ffffffff81566c55>] >>> schedule_timeout+0x215/0x2f0 >>> Apr 22 09:11:49 daisy kernel: [142441.721155]? [<ffffffff81067432>] ? >>> check_preempt_curr+0x82/0xa0 >>> Apr 22 09:11:49 daisy kernel: [142441.721159]? [<ffffffff815669b4>] >>> wait_for_completion+0xe4/0x120 >>> Apr 22 09:11...

...Call Trace: Feb 27 09:50:59 Server21 kernel: [ 1199.751303] [<ffffffffa04c056b>] ? dlm_kick_thread+0x7b/0x90 [ocfs2_dlm] Feb 27 09:50:59 Server21 kernel: [ 1199.751311] [<ffffffff8165a55f>] schedule+0x3f/0x60 Feb 27 09:50:59 Server21 kernel: [ 1199.751315] [<ffffffff8165aba5>] schedule_timeout+0x2a5/0x320 Feb 27 09:50:59 Server21 kernel: [ 1199.751319] [<ffffffff8165a39f>] wait_for_common+0xdf/0x180 Feb 27 09:50:59 Server21 kernel: [ 1199.751327] [<ffffffff8105f990>] ? try_to_wake_up+0x200/0x200 Feb 27 09:50:59 Server21 kernel: [ 1199.751331] [<ffffffff8165a51d>] wai...

...Call Trace: Feb 27 09:50:59 Server21 kernel: [ 1199.751303] [<ffffffffa04c056b>] ? dlm_kick_thread+0x7b/0x90 [ocfs2_dlm] Feb 27 09:50:59 Server21 kernel: [ 1199.751311] [<ffffffff8165a55f>] schedule+0x3f/0x60 Feb 27 09:50:59 Server21 kernel: [ 1199.751315] [<ffffffff8165aba5>] schedule_timeout+0x2a5/0x320 Feb 27 09:50:59 Server21 kernel: [ 1199.751319] [<ffffffff8165a39f>] wait_for_common+0xdf/0x180 Feb 27 09:50:59 Server21 kernel: [ 1199.751327] [<ffffffff8105f990>] ? try_to_wake_up+0x200/0x200 Feb 27 09:50:59 Server21 kernel: [ 1199.751331] [<ffffffff8165a51d>] wai...

...616291] [<ffffffffa02ab0a7>] ? o2dlm_blocking_ast_wrapper+0x0/0x17 [ocfs2_stack_o2cb] Apr 29 11:01:18 node06 kernel: [2569440.616317] [<ffffffffa02ab090>] ? o2dlm_lock_ast_wrapper+0x0/0x17 [ocfs2_stack_o2cb] Apr 29 11:01:18 node06 kernel: [2569440.616345] [<ffffffff812ee253>] ? schedule_timeout+0x2e/0xdd Apr 29 11:01:18 node06 kernel: [2569440.616362] [<ffffffff8118d99a>] ? vsnprintf+0x40a/0x449 Apr 29 11:01:18 node06 kernel: [2569440.616378] [<ffffffff812ee118>] ? wait_for_common+0xde/0x14f Apr 29 11:01:18 node06 kernel: [2569440.616396] [<ffffffff8104a188>] ? defaul...

...[ 240.231784] ffff8800ca2e3fd8 00000000001d5f00 ffff880128bf0000 ffff8800c82a3480 [ 240.232344] ffffffff82c30990 7fffffffffffffff ffffffff81ee2698 ffffffff81ee2690 [ 240.232931] Call Trace: [ 240.233467] [<ffffffff8185baf9>] schedule+0x29/0x70 [ 240.234025] [<ffffffff81860d1c>] schedule_timeout+0x26c/0x410 [ 240.234562] [<ffffffff81028c4a>] ? native_sched_clock+0x2a/0xa0 [ 240.235118] [<ffffffff811078bc>] ? mark_held_locks+0x7c/0xb0 [ 240.235645] [<ffffffff81861da0>] ? _raw_spin_unlock_irq+0x30/0x50 [ 240.236198] [<ffffffff81107a4d>] ? trace_hardirqs_on_cal...

...different kernels: VM: - 2.6.38.3 xenlinux based on SUSE package - vanilla 3.0.3 - vanilla 3.1 rc2 dom0: - 2.6.38.3 xenlinux based on SUSE package - vanilla 3.1 rc2 Result always the same: sometimes VM hang at startup, SysRq-T shows modprobe waiting in "wait_for_devices" (concretely schedule_timeout) and jiffies counter not increasing between task-states dumps. The only found thing (probably) connected with this problem are domU kernel messages: CE: xen increased min_delta_ns to 150000 nsec (...) CE: xen increased min_delta_ns to 4000000 nsec CE: Reprogramming failure. Giving up This message...