Re: Kernel v5.2+ on HiKey960?

[Jerome Forissier <jerome@forissier.org>]

On 12/4/19 11:18 AM, Marc Zyngier wrote:
> [switching email address]
> 
> Hi Jerome,
> 
> On 2019-12-04 09:01, Jerome Forissier wrote:
>> Hi Marc,
>>
>> On 12/3/19 6:47 PM, Marc Zyngier wrote:
>>> Hi Jerome,
>>>
>>> Adding Vincenzo (who was the last one to mess with the VDSO).
>>>
>>> On 2019-12-03 15:43, Jerome Forissier wrote:
>>>> Hi,
>>>>
>>>> Has anyone successfully run kernel v5.2 or later on a HiKey960 board?
>>>>
>>>> For some reason, anything past v5.1 doesn't work for me and I could not
>>>> figure out why. The symptom is it never gets to the login prompt. The
>>>> root FS is a Buildroot-generated one, and prior to reaching the kernel
>>>> the board runs TF-A, OP-TEE, UEFI (edk2) and Grub.
>>>>
>>>> I tried replacing /init with a shell, in which case I can type a
>>>> command
>>>> but whatever it is (even a simple "ls"), the command hangs on exit
>>>> and I
>>>> never get back to the prompt.
>>>>
>>>> Then I started bisecting, that was quite painful but I found several
>>>> problematic commits. I ended up reverting the following (in this order)
>>>> to be able to boot v5.4:
>>>>
>>>> 1. "arm64: vdso: Substitute gettimeofday() with C implementation"
>>>> 2. "arm64: vdso: Explicitly add build-id option"
>>>> 3. "arm64: arch_timer: Ensure counter register reads occur with seqlock
>>>>     held"
>>>> 4. "arm64: vdso: Remove stale files from old assembly implementation"
>>>>
>>>> So the main thing appears to be the VDSO stuff, but if I do not also
>>>> revert the arch_timer commit I get a kernel panic:
>>>>
>>>> [    4.657118] Run /init as init process
>>>> [    4.662380] Kernel panic - not syncing: Attempted to kill init!
>>>>                exitcode=0x00000004
>>>> [    4.670035] CPU: 7 PID: 1 Comm: init Not tainted 5.4.0-00003-
>>>>                g223b12c033fb #258
>>>> [    4.677338] Hardware name: HiKey960 (DT)
>>>> [    4.681253] Call trace:
>>>> [    4.683700]  dump_backtrace+0x0/0x148
>>>> [    4.687355]  show_stack+0x24/0x30
>>>> [    4.690664]  dump_stack+0xbc/0x100
>>>> [    4.694058]  panic+0x168/0x368
>>>> [    4.697105]  do_exit+0xa10/0xa28
>>>> [    4.700323]  do_group_exit+0x48/0xa8
>>>> [    4.703892]  get_signal+0xec/0x848
>>>> [    4.707287]  do_notify_resume+0x21c/0x480
>>>> [    4.711290]  work_pending+0x8/0x10
>>>> [    4.714689] SMP: stopping secondary CPUs
>>>> [    4.718607] Kernel Offset: disabled
>>>> [    4.722089] CPU features: 0x0002,21082004
>>>> [    4.726090] Memory Limit: none
>>>> [    4.729145] ---[ end Kernel panic - not syncing: Attempted to kill
>>>>                init! exitcode=0x00000004 ]---
>>>>
>>>> Any idea what could be wrong with my setup?
>>>
>>> Posting the relevant sections of your kernel messages would be a good
>>> start.
>>
>> Not sure what's relevant, so here are the full boot logs: v5.1 [1],
>> boots fine; v5.4 [2], hangs when launching /init (actually seems to be
>> stuck in some kind of active loop judging by the "THERMAL ALARM"
>> message); v5.4 + the above commits reverted [3], boots fine again
>> (please ignore the message "optee: PTA_CMD_GET_DEVICES invoke function
>> err: ffff0006" as well as the errors about /dev/tee*, they are unrelated
>> and are fixed in -next).
>>
>> [1] https://pastebin.com/pj8tb4Qr
>> [2] https://pastebin.com/sQTMQ8wu
>> [3] https://pastebin.com/58YycSF4
> 
> It is amusing that reverting the VDSO patches fixes anything, as your
> HW is affected by ARM erratum 858921, for which we should *disable* the
> VDSO altogether (the counter is not reliable and we have to workaround
> it in the kernel anyway, hence no fast gettimeofday for you).
> 
> I bet that the conversion to the generic VDSO has resulted in a loss
> of the VDSO disabling when only a secondary CPU is affected...
> 
> Can you please try the following hack for size? it is a terrible hack,
> but it should give us an indication of whether my hunch is correct
> or not. If this works, we'll look at the real solution. Otherwise, we'll
> keep digging.

Nope, doesn't help unfortunately :-/
Boot log for v5.4 + this patch: https://pastebin.com/9RmVSNWE

-- 
Jerome

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel