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

[Qian Cai]

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

# dmidecode 
# dmidecode 3.1
Getting SMBIOS data from sysfs.
SMBIOS 3.0.0 present.
Table at 0x397D0000.

Handle 0x0000, DMI type 0, 24 bytes
BIOS Information
	Vendor: Huawei
	Version: 1.50
	Release Date: 06/01/2018
	Address: 0xA4800
	Runtime Size: 366 kB
	ROM Size: 8192 kB
	Characteristics:
		PCI is supported
		BIOS is upgradeable
		BIOS shadowing is allowed
		Boot from CD is supported
		Selectable boot is supported
		EDD is supported
		Japanese floppy for NEC 9800 1.2 MB is supported (int 13h)
		Japanese floppy for Toshiba 1.2 MB is supported (int 13h)
		5.25"/360 kB floppy services are supported (int 13h)
		5.25"/1.2 MB floppy services are supported (int 13h)
		3.5"/720 kB floppy services are supported (int 13h)
		3.5"/2.88 MB floppy services are supported (int 13h)
		8042 keyboard services are supported (int 9h)
		CGA/mono video services are supported (int 10h)
		ACPI is supported
		USB legacy is supported
		BIOS boot specification is supported
		Targeted content distribution is supported
		UEFI is supported
	BIOS Revision: 0.0

Handle 0x0001, DMI type 1, 27 bytes
System Information
	Manufacturer: Huawei
	Product Name: TaiShan 2280 
	Version: V100R001C00
	Serial Number: 2102311TBJ10H7000017
	UUID: 8d9f1d7e-639a-11e7-9a0a-a08cf8625acc
	Wake-up Type: Power Switch
	SKU Number: To be filled by O.E.M.
	Family: To be filled by O.E.M.

I am not sure if I understand your second question, but there is no workaround
to make this warning disappear that I am aware of.