Re: Kernel v5.2+ on HiKey960?

From: Jerome Forissier <jerome@forissier.org>
To: Will Deacon <will@kernel.org>
Cc: Catalin Marinas <catalin.marinas@arm.com>,
	Vincenzo Frascino <vincenzo.frascino@arm.com>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>,
	maz@kernel.org
Subject: Re: Kernel v5.2+ on HiKey960?
Date: Thu, 5 Dec 2019 15:54:10 +0100	[thread overview]
Message-ID: <e3ac6a90-c6e7-460e-087a-880e3735051e@forissier.org> (raw)
In-Reply-To: <20191205085709.GB8606@willie-the-truck>

On 12/5/19 9:57 AM, Will Deacon wrote:
> On Thu, Dec 05, 2019 at 08:26:48AM +0100, Jerome Forissier wrote:
>> On 12/4/19 6:57 PM, Will Deacon wrote:
>>> On Wed, Dec 04, 2019 at 03:58:57PM +0100, Jerome Forissier wrote:
>>>> On 12/4/19 3:28 PM, Catalin Marinas wrote:
>>>>> On Wed, Dec 04, 2019 at 02:15:48PM +0100, Jerome Forissier wrote:
>>>>>> On 12/4/19 11:18 AM, Catalin Marinas wrote:
>>>>>>> On Tue, Dec 03, 2019 at 04:43:22PM +0100, Jerome Forissier wrote:
>>>>>>>> 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:
>>>>> [...]
>>>>>> 75a19a0202db is the first bad commit. Its parent: commit 2f1d4e24d91b
>>>>>> ("firmware: arm_sdei: Prohibit probing in '_sdei_handler'") boots fine
>>>>>> [2]. Since reverting 75a19a0202db in v5.2 does not work, I suspect we're
>>>>>> dealing with multiple problems. As I said, the set of reverts above is
>>>>>> the best I could figure out, and believe me I spent several days trying
>>>>>> to troubleshoot this :-/ (that being said, I know nothing about the VDSO
>>>>>> or the arch timer so I could not try anything meaningful other than
>>>>>> reverting some commits).
>>>>>
>>>>> Thanks. There could as well be multiple issues. Since commit
>>>>> 75a19a0202db is cc stable, could you please apply it on top of 5.1 and
>>>>> see if it fails? I don't have a HiKey960 at hand to try this.
>>>>>
>>>>
>>>> Fails indeed (panic): https://pastebin.com/F0jpktii
>>>
>>> Interesting. I followed your instructions and my board boots fine even
>>> after applying that patch, but then I see the following on shutdown:
>>>
>>> [   83.022955] WARNING: CPU: 0 PID: 1995 at kernel/time/tick-broadcast.c:647 tick_handle_oneshot_broadcast+0x1c8/0x1e8
>>> [   83.033392] Modules linked in:
>>> [   83.036447] CPU: 0 PID: 1995 Comm: init Tainted: G S                5.1.0-253105-g2b41f6584d59 #3
>>
>> That is not v5.1 plus one commit, is it?
> 
> No, and I wasn't claiming that it was. 

;-) My apologies, I was confused.

> I followed the instructions you pointed us to [1] and cherry-picked 75a19a0202db> on top. If there's something different that I need to do in order to
reproduce> the problem, then please holler.
> My experience with Hikey960 has been 100% "bloody awful"
> so I don't have a good setup for simply building and running a kernel on it.
> 
> I also had to hack some of the EDK2 code in there to get it to compile, so
> it continues to live up to expectations.

What error did you encounter? Is it this one by chance?

 error: ‘__builtin_strncpy’ output truncated [...]

I just noticed GCC 9.x shows this, while GCC 8.x doesn't. So it depends
on what distribution you are using. I will need to do something to
address this problem.

Thanks,
-- 
Jerome

> 
> My hunch is that we're somehow ending up in the vDSO code but with the A73
> workaround for erratum 858921 enabled. This shouldn't ever happen because
> the syscall fallback will be enabled in this case, so I'm also thinking that
> the SP804 clocksource is confusing things somehow. If we end up trapping to
> the kernel with the seqlock held then I could see userspace getting stuck in
> an infinite loop. Since I've been unable to reproduce the failure, could you
> see if it persists even with CONFIG_ARM64_ERRATUM_858921=n?
> 
> Will
> 
> [1] https://optee.readthedocs.io/en/latest/building/gits/build.html#get-and-build-the-solution
> 

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