ppc32 panic on boot on linux-next

ppc32 panic on boot on linux-next

[Nick Desaulniers]

As a heads up, our CI went red last night, seems like a panic from
free_initmem?  Is this a known issue?

https://travis-ci.com/ClangBuiltLinux/continuous-integration/jobs/295304058?utm_medium=notification&utm_source=email

-- 
Thanks,
~Nick Desaulniers

Re: ppc32 panic on boot on linux-next

[Christophe Leroy]

Le 06/03/2020 à 20:05, Nick Desaulniers a écrit :
> As a heads up, our CI went red last night, seems like a panic from
> free_initmem?  Is this a known issue?

Thanks for the heads up.

No such issue with either 8xx or book3s/32.

I've now been able to reproduce it with bamboo QEMU.

Reverting 2efc7c085f05 makes it disappear. I'll investigate.

Christophe

Re: ppc32 panic on boot on linux-next

[Christophe Leroy]

Le 07/03/2020 à 09:42, Christophe Leroy a écrit :
> 
> 
> Le 06/03/2020 à 20:05, Nick Desaulniers a écrit :
>> As a heads up, our CI went red last night, seems like a panic from
>> free_initmem?  Is this a known issue?
> 
> Thanks for the heads up.
> 
> No such issue with either 8xx or book3s/32.
> 
> I've now been able to reproduce it with bamboo QEMU.
> 
> Reverting 2efc7c085f05 makes it disappear. I'll investigate.
> 

Ok, I found the problem. virt_to_kpte() lacks a NULL pmd check. I'll 
send a patch for that.

However, if there is no PMD I guess this area is mapped through some 
kind of block mapping. Therefore it should bail out of the function through:

	if (v_block_mapped(address))
		return 0;


Can someone who knows BOOKE investigate that ?

Christophe

Re: ppc32 panic on boot on linux-next

[Michael Ellerman]

Christophe Leroy <christophe.leroy@c-s.fr> writes:
> Le 07/03/2020 à 09:42, Christophe Leroy a écrit :
>> Le 06/03/2020 à 20:05, Nick Desaulniers a écrit :
>>> As a heads up, our CI went red last night, seems like a panic from
>>> free_initmem?  Is this a known issue?
>> 
>> Thanks for the heads up.
>> 
>> No such issue with either 8xx or book3s/32.
>> 
>> I've now been able to reproduce it with bamboo QEMU.
>> 
>> Reverting 2efc7c085f05 makes it disappear. I'll investigate.
>> 
>
> Ok, I found the problem. virt_to_kpte() lacks a NULL pmd check. I'll 
> send a patch for that.
>
> However, if there is no PMD I guess this area is mapped through some 
> kind of block mapping. Therefore it should bail out of the function through:
>
> 	if (v_block_mapped(address))
> 		return 0;
>
>
> Can someone who knows BOOKE investigate that ?

Not sure we have anyone left?

cheers

Re: ppc32 panic on boot on linux-next

[Laurentiu Tudor]

Hello,

On 10.03.2020 06:44, Michael Ellerman wrote:
> Christophe Leroy <christophe.leroy@c-s.fr> writes:
>> Le 07/03/2020 à 09:42, Christophe Leroy a écrit :
>>> Le 06/03/2020 à 20:05, Nick Desaulniers a écrit :
>>>> As a heads up, our CI went red last night, seems like a panic from
>>>> free_initmem?  Is this a known issue?
>>>
>>> Thanks for the heads up.
>>>
>>> No such issue with either 8xx or book3s/32.
>>>
>>> I've now been able to reproduce it with bamboo QEMU.
>>>
>>> Reverting 2efc7c085f05 makes it disappear. I'll investigate.
>>>
>>
>> Ok, I found the problem. virt_to_kpte() lacks a NULL pmd check. I'll
>> send a patch for that.
>>
>> However, if there is no PMD I guess this area is mapped through some
>> kind of block mapping. Therefore it should bail out of the function through:
>>
>> 	if (v_block_mapped(address))
>> 		return 0;
>>
>>
>> Can someone who knows BOOKE investigate that ?
> 
> Not sure we have anyone left?
> 
> cheers
> 

With latest linux-next, PPC32 Book-E boots to prompt:

https://paste.debian.net/1134272/

---
Best Regards, Laurentiu