> From: Paul E. McKenney <paul...@kernel.org> > Sent: Thursday, November 26, 2020 1:42 PM > > > > Another possibility is that rcu_state.gp_kthread is non-NULL, but that > > > something else is preventing RCU grace periods from completing, but in > > > > It looks like somehow the scheduling is not working here: in rcu_barrier() > > , if I replace the wait_for_completion() with > > wait_for_completion_timeout(&rcu_state.barrier_completion, 30*HZ), the > > issue persists. > > Have you tried using sysreq-t to see what the various tasks are doing?
Will try it. BTW, this is a "Generation 2" VM on Hyper-V, meaning sysrq only starts to work after the Hyper-V para-virtualized keyboard driver loads... So, at this early point, sysrq is not working. :-( I'll have to hack the code and use a virtual NMI interrupt to force the sysrq handler to be called. > Having interrupts disabled on all CPUs would have the effect of disabling > the RCU CPU stall warnings. > Thanx, Paul I'm sure the interrupts are not disabled. Here the VM only has 1 virtual CPU, and when the hang issue happens the virtual serial console is still responding when I press Enter (it prints a new line) or Ctrl+C (it prints ^C). Here the VM does not use the "legacy timers" (PIT, Local APIC timer, etc.) at all. Instead, the VM uses the Hyper-V para-virtualized timers. It looks the Hyper-V timer never fires in the kdump kernel when the hang issue happens. I'm looking into this... I suspect this hang issue may only be specific to Hyper-V. Thanks, -- Dexuan
