ThunderX Panic after r368370

[Michal Meloun]

On 07.12.2020 17:33, Marcel Flores wrote:
> 
>> On Dec 7, 2020, at 1:13 AM, Michal Meloun <meloun.michal at gmail.com> wrote:
>>
>> On 07.12.2020 9:21, Mark Millard wrote:
>>> On 2020-Dec-6, at 13:30, Mark Millard <marklmi at yahoo.com> wrote:
>>>> On 2020-Dec-6, at 03:51, Michal Meloun <meloun.michal at gmail.com> wrote:
>>>>
>>>> On 06.12.2020 10:47, Mark Millard wrote:
>>>>>> On 2020-Dec-6, at 00:17, Michal Meloun <meloun.michal at gmail.com> wrote:
>>>>>>> On 06.12.2020 3:21, Marcel Flores wrote:
>>>>>>>> Hi All,
>>>>>>>> Looks like the ThunderX started panicking at boot after r368370:
>>>>>>>> https://reviews.freebsd.org/rS368370
>>>>>>>>  From a verbose boot, it looks like it bails in gic0 redistributor setup(?):
>>>>>>>> gic0: CPU29 Re-Distributor woke up
>>>>>>>> gic0: CPU24 enabled CPU interface via system registers
>>>>>>>> gic0: CPU17 enabled CPU interface via system registers
>>>>>>>> gic0: CPU29 enabled CPU interface via system registers
>>>>>>>> done
>>> Looks to me like fdt_cpuid's use in cpu_init_fdt is one of the issues
>>> with what is added to each cpuset_domain[domain] :
>>> fdt_cpuid's initial value can not be added by this code: it is
>>> incremented first.
>>
>> Good catch. This ThunderX system is *FDT* based. And I spend half of night by digging in ACPI sources in attempt to understand who screw cpuset_domain :P
>>
>> Marcel, can you please try following patch? I hope that it fix this issue.
>>
>> https://github.com/strejda/freebsd/commit/1404960be6a7a6c75af86e86331acf951cfdf9b1
>>
> 
> That did the trick — no more panic.
> 
> Working debug-patch output just in case:
> 
> https://gist.github.com/mesflores/be330f23df2faa93a082825104b986a1
> 
> Appreciate the quick response!
> 

In meantime, Andrew made expanded version of this fix
https://reviews.freebsd.org/D27497

I sure that this will be committed ASAP.
Many thanks for cooperation and help. Sorry for troubles.
Michal