[Skiboot] (no subject)

[Alexey Kardashevskiy]

On 02/12/17 11:38, Nicholas Piggin wrote:
> 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/

No, this is won't help my POWER8/firestone bug.


-- 
Alexey