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:52, Qian Cai wrote:
> 
> 
>> On Nov 9, 2018, at 10:38 AM, Marc Zyngier <marc.zyngier@arm.com> wrote:
>>
>> 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?
> 
> # 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.

Great stuff. This is what I know as a D05. I used to have one, but it
dropped of the network and I need to find someone to locate it in the
server room.

> 
> 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.

it is not about having a workaround to disable the warning, but a
workaround that the kernel is applying because the HW is busted:

>>> [    0.000000]  arch_timer_check_ool_workaround+0x128/0x2d0

See bb42ca474010 and d003d029cea8 for details.

Now, activating this workaround leads to lockdep being really angry,
most likely because the cpus_read_lock is not taken, which is a change
in behaviour...

I'm trying to dig into this now.

Thanks,

	M.
-- 
Jazz is not dead. It just smells funny...