Don Zickus <dzickus at redhat.com> writes: > On Tue, Jan 31, 2012 at 02:08:29PM -0800, Eric W. Biederman wrote: >> > The problem is that although kdump tries to shutdown minimal hardware, >> > it still needs to disable the IO APIC. This requires spinlocks which >> > may be held by another cpu. This other cpu is being held infinitely in >> > an NMI context by kdump in order to serialize the crashing path. Instant >> > deadlock. >> >> Can you test to see if kexec on panic still needs to disable the IO >> APIC. Last I looked we were close if not all of the way there to not >> needing to boot the kernel in pic mode? > > Ok, so you just blindly remove disable_IO_APIC from > native_machine_crash_shutdown and re-run some panic tests on various > machines? What about the disable_IO_APIC path in native_machine_shutdown? > Yes. Just native_machine_crash_shutdown. native_machine_shutdown is the case when all is good and we attempt to put the hardware back the way we found it. Any normal x86 machine that the kernel runs in ioapic mode should be enough to get a first approximation. > Also, where could I look to see if that work was done? Is that in the > ioapic setup code? The primary question is do we call the ioapic setup code without calling the pic setup code first. On some embedded x86 platforms we certainly do. I don't know if that code has been generalized. Historically the problem is that we started the pit timer in pic mode and used that to calibrate the delay loop. So what we are looking to verify is that the linux kernel boot skip pic mode entirely. Eric
