[Skiboot] (no subject)

[Nicholas Piggin]

On Sat, 2 Dec 2017 11:20:20 +1100
Alexey Kardashevskiy <aik at ozlabs.ru> wrote:

> On 02/12/17 11:13, Nicholas Piggin wrote:
> > On Fri, 01 Dec 2017 14:51:56 -0600
> > Benjamin Herrenschmidt <benh at kernel.crashing.org> wrote:
> >   
> >> On Fri, 2017-12-01 at 01:52 +1000, Nicholas Piggin wrote:  
> >>> Firstly, Linux should set up MMU registers like PIDR properly in
> >>> its per-CPU mmu initialisation at boot, patch for that should not
> >>> be controversial.    
> >>
> >> So I was wondering how we got things into the PWC since we are 
> >> in real mode when we do the flush, but the above explains it.
> >>
> >> We come up with a stale PIDR and turn the MMU on. We only
> >> execute/load/store from Q3 but prefetch/speculation can hit Q0 and thus
> >> get crap into the PWC.
> >>
> >> So I think setting PIDR to 0 is the main fix. Cleaning up the rest also
> >> makes sense of course.
> >>
> >> Or am I missing something else still ?  
> > 
> > Yes that's what happens. After realizing this, the bug no longer requires
> > translations to be cached in real mode (does the architecture guarantee
> > that?)
> > 
> > I think LPID is safer to be zeroed as well because in theory we might
> > get speculative access into quadrant 0/1.  
> 
> 
> Is there something quick to try?
> 
> I am having a problem with kdump not working while kexec still works just
> fine with the exact same kernel, and with kdump triggered by "echo c >
> /proc/sysrq-trigger", the new kernel crashes silently somewhere here:
> 
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/powerpc/kernel/setup_64.c#n305

I'm not sure. You're running with the MMU off at this point so I don't think
my patches will help.

I sent a Linux patch to fix the same bug, if that's easier to try.

https://patchwork.ozlabs.org/patch/843319/

Thanks,
Nick