[Xenomai] xenomai on ARM64 question

Jorge Ramirez 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:
>>>> Hi,
>>>>
>>>> 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?
>>>>
>>>> Log:
>>>> [   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] [00000000] *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
>>> missing.
>> 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))
>>                                 cpu_relax();
>>
>> 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
> correctly.

is your ATF in some public repository (ie, are you upstreaming it)? just 
curious...





More information about the Xenomai mailing list