Messages in this thread | | | Subject | Re: WARNING: CPU: 0 PID: 0 at drivers/irqchip/irq-gic-v3-its.c | From | Qian Cai <> | Date | Fri, 9 Nov 2018 10:52:04 -0500 |
| |
> 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.
| |