On Wed, Dec 05, 2018 at 05:00:44PM +0900, Sergey Senozhatsky wrote: > On (12/05/18 14:29), Sergey Senozhatsky wrote: > > On (12/05/18 11:57), Sergey Senozhatsky wrote: > > > On (12/05/18 10:47), Feng Tang wrote: > > > > OK... So, apparently, what's happening is panic() calls smp_send_stop(). > > And smp_send_stop()->native_stop_other_cpus() on x86 disables local APIC. > > So no fun anymore. > > > > If I keep APIC enabled on panic CPU, then I have my keyboard working, > > including PageUp-PageDown scrolling, sysrq handling, and so on. > > Meeh, it's much harder than this. Worked on one machine only. Same here, I tried on several platforms and hardly get the sysrq magic key working, though it works while system is running. And it make me wondering if those workqueue dependent led blinking code can still really work. > > > PeterZ, > > for those folks who sometimes have to use framebuffer for debugging > > (just a trivial "let me scrollback and see the panic backtrace") and > > not always have access to serial console, can we have local APIC > > enabled on the panic_cpu? Or is it a terrible thing to ask for? > > The question remains: can we have input irqs on panic_cpu after panic? With current kernel, the irq is still enabled for the panic CPU, I did see timer and some device's ISR get called, but they will only fire IRQ one time after panic triggered. Thanks, Feng
