lkml.org 
[lkml]   [2018]   [Nov]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: WARNING: CPU: 0 PID: 0 at drivers/irqchip/irq-gic-v3-its.c
From
Date


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

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.

\
 
 \ /
  Last update: 2018-11-09 16:52    [W:0.055 / U:3.752 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site