On 09/11/18 15:28, Qian Cai wrote:
>
>
>> On Nov 9, 2018, at 8:50 AM, Marc Zyngier <marc.zyng...@arm.com> wrote:
>>
>> On 09/11/18 12:28, Qian Cai wrote:
>>>
>>> On 11/9/18 at 7:08 AM, Marc Zyngier wrote:
>>>
>>>> [+Ard]
>>>>
>>>> On 08/11/18 20:59, Qian Cai wrote:
>>>>> Just booting up the latest git master (b00d209) on an aarch64 server and
>>>>> saw
>>>>> this. Not sure about the third warning (at kernel/cpu.c:315
>>>>> lockdep_assert_cpus_held+0x50/0x60) relates to irqchip or not, but
>>>>> appended it
>>>>> to here anyway just in case.
>>>>>
>>>>> [ 0.000000] WARNING: CPU: 0 PID: 0 at
>>>>> drivers/irqchip/irq-gic-v3-its.c:1696
>>>>> its_init+0x588/0xb54
>>>>
>>>> It looks like EFI cannot manage to reserve the memory for your GIC
>>>> redistributors. Pretty annoying. At the same time, you have reported
>>>> other issues with the EFI reservation mechanism, such as:
>>>>
>>>> https://lore.kernel.org/patchwork/patch/1008413/
>>>>
>>>> for which you have given a "Tested-by:". Is that related?
>>> No, I don’t think so. Those warnings are still there even after applied the
>>> patch above.
>>
>> Do you also have this series[1] applied? I'd otherwise need your
>> configuration to try and reproduce it, as I can't manage to trigger it
>> on my own setup.
>>
>> Thanks,
>>
>> M.
>>
>> [1] https://www.spinics.net/lists/arm-kernel/msg685751.html
> After applied the above series on the top of the mainline (b00d209), the only
> warning exist is,
OK, so the EFI/GICv3 stuff is sorted.
>
> [ 0.000000] WARNING: CPU: 0 PID: 0 at kernel/cpu.c:315
> lockdep_assert_cpus_held+0x50/0x60
> [ 0.000000] Modules linked in:
> [ 0.000000] CPU: 0 PID: 0 Comm: swapper/0 Tainted: G T
> 4.20.0-rc1+ #9
> [ 0.000000] pstate: 20000085 (nzCv daIf -PAN -UAO)
> [ 0.000000] pc : lockdep_assert_cpus_held+0x50/0x60
> [ 0.000000] lr : lockdep_assert_cpus_held+0x4c/0x60
> [ 0.000000] sp : ffff200009c97b10
> [ 0.000000] x29: ffff200009c97b10 x28: ffff200009e39000
> [ 0.000000] x27: ffff200009cd1000 x26: ffff200009cd2000
> [ 0.000000] x25: ffff200009125000 x24: ffff200009cc9868
> [ 0.000000] x23: ffff200009c7c040 x22: 0000000000001000
> [ 0.000000] x21: 0000000000000012 x20: ffff200009cc9000
> [ 0.000000] x19: ffff200009cd5000 x18: 000000000000003f
> [ 0.000000] x17: 0000000000000000 x16: 0000000000000000
> [ 0.000000] x15: 0000000000000007 x14: ffff200009461cd4
> [ 0.000000] x13: ffff2000094695ac x12: ffff2000095149a4
> [ 0.000000] x11: ffff2000094e4478 x10: ffff2000094e0a50
> [ 0.000000] x9 : ffff200009516aa8 x8 : ffff0ffbffcc4004
> [ 0.000000] x7 : 1fffeffbffcc4003 x6 : ffff0ffbffcc4003
> [ 0.000000] x5 : ffff7fdffe62001b x4 : ffff0ffbffcc4004
> [ 0.000000] x3 : ffff0ffbffcc4004 x2 : dfff200000000000
> [ 0.000000] x1 : 0000000000000000 x0 : 0000000000000000
> [ 0.000000] Call trace:
> [ 0.000000] lockdep_assert_cpus_held+0x50/0x60
> [ 0.000000] static_key_enable_cpuslocked+0x30/0xe8
> [ 0.000000] arch_timer_check_ool_workaround+0x128/0x2d0
> [ 0.000000] arch_timer_acpi_init+0x274/0x6ac
> [ 0.000000] acpi_table_parse+0x1ac/0x218
> [ 0.000000] __acpi_probe_device_table+0x164/0x1ec
> [ 0.000000] timer_probe+0x1bc/0x254
> [ 0.000000] time_init+0x44/0x98
> [ 0.000000] start_kernel+0x4ec/0x7d4
> [ 0.000000] irq event stamp: 0
> [ 0.000000] hardirqs last enabled at (0): [<0000000000000000>]
> (null)
> [ 0.000000] hardirqs last disabled at (0): [<0000000000000000>]
> (null)
> [ 0.000000] softirqs last enabled at (0): [<0000000000000000>]
> (null)
> [ 0.000000] softirqs last disabled at (0): [<0000000000000000>]
> (null)
> [ 0.000000] ---[ end trace 1dc5085680256ac1 ]—
Now this one: what machine is this? What is the workaround that gets
applied?
Thanks,
M.
--
Jazz is not dead. It just smells funny...
