Re: Kernel v5.2+ on HiKey960?

[Marc Zyngier <maz@kernel.org>]

[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.

Thanks,

         M.

diff --git a/drivers/clocksource/arm_arch_timer.c 
b/drivers/clocksource/arm_arch_timer.c
index 9a5464c625b4..dc63bb7e09bc 100644
--- a/drivers/clocksource/arm_arch_timer.c
+++ b/drivers/clocksource/arm_arch_timer.c
@@ -24,6 +24,7 @@
  #include <linux/sched/clock.h>
  #include <linux/sched_clock.h>
  #include <linux/acpi.h>
+#include <linux/timekeeper_internal.h>

  #include <asm/arch_timer.h>
  #include <asm/virt.h>
@@ -562,6 +563,7 @@ void arch_timer_enable_workaround(const struct 
arch_timer_erratum_workaround *wa
  	if (wa->read_cntvct_el0) {
  		clocksource_counter.archdata.vdso_direct = false;
  		vdso_default = false;
+		update_vsyscall_status(1);
  	}
  }

diff --git a/include/linux/timekeeper_internal.h 
b/include/linux/timekeeper_internal.h
index 84ff2844df2a..435c42f3567d 100644
--- a/include/linux/timekeeper_internal.h
+++ b/include/linux/timekeeper_internal.h
@@ -142,6 +142,7 @@ struct timekeeper {

  extern void update_vsyscall(struct timekeeper *tk);
  extern void update_vsyscall_tz(void);
+extern void update_vsyscall_status(u32 val);

  #else

@@ -151,6 +152,9 @@ static inline void update_vsyscall(struct 
timekeeper *tk)
  static inline void update_vsyscall_tz(void)
  {
  }
+static inline void update_vsyscall_status(u32)
+{
+}
  #endif

  #endif /* _LINUX_TIMEKEEPER_INTERNAL_H */
diff --git a/kernel/time/vsyscall.c b/kernel/time/vsyscall.c
index 5ee0f7709410..f5c048a65b72 100644
--- a/kernel/time/vsyscall.c
+++ b/kernel/time/vsyscall.c
@@ -128,3 +128,15 @@ void update_vsyscall_tz(void)

  	__arch_sync_vdso_data(vdata);
  }
+
+void update_vsyscall_status(u32 val)
+{
+	struct vdso_data *vdata = __arch_get_k_vdso_data();
+
+	vdso_write_begin(vdata);
+
+	vdata[CS_HRES_COARSE].clock_mode	= val;
+	vdata[CS_RAW].clock_mode		= val;
+
+	vdso_write_end(vdata);
+}

-- 
Jazz is not dead. It just smells funny...

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