[Xenomai] xenomai on ARM64 question
jro at xenomai.org
Sat Dec 16 19:28:38 CET 2017
On 12/16/2017 02:31 PM, Peng Fan wrote:
> On Fri, Dec 15, 2017 at 05:53:43PM +0800, Peng Fan wrote:
>> Hi Philippe,
>> On Thu, Dec 14, 2017 at 05:39:10PM +0100, Philippe Gerum wrote:
>>> On 12/14/2017 11:23 AM, Peng Fan wrote:
>>>> I am trying xenomai on ARM64 with GICV3, but met the following error.
>>>> I have no good idea on this. I disabled KVM/CPUFREQ/CPUIDLE, enabled DEBUG.
>>>> I use ipipe-core-4.9.51-arm64-3.patch with these patches applied from 4.9.y branch
>>>> ipipe: printk: fix unprotected check for deferrable output
>>>> ipipe: drop obsolete ipipe_probe_kernel*() calls
>>>> lib/ipipe: make dump_stack() domain-aware
>>>> ipipe: gicv3: [v3] Enable interrupt pipelining.
>>>> ipipe: add back migration notifiers
>>>> Do you know what this issue maybe related about?
>>>> [ 20.236548] dhd_module_init out
>>>> [ 20.239689] ALSA device list:
>>>> [ 20.242750] #0: amix-audio-sai
>>>> [ 20.246170] Unable to handle kernel NULL pointer dereference at virtual addr0
>>>> [ 20.254331] mm_pgd = ffff000009469000, hw_pgd = ffff8000015a4000
>>>> [ 20.260341]  *pgd=00000008bfffe003, *pud=00000008bfffd003, *pmd=000
>>>> [ 20.268640] Internal error: Oops: 86000004 [#1] PREEMPT SMP
>>> Some irqchip driver enabled in your kernel is not aware of interrupt
>>> pipelining, i.e. not handled by the I-pipe patch. The
>>> ->irq_hold/release() handlers for this interrupt controller are likely
>> Thanks. It is a dummy irqchip driver used for wakeup causes this issue.
>> I still have a question on my platform. with "maxcpus=1", kernel could runs
>> into login shell. But if using default 4 CPUs, kernel stops at:
>> [ 4.305046] audit: initializing netlink subsys (disabled)
>> [ 4.305111] audit: type=2000 audit(4.032:1): initialized
>> [ 4.305526] [Xenomai] scheduling class idle registered.
>> [ 4.305530] [Xenomai] scheduling class rt registered.
>> ---- Stops here.
> >From the code, I found it stops at
>> * Ensure all CPUs consumed the IPI to avoid
>> * running __ipipe_cpu_sync prematurely. This
>> * usually resolves the deadlock reason too.
>> while (!cpumask_equal(&online, &__ipipe_cpu_pass_map))
>> Seems online not equal to __ipipe_cpu_pass_map. I am not sure IPI is send
>> to other cores, I am using GICV3. Still debugging.
>> Any hints?
> Resolved. It is my arm trusted firmware issue, not configured ipi critical
is your ATF in some public repository (ie, are you upstreaming it)? just
More information about the Xenomai