kdump regression compared to v2.6.35

Tejun Heo tj at kernel.org
Mon Aug 30 10:21:02 EDT 2010


Hello,

On 08/30/2010 04:02 PM, CAI Qian wrote:
>> Hmm, odd.  So, here's the said debug patch.  It will periodically
>> check all works and report if any work is being delayed for too long.
>> If the max wait goes over 30secs, it will dump all task states and
>> disable itself.  Can you please apply the patch on top of rc2 +
>> wq#for-linus and report the output?  It should tell us who's stuck
>> where.
>
> Nothing new was printed after around 10 minutes.

Eh... that's interesting.  That means no work is stalled on
workqueues, so it at least is not a workqueue stall.  Can you please
try the following then?  Or if sysrq wasn't working because your
keyboard wasn't initialized at that point, you can setup serial
console and trigger sysrq that way.

Thanks.

diff --git a/init/main.c b/init/main.c
index 94ab488..e156b8f 100644
--- a/init/main.c
+++ b/init/main.c
@@ -423,11 +423,19 @@ static void __init setup_command_line(char *command_line)

 static __initdata DECLARE_COMPLETION(kthreadd_done);

+static void show_state_timer_fn(unsigned long data)
+{
+	show_state();
+}
+static DEFINE_TIMER(show_state_timer, show_state_timer_fn, 0, 0);
+
 static noinline void __init_refok rest_init(void)
 	__releases(kernel_lock)
 {
 	int pid;

+	printk("XXX show_state_timer registered\n");
+	mod_timer(&show_state_timer, jiffies + 180 * HZ);
 	rcu_scheduler_starting();
 	/*
 	 * We need to spawn init first so that it obtains pid 1, however



More information about the kexec mailing list