Regression: kexec/kdump boot hangs with x86/vector commits

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, Dec 13, 2017 at 10:52:56AM +0800, Dave Young wrote:
> Hi,
> 
> Kexec reboot and kdump has broken on my laptop for long time with
> 4.15.0-rc1+ kernels. With the patch below an early panic been fixed:
> https://patchwork.kernel.org/patch/10084289/
> 
> But still can not get a successful reboot, it looked like graphic
> issue, but after bisecting the kernel, I got below:
> 
> [dyoung at dhcp-*-* linux]$ git bisect good
> There are only 'skip'ped commits left to test.
> The first bad commit could be any of:
> 2db1f959d9dc16035f2eb44ed5fdb2789b754d6a
> 4900be83602b6be07366d3e69f756c1959f4169a
> We cannot bisect more!
> 
> These two commits can no be reverted because of code conflicts, thus
> I reverted the whole series from Thomas (below commits), with those
> x86/vector changes reverted, kexec reboot works fine.
> 
> Could you help to take a look, any thoughts?  I can do the test
> if you have some debug patch to try.
Is it possible that the "second" kernel runs on non-zero CPU? If yes,
what if some irqs are only delivered to cpu0? (use cpumask_of(0)
directly)

Thanks,
	Yu




[Index of Archives]     [LM Sensors]     [Linux Sound]     [ALSA Users]     [ALSA Devel]     [Linux Audio Users]     [Linux Media]     [Kernel]     [Gimp]     [Yosemite News]     [Linux Media]

  Powered by Linux