Re: WARNING: CPU: 0 PID: 0 at drivers/irqchip/irq-gic-v3-its.c

[Marc Zyngier <marc.zyngier@arm.com>]

On 09/11/18 15:28, Qian Cai wrote:
> 
> 
>> On Nov 9, 2018, at 8:50 AM, Marc Zyngier <marc.zyngier@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...