On Wed, 29 Nov 2017 15:06:52 +1100 David Gibson <da...@gibson.dropbear.id.au> wrote:
> a3b2cb30 "powerpc: Do not call ppc_md.panic in fadump panic notifier" > purports to fix a problem when the kernel panics with fadump not > registered, but it breaks something else instead. I _think_ it was > working on the incorrect assumption that ppc_md.panic was (or should > be) only used with fadump, but I'm not really sure. > > Panic works with kdump enabled, and (I think) with fadump enabled). > However, with neither of these enabled, we always go to the generic > panic logic. Yeah thanks, I can't remember what assumption I was working on tbh. > That's incorrect for PAPR guests - they should call ibm,os-term via > RTAS. Under qemu this leads to a "GUEST_PANICKED" event notification > which higher-level management pays attention to. Since a3b2cb30 we > now reboot instead of reporting that. > > I believe it will also break panic for PS3 machines, but since that > platform basically no longer exists, we probably don't care. I (hope) it should just go down to the normal panic path and not do much worse than it already does -- although it won't print out that message. > I'm not entirely sure how to fix this. I _think_ what we want is to > call ppc_md.panic from a late panic notifier, the way this patch does > for fadump_panic_event() if fadump is registered. The problem I had there is that some of the printk and console stuff wasn't getting flushed out, so I was getting a blank screen. This was probably in conjunction with panicing from NMI context that we're now starting to introduce. So it's a bit annoying. There's other ugliness we have for being unable to control panic code well enough from arch code (arch/powerpc/platforms/powernv/opal.c) I guess a really minimal fix is to put an #ifdef powerpc down the bottom there (/me *cries*).