Re: WARNING: CPU: 0 PID: 0 at drivers/irqchip/irq-gic-v3-its.c
On 11/12/18 3:39 AM, Marc Zyngier wrote:
> On Fri, 09 Nov 2018 18:41:03 +,
> Qian Cai wrote:
>>
>>
>>
>>> On Nov 9, 2018, at 12:41 PM, Marc Zyngier wrote:
>>>
>>> On 09/11/18 17:28, Sudeep Holla wrote:
On Fri, Nov 9, 2018 at 4:10 PM Marc Zyngier wrote:
>
[...]
>
> 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.
>
Yes we found similar issue in kernel/sched/core.c sched_init_smp
There's a fix with detailed description in -next
(Commit 40fa3780bac2 ("sched/core: Take the hotplug lock in
sched_init_smp()")
The behaviour changed since commit cb538267ea1e ("jump_label/lockdep:
Assert we hold the hotplug lock for _cpuslocked() operations")
>>>
>>> I indeed came to the same conclusion, but the fix is slightly less than
>>> obvious. I have the following arm64-specific crap, but it is pretty
>>> terrible:
>>>
>>> diff --git a/arch/arm64/kernel/time.c b/arch/arm64/kernel/time.c
>>> index f258636273c9..9e96e9eaca9b 100644
>>> --- a/arch/arm64/kernel/time.c
>>> +++ b/arch/arm64/kernel/time.c
>>> @@ -36,6 +36,7 @@
>>> #include
>>> #include
>>> #include
>>> +#include
>>>
>>> #include
>>>
>>> @@ -69,7 +70,9 @@ void __init time_init(void)
>>> u32 arch_timer_rate;
>>>
>>> of_clk_init(NULL);
>>> + cpus_read_lock();
>>> timer_probe();
>>> + cpus_read_unlock();
>>>
>>> tick_setup_hrtimer_broadcast();
>>>
>>> Qian, can you please let me know if this helps? If it does, we'll have
>>> to think of something a bit better…
>> After applied the above patch, the original warning is gone but there
>> Is now a new warning.
>
> [...]
>
> Which was ful;ly expected, given that I've taken the cpu lock at some
> semi-random location. I'll try to talk to PeterZ this week to try and
> solve this.
>
Marc, did you have a chance to investigate this further? I have still seen it in
the latest mainline today. This is the only warning left on this Huawei TaiShan
2280 server now after confirmed that those GICv3 warnings were gone.
Re: WARNING: CPU: 0 PID: 0 at drivers/irqchip/irq-gic-v3-its.c
On 11/12/18 3:39 AM, Marc Zyngier wrote:
> On Fri, 09 Nov 2018 18:41:03 +,
> Qian Cai wrote:
>>
>>
>>
>>> On Nov 9, 2018, at 12:41 PM, Marc Zyngier wrote:
>>>
>>> On 09/11/18 17:28, Sudeep Holla wrote:
On Fri, Nov 9, 2018 at 4:10 PM Marc Zyngier wrote:
>
[...]
>
> 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.
>
Yes we found similar issue in kernel/sched/core.c sched_init_smp
There's a fix with detailed description in -next
(Commit 40fa3780bac2 ("sched/core: Take the hotplug lock in
sched_init_smp()")
The behaviour changed since commit cb538267ea1e ("jump_label/lockdep:
Assert we hold the hotplug lock for _cpuslocked() operations")
>>>
>>> I indeed came to the same conclusion, but the fix is slightly less than
>>> obvious. I have the following arm64-specific crap, but it is pretty
>>> terrible:
>>>
>>> diff --git a/arch/arm64/kernel/time.c b/arch/arm64/kernel/time.c
>>> index f258636273c9..9e96e9eaca9b 100644
>>> --- a/arch/arm64/kernel/time.c
>>> +++ b/arch/arm64/kernel/time.c
>>> @@ -36,6 +36,7 @@
>>> #include
>>> #include
>>> #include
>>> +#include
>>>
>>> #include
>>>
>>> @@ -69,7 +70,9 @@ void __init time_init(void)
>>> u32 arch_timer_rate;
>>>
>>> of_clk_init(NULL);
>>> + cpus_read_lock();
>>> timer_probe();
>>> + cpus_read_unlock();
>>>
>>> tick_setup_hrtimer_broadcast();
>>>
>>> Qian, can you please let me know if this helps? If it does, we'll have
>>> to think of something a bit better…
>> After applied the above patch, the original warning is gone but there
>> Is now a new warning.
>
> [...]
>
> Which was ful;ly expected, given that I've taken the cpu lock at some
> semi-random location. I'll try to talk to PeterZ this week to try and
> solve this.
>
Marc, did you have a chance to investigate this further? I have still seen it in
the latest mainline today. This is the only warning left on this Huawei TaiShan
2280 server now after confirmed that those GICv3 warnings were gone.
Re: WARNING: CPU: 0 PID: 0 at drivers/irqchip/irq-gic-v3-its.c
On Fri, 09 Nov 2018 18:41:03 +,
Qian Cai wrote:
>
>
>
> > On Nov 9, 2018, at 12:41 PM, Marc Zyngier wrote:
> >
> > On 09/11/18 17:28, Sudeep Holla wrote:
> >> On Fri, Nov 9, 2018 at 4:10 PM Marc Zyngier wrote:
> >>>
> >> [...]
> >>
> >>>
> >>> 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.
> >>>
> >>
> >> Yes we found similar issue in kernel/sched/core.c sched_init_smp
> >> There's a fix with detailed description in -next
> >> (Commit 40fa3780bac2 ("sched/core: Take the hotplug lock in
> >> sched_init_smp()")
> >>
> >> The behaviour changed since commit cb538267ea1e ("jump_label/lockdep:
> >> Assert we hold the hotplug lock for _cpuslocked() operations")
> >
> > I indeed came to the same conclusion, but the fix is slightly less than
> > obvious. I have the following arm64-specific crap, but it is pretty
> > terrible:
> >
> > diff --git a/arch/arm64/kernel/time.c b/arch/arm64/kernel/time.c
> > index f258636273c9..9e96e9eaca9b 100644
> > --- a/arch/arm64/kernel/time.c
> > +++ b/arch/arm64/kernel/time.c
> > @@ -36,6 +36,7 @@
> > #include
> > #include
> > #include
> > +#include
> >
> > #include
> >
> > @@ -69,7 +70,9 @@ void __init time_init(void)
> > u32 arch_timer_rate;
> >
> > of_clk_init(NULL);
> > + cpus_read_lock();
> > timer_probe();
> > + cpus_read_unlock();
> >
> > tick_setup_hrtimer_broadcast();
> >
> > Qian, can you please let me know if this helps? If it does, we'll have
> > to think of something a bit better…
> After applied the above patch, the original warning is gone but there
> Is now a new warning.
[...]
Which was ful;ly expected, given that I've taken the cpu lock at some
semi-random location. I'll try to talk to PeterZ this week to try and
solve this.
Thanks,
M.
--
Jazz is not dead, it just smell funny.
Re: WARNING: CPU: 0 PID: 0 at drivers/irqchip/irq-gic-v3-its.c
On Fri, 09 Nov 2018 18:41:03 +,
Qian Cai wrote:
>
>
>
> > On Nov 9, 2018, at 12:41 PM, Marc Zyngier wrote:
> >
> > On 09/11/18 17:28, Sudeep Holla wrote:
> >> On Fri, Nov 9, 2018 at 4:10 PM Marc Zyngier wrote:
> >>>
> >> [...]
> >>
> >>>
> >>> 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.
> >>>
> >>
> >> Yes we found similar issue in kernel/sched/core.c sched_init_smp
> >> There's a fix with detailed description in -next
> >> (Commit 40fa3780bac2 ("sched/core: Take the hotplug lock in
> >> sched_init_smp()")
> >>
> >> The behaviour changed since commit cb538267ea1e ("jump_label/lockdep:
> >> Assert we hold the hotplug lock for _cpuslocked() operations")
> >
> > I indeed came to the same conclusion, but the fix is slightly less than
> > obvious. I have the following arm64-specific crap, but it is pretty
> > terrible:
> >
> > diff --git a/arch/arm64/kernel/time.c b/arch/arm64/kernel/time.c
> > index f258636273c9..9e96e9eaca9b 100644
> > --- a/arch/arm64/kernel/time.c
> > +++ b/arch/arm64/kernel/time.c
> > @@ -36,6 +36,7 @@
> > #include
> > #include
> > #include
> > +#include
> >
> > #include
> >
> > @@ -69,7 +70,9 @@ void __init time_init(void)
> > u32 arch_timer_rate;
> >
> > of_clk_init(NULL);
> > + cpus_read_lock();
> > timer_probe();
> > + cpus_read_unlock();
> >
> > tick_setup_hrtimer_broadcast();
> >
> > Qian, can you please let me know if this helps? If it does, we'll have
> > to think of something a bit better…
> After applied the above patch, the original warning is gone but there
> Is now a new warning.
[...]
Which was ful;ly expected, given that I've taken the cpu lock at some
semi-random location. I'll try to talk to PeterZ this week to try and
solve this.
Thanks,
M.
--
Jazz is not dead, it just smell funny.
Re: WARNING: CPU: 0 PID: 0 at drivers/irqchip/irq-gic-v3-its.c
> On Nov 9, 2018, at 12:41 PM, Marc Zyngier wrote:
>
> On 09/11/18 17:28, Sudeep Holla wrote:
>> On Fri, Nov 9, 2018 at 4:10 PM Marc Zyngier wrote:
>>>
>> [...]
>>
>>>
>>> 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.
>>>
>>
>> Yes we found similar issue in kernel/sched/core.c sched_init_smp
>> There's a fix with detailed description in -next
>> (Commit 40fa3780bac2 ("sched/core: Take the hotplug lock in
>> sched_init_smp()")
>>
>> The behaviour changed since commit cb538267ea1e ("jump_label/lockdep:
>> Assert we hold the hotplug lock for _cpuslocked() operations")
>
> I indeed came to the same conclusion, but the fix is slightly less than
> obvious. I have the following arm64-specific crap, but it is pretty
> terrible:
>
> diff --git a/arch/arm64/kernel/time.c b/arch/arm64/kernel/time.c
> index f258636273c9..9e96e9eaca9b 100644
> --- a/arch/arm64/kernel/time.c
> +++ b/arch/arm64/kernel/time.c
> @@ -36,6 +36,7 @@
> #include
> #include
> #include
> +#include
>
> #include
>
> @@ -69,7 +70,9 @@ void __init time_init(void)
> u32 arch_timer_rate;
>
> of_clk_init(NULL);
> + cpus_read_lock();
> timer_probe();
> + cpus_read_unlock();
>
> tick_setup_hrtimer_broadcast();
>
> Qian, can you please let me know if this helps? If it does, we'll have
> to think of something a bit better…
After applied the above patch, the original warning is gone but there
Is now a new warning.
> [0.00] rcu: Offload RCU callbacks from CPUs: (none).
> [0.00]
> [0.00] ==
> [0.00] WARNING: possible circular locking dependency detected
> [0.00] 4.20.0-rc1+ #10 Tainted: GT
> [0.00] --
> [0.00] swapper/0/0 is trying to acquire lock:
> [0.00] (ptrval) (acpi_probe_mutex){}, at:
> __acpi_probe_device_table+0xac/0x1ec
> [0.00]
> [0.00] but task is already holding lock:
> [0.00] (ptrval) (cpu_hotplug_lock.rw_sem){}, at:
> time_init+0x44/0xa0
> [0.00]
> [0.00] which lock already depends on the new lock.
> [0.00]
> [0.00]
> [0.00] the existing dependency chain (in reverse order) is:
> [0.00]
> [0.00] -> #1 (cpu_hotplug_lock.rw_sem){}:
> [0.00]__lock_acquire+0x3cc/0x858
> [0.00]lock_acquire+0x124/0x330
> [0.00]cpus_read_lock+0x6c/0x100
> [0.00]__cpuhp_setup_state+0x38/0x78
> [0.00]gic_init_bases+0x3ac/0x5d8
> [0.00]gic_acpi_init+0x2cc/0x564
> [0.00]acpi_match_madt+0x9c/0x15c
> [0.00]acpi_table_parse_entries_array+0x3e0/0x5d8
> [0.00]acpi_table_parse_entries+0xbc/0x114
> [0.00]acpi_table_parse_madt+0x4c/0x80
> [0.00]__acpi_probe_device_table+0x134/0x1ec
> [0.00]irqchip_init+0x48/0x74
> [0.00]init_IRQ+0xe4/0x12c
> [0.00]start_kernel+0x4d0/0x7d4
> [0.00]
> [0.00] -> #0 (acpi_probe_mutex){}:
> [0.00]validate_chain.isra.19+0xcd8/0x1158
> [0.00]__lock_acquire+0x3cc/0x858
> [0.00]lock_acquire+0x124/0x330
> [0.00]__mutex_lock+0x110/0xa68
> [0.00]mutex_lock_nested+0x3c/0x50
> [0.00]__acpi_probe_device_table+0xac/0x1ec
> [0.00]timer_probe+0x1bc/0x254
> [0.00]time_init+0x48/0xa0
> [0.00]start_kernel+0x4ec/0x7d4
> [0.00]
> [0.00] other info that might help us debug this:
> [0.00]
> [0.00] Possible unsafe locking scenario:
> [0.00]
> [0.00]CPU0CPU1
> [0.00]
> [0.00] lock(cpu_hotplug_lock.rw_sem);
> [0.00]lock(acpi_probe_mutex);
> [0.00]lock(cpu_hotplug_lock.rw_sem);
> [0.00] lock(acpi_probe_mutex);
> [0.00]
> [0.00] *** DEADLOCK ***
> [0.00]
> [0.00] 1 lock held by swapper/0/0:
> [0.00] #0: (ptrval) (cpu_hotplug_lock.rw_sem){}, at:
> time_init+0x44/0xa0
> [0.00]
> [0.00] stack backtrace:
> [0.00] CPU: 0 PID: 0 Comm: swapper/0 Tainted: GT
> 4.20.0-rc1+ #10
> [0.00] Call trace:
> [0.00] dump_backtrace+0x0/0x248
> [0.00] show_stack+0x24/0x30
> [0.00] dump_stack+0xb8/0xf4
> [0.00] print_circular_bug.isra.15+0x240/0x368
> [0.00]
Re: WARNING: CPU: 0 PID: 0 at drivers/irqchip/irq-gic-v3-its.c
> On Nov 9, 2018, at 12:41 PM, Marc Zyngier wrote:
>
> On 09/11/18 17:28, Sudeep Holla wrote:
>> On Fri, Nov 9, 2018 at 4:10 PM Marc Zyngier wrote:
>>>
>> [...]
>>
>>>
>>> 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.
>>>
>>
>> Yes we found similar issue in kernel/sched/core.c sched_init_smp
>> There's a fix with detailed description in -next
>> (Commit 40fa3780bac2 ("sched/core: Take the hotplug lock in
>> sched_init_smp()")
>>
>> The behaviour changed since commit cb538267ea1e ("jump_label/lockdep:
>> Assert we hold the hotplug lock for _cpuslocked() operations")
>
> I indeed came to the same conclusion, but the fix is slightly less than
> obvious. I have the following arm64-specific crap, but it is pretty
> terrible:
>
> diff --git a/arch/arm64/kernel/time.c b/arch/arm64/kernel/time.c
> index f258636273c9..9e96e9eaca9b 100644
> --- a/arch/arm64/kernel/time.c
> +++ b/arch/arm64/kernel/time.c
> @@ -36,6 +36,7 @@
> #include
> #include
> #include
> +#include
>
> #include
>
> @@ -69,7 +70,9 @@ void __init time_init(void)
> u32 arch_timer_rate;
>
> of_clk_init(NULL);
> + cpus_read_lock();
> timer_probe();
> + cpus_read_unlock();
>
> tick_setup_hrtimer_broadcast();
>
> Qian, can you please let me know if this helps? If it does, we'll have
> to think of something a bit better…
After applied the above patch, the original warning is gone but there
Is now a new warning.
> [0.00] rcu: Offload RCU callbacks from CPUs: (none).
> [0.00]
> [0.00] ==
> [0.00] WARNING: possible circular locking dependency detected
> [0.00] 4.20.0-rc1+ #10 Tainted: GT
> [0.00] --
> [0.00] swapper/0/0 is trying to acquire lock:
> [0.00] (ptrval) (acpi_probe_mutex){}, at:
> __acpi_probe_device_table+0xac/0x1ec
> [0.00]
> [0.00] but task is already holding lock:
> [0.00] (ptrval) (cpu_hotplug_lock.rw_sem){}, at:
> time_init+0x44/0xa0
> [0.00]
> [0.00] which lock already depends on the new lock.
> [0.00]
> [0.00]
> [0.00] the existing dependency chain (in reverse order) is:
> [0.00]
> [0.00] -> #1 (cpu_hotplug_lock.rw_sem){}:
> [0.00]__lock_acquire+0x3cc/0x858
> [0.00]lock_acquire+0x124/0x330
> [0.00]cpus_read_lock+0x6c/0x100
> [0.00]__cpuhp_setup_state+0x38/0x78
> [0.00]gic_init_bases+0x3ac/0x5d8
> [0.00]gic_acpi_init+0x2cc/0x564
> [0.00]acpi_match_madt+0x9c/0x15c
> [0.00]acpi_table_parse_entries_array+0x3e0/0x5d8
> [0.00]acpi_table_parse_entries+0xbc/0x114
> [0.00]acpi_table_parse_madt+0x4c/0x80
> [0.00]__acpi_probe_device_table+0x134/0x1ec
> [0.00]irqchip_init+0x48/0x74
> [0.00]init_IRQ+0xe4/0x12c
> [0.00]start_kernel+0x4d0/0x7d4
> [0.00]
> [0.00] -> #0 (acpi_probe_mutex){}:
> [0.00]validate_chain.isra.19+0xcd8/0x1158
> [0.00]__lock_acquire+0x3cc/0x858
> [0.00]lock_acquire+0x124/0x330
> [0.00]__mutex_lock+0x110/0xa68
> [0.00]mutex_lock_nested+0x3c/0x50
> [0.00]__acpi_probe_device_table+0xac/0x1ec
> [0.00]timer_probe+0x1bc/0x254
> [0.00]time_init+0x48/0xa0
> [0.00]start_kernel+0x4ec/0x7d4
> [0.00]
> [0.00] other info that might help us debug this:
> [0.00]
> [0.00] Possible unsafe locking scenario:
> [0.00]
> [0.00]CPU0CPU1
> [0.00]
> [0.00] lock(cpu_hotplug_lock.rw_sem);
> [0.00]lock(acpi_probe_mutex);
> [0.00]lock(cpu_hotplug_lock.rw_sem);
> [0.00] lock(acpi_probe_mutex);
> [0.00]
> [0.00] *** DEADLOCK ***
> [0.00]
> [0.00] 1 lock held by swapper/0/0:
> [0.00] #0: (ptrval) (cpu_hotplug_lock.rw_sem){}, at:
> time_init+0x44/0xa0
> [0.00]
> [0.00] stack backtrace:
> [0.00] CPU: 0 PID: 0 Comm: swapper/0 Tainted: GT
> 4.20.0-rc1+ #10
> [0.00] Call trace:
> [0.00] dump_backtrace+0x0/0x248
> [0.00] show_stack+0x24/0x30
> [0.00] dump_stack+0xb8/0xf4
> [0.00] print_circular_bug.isra.15+0x240/0x368
> [0.00]
Re: WARNING: CPU: 0 PID: 0 at drivers/irqchip/irq-gic-v3-its.c
On 09/11/18 17:28, Sudeep Holla wrote:
> On Fri, Nov 9, 2018 at 4:10 PM Marc Zyngier wrote:
>>
> [...]
>
>>
>> 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.
>>
>
> Yes we found similar issue in kernel/sched/core.c sched_init_smp
> There's a fix with detailed description in -next
> (Commit 40fa3780bac2 ("sched/core: Take the hotplug lock in sched_init_smp()")
>
> The behaviour changed since commit cb538267ea1e ("jump_label/lockdep:
> Assert we hold the hotplug lock for _cpuslocked() operations")
I indeed came to the same conclusion, but the fix is slightly less than
obvious. I have the following arm64-specific crap, but it is pretty
terrible:
diff --git a/arch/arm64/kernel/time.c b/arch/arm64/kernel/time.c
index f258636273c9..9e96e9eaca9b 100644
--- a/arch/arm64/kernel/time.c
+++ b/arch/arm64/kernel/time.c
@@ -36,6 +36,7 @@
#include
#include
#include
+#include
#include
@@ -69,7 +70,9 @@ void __init time_init(void)
u32 arch_timer_rate;
of_clk_init(NULL);
+ cpus_read_lock();
timer_probe();
+ cpus_read_unlock();
tick_setup_hrtimer_broadcast();
Qian, can you please let me know if this helps? If it does, we'll have
to think of something a bit better...
Thanks,
M.
--
Jazz is not dead. It just smells funny...
Re: WARNING: CPU: 0 PID: 0 at drivers/irqchip/irq-gic-v3-its.c
On 09/11/18 17:28, Sudeep Holla wrote:
> On Fri, Nov 9, 2018 at 4:10 PM Marc Zyngier wrote:
>>
> [...]
>
>>
>> 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.
>>
>
> Yes we found similar issue in kernel/sched/core.c sched_init_smp
> There's a fix with detailed description in -next
> (Commit 40fa3780bac2 ("sched/core: Take the hotplug lock in sched_init_smp()")
>
> The behaviour changed since commit cb538267ea1e ("jump_label/lockdep:
> Assert we hold the hotplug lock for _cpuslocked() operations")
I indeed came to the same conclusion, but the fix is slightly less than
obvious. I have the following arm64-specific crap, but it is pretty
terrible:
diff --git a/arch/arm64/kernel/time.c b/arch/arm64/kernel/time.c
index f258636273c9..9e96e9eaca9b 100644
--- a/arch/arm64/kernel/time.c
+++ b/arch/arm64/kernel/time.c
@@ -36,6 +36,7 @@
#include
#include
#include
+#include
#include
@@ -69,7 +70,9 @@ void __init time_init(void)
u32 arch_timer_rate;
of_clk_init(NULL);
+ cpus_read_lock();
timer_probe();
+ cpus_read_unlock();
tick_setup_hrtimer_broadcast();
Qian, can you please let me know if this helps? If it does, we'll have
to think of something a bit better...
Thanks,
M.
--
Jazz is not dead. It just smells funny...
Re: WARNING: CPU: 0 PID: 0 at drivers/irqchip/irq-gic-v3-its.c
On Fri, Nov 9, 2018 at 4:10 PM Marc Zyngier wrote:
>
[...]
>
> 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.
>
Yes we found similar issue in kernel/sched/core.c sched_init_smp
There's a fix with detailed description in -next
(Commit 40fa3780bac2 ("sched/core: Take the hotplug lock in sched_init_smp()")
The behaviour changed since commit cb538267ea1e ("jump_label/lockdep:
Assert we hold the hotplug lock for _cpuslocked() operations")
--
Regards,
Sudeep
Re: WARNING: CPU: 0 PID: 0 at drivers/irqchip/irq-gic-v3-its.c
On Fri, Nov 9, 2018 at 4:10 PM Marc Zyngier wrote:
>
[...]
>
> 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.
>
Yes we found similar issue in kernel/sched/core.c sched_init_smp
There's a fix with detailed description in -next
(Commit 40fa3780bac2 ("sched/core: Take the hotplug lock in sched_init_smp()")
The behaviour changed since commit cb538267ea1e ("jump_label/lockdep:
Assert we hold the hotplug lock for _cpuslocked() operations")
--
Regards,
Sudeep
Re: WARNING: CPU: 0 PID: 0 at drivers/irqchip/irq-gic-v3-its.c
On 09/11/18 15:52, Qian Cai wrote: > > >> On Nov 9, 2018, at 10:38 AM, Marc Zyngier wrote: >> >> On 09/11/18 15:28, Qian Cai wrote: >>> >>> On Nov 9, 2018, at 8:50 AM, Marc Zyngier 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.00] 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.00] WARNING: CPU: 0 PID: 0 at kernel/cpu.c:315 >>> lockdep_assert_cpus_held+0x50/0x60 >>> [0.00] Modules linked in: >>> [0.00] CPU: 0 PID: 0 Comm: swapper/0 Tainted: GT >>> 4.20.0-rc1+ #9 >>> [0.00] pstate: 2085 (nzCv daIf -PAN -UAO) >>> [0.00] pc : lockdep_assert_cpus_held+0x50/0x60 >>> [0.00] lr : lockdep_assert_cpus_held+0x4c/0x60 >>> [0.00] sp : 29c97b10 >>> [0.00] x29: 29c97b10 x28: 29e39000 >>> [0.00] x27: 29cd1000 x26: 29cd2000 >>> [0.00] x25: 29125000 x24: 29cc9868 >>> [0.00] x23: 29c7c040 x22: 1000 >>> [0.00] x21: 0012 x20: 29cc9000 >>> [0.00] x19: 29cd5000 x18: 003f >>> [0.00] x17: x16: >>> [0.00] x15: 0007 x14: 29461cd4 >>> [0.00] x13: 294695ac x12: 295149a4 >>> [0.00] x11: 294e4478 x10: 294e0a50 >>> [0.00] x9 : 29516aa8 x8 : 0ffbffcc4004 >>> [0.00] x7 : 1fffeffbffcc4003 x6 : 0ffbffcc4003 >>> [0.00] x5 : 7fdffe62001b x4 : 0ffbffcc4004 >>> [0.00] x3 : 0ffbffcc4004 x2 : dfff2000 >>> [0.00] x1 : x0 : >>> [0.00] Call trace: >>> [0.00] lockdep_assert_cpus_held+0x50/0x60 >>> [0.00] static_key_enable_cpuslocked+0x30/0xe8 >>> [0.00] arch_timer_check_ool_workaround+0x128/0x2d0 >>> [0.00] arch_timer_acpi_init+0x274/0x6ac >>> [0.00] acpi_table_parse+0x1ac/0x218 >>> [0.00] __acpi_probe_device_table+0x164/0x1ec >>> [0.00] timer_probe+0x1bc/0x254 >>> [0.00] time_init+0x44/0x98 >>> [0.00] start_kernel+0x4ec/0x7d4 >>> [0.00] irq event stamp: 0 >>> [0.00] hardirqs last enabled at (0): [<>] >>> (null) >>> [0.00] hardirqs last disabled at (0): [<>] >>> (null) >>> [0.00] softirqs last enabled at (0): [<>] >>> (null) >>> [0.00] softirqs last disabled at (0): [<>] >>> (null) >>> [0.00] ---[ 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 0x397D. > > Handle 0x, 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
Re: WARNING: CPU: 0 PID: 0 at drivers/irqchip/irq-gic-v3-its.c
On 09/11/18 15:52, Qian Cai wrote: > > >> On Nov 9, 2018, at 10:38 AM, Marc Zyngier wrote: >> >> On 09/11/18 15:28, Qian Cai wrote: >>> >>> On Nov 9, 2018, at 8:50 AM, Marc Zyngier 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.00] 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.00] WARNING: CPU: 0 PID: 0 at kernel/cpu.c:315 >>> lockdep_assert_cpus_held+0x50/0x60 >>> [0.00] Modules linked in: >>> [0.00] CPU: 0 PID: 0 Comm: swapper/0 Tainted: GT >>> 4.20.0-rc1+ #9 >>> [0.00] pstate: 2085 (nzCv daIf -PAN -UAO) >>> [0.00] pc : lockdep_assert_cpus_held+0x50/0x60 >>> [0.00] lr : lockdep_assert_cpus_held+0x4c/0x60 >>> [0.00] sp : 29c97b10 >>> [0.00] x29: 29c97b10 x28: 29e39000 >>> [0.00] x27: 29cd1000 x26: 29cd2000 >>> [0.00] x25: 29125000 x24: 29cc9868 >>> [0.00] x23: 29c7c040 x22: 1000 >>> [0.00] x21: 0012 x20: 29cc9000 >>> [0.00] x19: 29cd5000 x18: 003f >>> [0.00] x17: x16: >>> [0.00] x15: 0007 x14: 29461cd4 >>> [0.00] x13: 294695ac x12: 295149a4 >>> [0.00] x11: 294e4478 x10: 294e0a50 >>> [0.00] x9 : 29516aa8 x8 : 0ffbffcc4004 >>> [0.00] x7 : 1fffeffbffcc4003 x6 : 0ffbffcc4003 >>> [0.00] x5 : 7fdffe62001b x4 : 0ffbffcc4004 >>> [0.00] x3 : 0ffbffcc4004 x2 : dfff2000 >>> [0.00] x1 : x0 : >>> [0.00] Call trace: >>> [0.00] lockdep_assert_cpus_held+0x50/0x60 >>> [0.00] static_key_enable_cpuslocked+0x30/0xe8 >>> [0.00] arch_timer_check_ool_workaround+0x128/0x2d0 >>> [0.00] arch_timer_acpi_init+0x274/0x6ac >>> [0.00] acpi_table_parse+0x1ac/0x218 >>> [0.00] __acpi_probe_device_table+0x164/0x1ec >>> [0.00] timer_probe+0x1bc/0x254 >>> [0.00] time_init+0x44/0x98 >>> [0.00] start_kernel+0x4ec/0x7d4 >>> [0.00] irq event stamp: 0 >>> [0.00] hardirqs last enabled at (0): [<>] >>> (null) >>> [0.00] hardirqs last disabled at (0): [<>] >>> (null) >>> [0.00] softirqs last enabled at (0): [<>] >>> (null) >>> [0.00] softirqs last disabled at (0): [<>] >>> (null) >>> [0.00] ---[ 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 0x397D. > > Handle 0x, 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
Re: WARNING: CPU: 0 PID: 0 at drivers/irqchip/irq-gic-v3-its.c
> On Nov 9, 2018, at 10:38 AM, Marc Zyngier wrote: > > On 09/11/18 15:28, Qian Cai wrote: >> >> >>> On Nov 9, 2018, at 8:50 AM, Marc Zyngier 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.00] 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.00] WARNING: CPU: 0 PID: 0 at kernel/cpu.c:315 >> lockdep_assert_cpus_held+0x50/0x60 >> [0.00] Modules linked in: >> [0.00] CPU: 0 PID: 0 Comm: swapper/0 Tainted: GT >> 4.20.0-rc1+ #9 >> [0.00] pstate: 2085 (nzCv daIf -PAN -UAO) >> [0.00] pc : lockdep_assert_cpus_held+0x50/0x60 >> [0.00] lr : lockdep_assert_cpus_held+0x4c/0x60 >> [0.00] sp : 29c97b10 >> [0.00] x29: 29c97b10 x28: 29e39000 >> [0.00] x27: 29cd1000 x26: 29cd2000 >> [0.00] x25: 29125000 x24: 29cc9868 >> [0.00] x23: 29c7c040 x22: 1000 >> [0.00] x21: 0012 x20: 29cc9000 >> [0.00] x19: 29cd5000 x18: 003f >> [0.00] x17: x16: >> [0.00] x15: 0007 x14: 29461cd4 >> [0.00] x13: 294695ac x12: 295149a4 >> [0.00] x11: 294e4478 x10: 294e0a50 >> [0.00] x9 : 29516aa8 x8 : 0ffbffcc4004 >> [0.00] x7 : 1fffeffbffcc4003 x6 : 0ffbffcc4003 >> [0.00] x5 : 7fdffe62001b x4 : 0ffbffcc4004 >> [0.00] x3 : 0ffbffcc4004 x2 : dfff2000 >> [0.00] x1 : x0 : >> [0.00] Call trace: >> [0.00] lockdep_assert_cpus_held+0x50/0x60 >> [0.00] static_key_enable_cpuslocked+0x30/0xe8 >> [0.00] arch_timer_check_ool_workaround+0x128/0x2d0 >> [0.00] arch_timer_acpi_init+0x274/0x6ac >> [0.00] acpi_table_parse+0x1ac/0x218 >> [0.00] __acpi_probe_device_table+0x164/0x1ec >> [0.00] timer_probe+0x1bc/0x254 >> [0.00] time_init+0x44/0x98 >> [0.00] start_kernel+0x4ec/0x7d4 >> [0.00] irq event stamp: 0 >> [0.00] hardirqs last enabled at (0): [<>] >> (null) >> [0.00] hardirqs last disabled at (0): [<>] >> (null) >> [0.00] softirqs last enabled at (0): [<>] >> (null) >> [0.00] softirqs last disabled at (0): [<>] >> (null) >> [0.00] ---[ 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 0x397D. Handle 0x, 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
Re: WARNING: CPU: 0 PID: 0 at drivers/irqchip/irq-gic-v3-its.c
> On Nov 9, 2018, at 10:38 AM, Marc Zyngier wrote: > > On 09/11/18 15:28, Qian Cai wrote: >> >> >>> On Nov 9, 2018, at 8:50 AM, Marc Zyngier 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.00] 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.00] WARNING: CPU: 0 PID: 0 at kernel/cpu.c:315 >> lockdep_assert_cpus_held+0x50/0x60 >> [0.00] Modules linked in: >> [0.00] CPU: 0 PID: 0 Comm: swapper/0 Tainted: GT >> 4.20.0-rc1+ #9 >> [0.00] pstate: 2085 (nzCv daIf -PAN -UAO) >> [0.00] pc : lockdep_assert_cpus_held+0x50/0x60 >> [0.00] lr : lockdep_assert_cpus_held+0x4c/0x60 >> [0.00] sp : 29c97b10 >> [0.00] x29: 29c97b10 x28: 29e39000 >> [0.00] x27: 29cd1000 x26: 29cd2000 >> [0.00] x25: 29125000 x24: 29cc9868 >> [0.00] x23: 29c7c040 x22: 1000 >> [0.00] x21: 0012 x20: 29cc9000 >> [0.00] x19: 29cd5000 x18: 003f >> [0.00] x17: x16: >> [0.00] x15: 0007 x14: 29461cd4 >> [0.00] x13: 294695ac x12: 295149a4 >> [0.00] x11: 294e4478 x10: 294e0a50 >> [0.00] x9 : 29516aa8 x8 : 0ffbffcc4004 >> [0.00] x7 : 1fffeffbffcc4003 x6 : 0ffbffcc4003 >> [0.00] x5 : 7fdffe62001b x4 : 0ffbffcc4004 >> [0.00] x3 : 0ffbffcc4004 x2 : dfff2000 >> [0.00] x1 : x0 : >> [0.00] Call trace: >> [0.00] lockdep_assert_cpus_held+0x50/0x60 >> [0.00] static_key_enable_cpuslocked+0x30/0xe8 >> [0.00] arch_timer_check_ool_workaround+0x128/0x2d0 >> [0.00] arch_timer_acpi_init+0x274/0x6ac >> [0.00] acpi_table_parse+0x1ac/0x218 >> [0.00] __acpi_probe_device_table+0x164/0x1ec >> [0.00] timer_probe+0x1bc/0x254 >> [0.00] time_init+0x44/0x98 >> [0.00] start_kernel+0x4ec/0x7d4 >> [0.00] irq event stamp: 0 >> [0.00] hardirqs last enabled at (0): [<>] >> (null) >> [0.00] hardirqs last disabled at (0): [<>] >> (null) >> [0.00] softirqs last enabled at (0): [<>] >> (null) >> [0.00] softirqs last disabled at (0): [<>] >> (null) >> [0.00] ---[ 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 0x397D. Handle 0x, 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
Re: WARNING: CPU: 0 PID: 0 at drivers/irqchip/irq-gic-v3-its.c
On 09/11/18 15:28, Qian Cai wrote: > > >> On Nov 9, 2018, at 8:50 AM, Marc Zyngier 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.00] 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.00] WARNING: CPU: 0 PID: 0 at kernel/cpu.c:315 > lockdep_assert_cpus_held+0x50/0x60 > [0.00] Modules linked in: > [0.00] CPU: 0 PID: 0 Comm: swapper/0 Tainted: GT > 4.20.0-rc1+ #9 > [0.00] pstate: 2085 (nzCv daIf -PAN -UAO) > [0.00] pc : lockdep_assert_cpus_held+0x50/0x60 > [0.00] lr : lockdep_assert_cpus_held+0x4c/0x60 > [0.00] sp : 29c97b10 > [0.00] x29: 29c97b10 x28: 29e39000 > [0.00] x27: 29cd1000 x26: 29cd2000 > [0.00] x25: 29125000 x24: 29cc9868 > [0.00] x23: 29c7c040 x22: 1000 > [0.00] x21: 0012 x20: 29cc9000 > [0.00] x19: 29cd5000 x18: 003f > [0.00] x17: x16: > [0.00] x15: 0007 x14: 29461cd4 > [0.00] x13: 294695ac x12: 295149a4 > [0.00] x11: 294e4478 x10: 294e0a50 > [0.00] x9 : 29516aa8 x8 : 0ffbffcc4004 > [0.00] x7 : 1fffeffbffcc4003 x6 : 0ffbffcc4003 > [0.00] x5 : 7fdffe62001b x4 : 0ffbffcc4004 > [0.00] x3 : 0ffbffcc4004 x2 : dfff2000 > [0.00] x1 : x0 : > [0.00] Call trace: > [0.00] lockdep_assert_cpus_held+0x50/0x60 > [0.00] static_key_enable_cpuslocked+0x30/0xe8 > [0.00] arch_timer_check_ool_workaround+0x128/0x2d0 > [0.00] arch_timer_acpi_init+0x274/0x6ac > [0.00] acpi_table_parse+0x1ac/0x218 > [0.00] __acpi_probe_device_table+0x164/0x1ec > [0.00] timer_probe+0x1bc/0x254 > [0.00] time_init+0x44/0x98 > [0.00] start_kernel+0x4ec/0x7d4 > [0.00] irq event stamp: 0 > [0.00] hardirqs last enabled at (0): [<>] > (null) > [0.00] hardirqs last disabled at (0): [<>] > (null) > [0.00] softirqs last enabled at (0): [<>] > (null) > [0.00] softirqs last disabled at (0): [<>] > (null) > [0.00] ---[ 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...
Re: WARNING: CPU: 0 PID: 0 at drivers/irqchip/irq-gic-v3-its.c
On 09/11/18 15:28, Qian Cai wrote: > > >> On Nov 9, 2018, at 8:50 AM, Marc Zyngier 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.00] 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.00] WARNING: CPU: 0 PID: 0 at kernel/cpu.c:315 > lockdep_assert_cpus_held+0x50/0x60 > [0.00] Modules linked in: > [0.00] CPU: 0 PID: 0 Comm: swapper/0 Tainted: GT > 4.20.0-rc1+ #9 > [0.00] pstate: 2085 (nzCv daIf -PAN -UAO) > [0.00] pc : lockdep_assert_cpus_held+0x50/0x60 > [0.00] lr : lockdep_assert_cpus_held+0x4c/0x60 > [0.00] sp : 29c97b10 > [0.00] x29: 29c97b10 x28: 29e39000 > [0.00] x27: 29cd1000 x26: 29cd2000 > [0.00] x25: 29125000 x24: 29cc9868 > [0.00] x23: 29c7c040 x22: 1000 > [0.00] x21: 0012 x20: 29cc9000 > [0.00] x19: 29cd5000 x18: 003f > [0.00] x17: x16: > [0.00] x15: 0007 x14: 29461cd4 > [0.00] x13: 294695ac x12: 295149a4 > [0.00] x11: 294e4478 x10: 294e0a50 > [0.00] x9 : 29516aa8 x8 : 0ffbffcc4004 > [0.00] x7 : 1fffeffbffcc4003 x6 : 0ffbffcc4003 > [0.00] x5 : 7fdffe62001b x4 : 0ffbffcc4004 > [0.00] x3 : 0ffbffcc4004 x2 : dfff2000 > [0.00] x1 : x0 : > [0.00] Call trace: > [0.00] lockdep_assert_cpus_held+0x50/0x60 > [0.00] static_key_enable_cpuslocked+0x30/0xe8 > [0.00] arch_timer_check_ool_workaround+0x128/0x2d0 > [0.00] arch_timer_acpi_init+0x274/0x6ac > [0.00] acpi_table_parse+0x1ac/0x218 > [0.00] __acpi_probe_device_table+0x164/0x1ec > [0.00] timer_probe+0x1bc/0x254 > [0.00] time_init+0x44/0x98 > [0.00] start_kernel+0x4ec/0x7d4 > [0.00] irq event stamp: 0 > [0.00] hardirqs last enabled at (0): [<>] > (null) > [0.00] hardirqs last disabled at (0): [<>] > (null) > [0.00] softirqs last enabled at (0): [<>] > (null) > [0.00] softirqs last disabled at (0): [<>] > (null) > [0.00] ---[ 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...
Re: WARNING: CPU: 0 PID: 0 at drivers/irqchip/irq-gic-v3-its.c
> On Nov 9, 2018, at 8:50 AM, Marc Zyngier 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.00] 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, [0.00] WARNING: CPU: 0 PID: 0 at kernel/cpu.c:315 lockdep_assert_cpus_held+0x50/0x60 [0.00] Modules linked in: [0.00] CPU: 0 PID: 0 Comm: swapper/0 Tainted: GT 4.20.0-rc1+ #9 [0.00] pstate: 2085 (nzCv daIf -PAN -UAO) [0.00] pc : lockdep_assert_cpus_held+0x50/0x60 [0.00] lr : lockdep_assert_cpus_held+0x4c/0x60 [0.00] sp : 29c97b10 [0.00] x29: 29c97b10 x28: 29e39000 [0.00] x27: 29cd1000 x26: 29cd2000 [0.00] x25: 29125000 x24: 29cc9868 [0.00] x23: 29c7c040 x22: 1000 [0.00] x21: 0012 x20: 29cc9000 [0.00] x19: 29cd5000 x18: 003f [0.00] x17: x16: [0.00] x15: 0007 x14: 29461cd4 [0.00] x13: 294695ac x12: 295149a4 [0.00] x11: 294e4478 x10: 294e0a50 [0.00] x9 : 29516aa8 x8 : 0ffbffcc4004 [0.00] x7 : 1fffeffbffcc4003 x6 : 0ffbffcc4003 [0.00] x5 : 7fdffe62001b x4 : 0ffbffcc4004 [0.00] x3 : 0ffbffcc4004 x2 : dfff2000 [0.00] x1 : x0 : [0.00] Call trace: [0.00] lockdep_assert_cpus_held+0x50/0x60 [0.00] static_key_enable_cpuslocked+0x30/0xe8 [0.00] arch_timer_check_ool_workaround+0x128/0x2d0 [0.00] arch_timer_acpi_init+0x274/0x6ac [0.00] acpi_table_parse+0x1ac/0x218 [0.00] __acpi_probe_device_table+0x164/0x1ec [0.00] timer_probe+0x1bc/0x254 [0.00] time_init+0x44/0x98 [0.00] start_kernel+0x4ec/0x7d4 [0.00] irq event stamp: 0 [0.00] hardirqs last enabled at (0): [<>] (null) [0.00] hardirqs last disabled at (0): [<>] (null) [0.00] softirqs last enabled at (0): [<>] (null) [0.00] softirqs last disabled at (0): [<>] (null) [0.00] ---[ end trace 1dc5085680256ac1 ]— Here is the kernel config used, https://c.gmx.com/@642631272677512867/tqD5eulbQAC-1h-fkVe1Iw
Re: WARNING: CPU: 0 PID: 0 at drivers/irqchip/irq-gic-v3-its.c
> On Nov 9, 2018, at 8:50 AM, Marc Zyngier 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.00] 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, [0.00] WARNING: CPU: 0 PID: 0 at kernel/cpu.c:315 lockdep_assert_cpus_held+0x50/0x60 [0.00] Modules linked in: [0.00] CPU: 0 PID: 0 Comm: swapper/0 Tainted: GT 4.20.0-rc1+ #9 [0.00] pstate: 2085 (nzCv daIf -PAN -UAO) [0.00] pc : lockdep_assert_cpus_held+0x50/0x60 [0.00] lr : lockdep_assert_cpus_held+0x4c/0x60 [0.00] sp : 29c97b10 [0.00] x29: 29c97b10 x28: 29e39000 [0.00] x27: 29cd1000 x26: 29cd2000 [0.00] x25: 29125000 x24: 29cc9868 [0.00] x23: 29c7c040 x22: 1000 [0.00] x21: 0012 x20: 29cc9000 [0.00] x19: 29cd5000 x18: 003f [0.00] x17: x16: [0.00] x15: 0007 x14: 29461cd4 [0.00] x13: 294695ac x12: 295149a4 [0.00] x11: 294e4478 x10: 294e0a50 [0.00] x9 : 29516aa8 x8 : 0ffbffcc4004 [0.00] x7 : 1fffeffbffcc4003 x6 : 0ffbffcc4003 [0.00] x5 : 7fdffe62001b x4 : 0ffbffcc4004 [0.00] x3 : 0ffbffcc4004 x2 : dfff2000 [0.00] x1 : x0 : [0.00] Call trace: [0.00] lockdep_assert_cpus_held+0x50/0x60 [0.00] static_key_enable_cpuslocked+0x30/0xe8 [0.00] arch_timer_check_ool_workaround+0x128/0x2d0 [0.00] arch_timer_acpi_init+0x274/0x6ac [0.00] acpi_table_parse+0x1ac/0x218 [0.00] __acpi_probe_device_table+0x164/0x1ec [0.00] timer_probe+0x1bc/0x254 [0.00] time_init+0x44/0x98 [0.00] start_kernel+0x4ec/0x7d4 [0.00] irq event stamp: 0 [0.00] hardirqs last enabled at (0): [<>] (null) [0.00] hardirqs last disabled at (0): [<>] (null) [0.00] softirqs last enabled at (0): [<>] (null) [0.00] softirqs last disabled at (0): [<>] (null) [0.00] ---[ end trace 1dc5085680256ac1 ]— Here is the kernel config used, https://c.gmx.com/@642631272677512867/tqD5eulbQAC-1h-fkVe1Iw
Re: WARNING: CPU: 0 PID: 0 at drivers/irqchip/irq-gic-v3-its.c
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.00] 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 -- Jazz is not dead. It just smells funny...
Re: WARNING: CPU: 0 PID: 0 at drivers/irqchip/irq-gic-v3-its.c
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.00] 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 -- Jazz is not dead. It just smells funny...
Re: WARNING: CPU: 0 PID: 0 at drivers/irqchip/irq-gic-v3-its.c
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.00] 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.
Re: WARNING: CPU: 0 PID: 0 at drivers/irqchip/irq-gic-v3-its.c
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.00] 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.
Re: WARNING: CPU: 0 PID: 0 at drivers/irqchip/irq-gic-v3-its.c
[+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.00] 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? > [0.00] Modules linked in: > [0.00] CPU: 0 PID: 0 Comm: swapper/0 Tainted: GT > 4.20.0- > rc1+ #7 > [0.00] pstate: 6085 (nZCv daIf -PAN -UAO) > [0.00] pc : its_init+0x588/0xb54 > [0.00] lr : its_init+0x558/0xb54 > [0.00] sp : 29ca79d0 > [0.00] x29: 29ca79d0 x28: 001dc0fb > [0.00] x27: 7fe007703ec0 x26: 3fe2e7a5444e6979 > [0.00] x25: 293a8000 x24: 0001 > [0.00] x23: 29ce61a0 x22: 1fffe40001394f4e > [0.00] x21: 29f84000 x20: 2c0c3000 > [0.00] x19: 28fb2000 x18: 003f > [0.00] x17: x16: > [0.00] x15: 0007 x14: 29ceea80 > [0.00] x13: 29ceea80 x12: 801dc0d60f80 > [0.00] x11: 801dc0d6f080 x10: 29ceea80 > [0.00] x9 : x8 : 801dc0fc > [0.00] x7 : a2a2a2a2a2a2a2a2 x6 : 1003b81f7fff > [0.00] x5 : 801dc0fb x4 : > [0.00] x3 : 003f x2 : dfff2000 > [0.00] x1 : 0001 x0 : 6667f74e4ba50b25 > [0.00] Call trace: > [0.00] its_init+0x588/0xb54 > [0.00] gic_init_bases+0x53c/0x5d4 > [0.00] gic_acpi_init+0x2cc/0x564 > [0.00] acpi_match_madt+0x9c/0x15c > [0.00] acpi_table_parse_entries_array+0x3e0/0x5d8 > [0.00] acpi_table_parse_entries+0xbc/0x114 > [0.00] acpi_table_parse_madt+0x4c/0x80 > [0.00] __acpi_probe_device_table+0x134/0x1ec > [0.00] irqchip_init+0x48/0x74 > [0.00] init_IRQ+0xe4/0x12c > [0.00] start_kernel+0x4d0/0x7d4 > [0.00] irq event stamp: 0 > [0.00] hardirqs last enabled at (0): > [<>] (null) > [0.00] hardirqs last disabled at (0): > [<>] (null) > [0.00] softirqs last enabled at (0): > [<>] (null) > [0.00] softirqs last disabled at (0): > [<>] (null) > [0.00] ---[ end trace f27c5aed63f8afd4 ]--- > [0.00] GICv3: using LPI property table @0x001dc0fb > [0.00] ITS: Using DirectLPI for VPE invalidation > [0.00] ITS: Enabling GICv4 support > [0.00] WARNING: CPU: 0 PID: 0 at drivers/irqchip/irq-gic-v3-its.c:2096 > its_cpu_init_lpis+0x3b4/0x3f0 Same thing here. > [0.00] Modules linked in: > [0.00] CPU: 0 PID: 0 Comm: swapper/0 Tainted: GW T > 4.20.0- > rc1+ #7 > [0.00] pstate: 6085 (nZCv daIf -PAN -UAO) > [0.00] pc : its_cpu_init_lpis+0x3b4/0x3f0 > [0.00] lr : its_cpu_init_lpis+0x3b0/0x3f0 > [0.00] sp : 29ca7a00 > [0.00] x29: 29ca7a00 x28: 29ce6188 > [0.00] x27: 601df1e3 x26: 29ca7a00 > [0.00] x25: 001dc0fc x24: 2c0c3000 > [0.00] x23: 7fe007703f00 x22: 293a8000 > [0.00] x21: 2c18 x20: 29cd9000 > [0.00] x19: 1fffe40001394f4c x18: 003f > [0.00] x17: x16: > [0.00] x15: 0007 x14: 294f050c > [0.00] x13: 294f3cac x12: 294e7248 > [0.00] x11: 294e69e0 x10: 294e9d18 > [0.00] x9 : 1fffe40001394e5c x8 : 040001394edf > [0.00] x7 : 41b58ab3 x6 : f1f1f1f1 > [0.00] x5 : 41b58ab3 x4 : f1f1f1f1 > [0.00] x3 : 040001394f4c x2 : > [0.00] x1 : 0001 x0 : ffed > [0.00] Call trace: > [0.00] its_cpu_init_lpis+0x3b4/0x3f0 > [0.00] its_cpu_init+0xa8/0x220 > [0.00] gic_init_bases+0x540/0x5d4 > [0.00] gic_acpi_init+0x2cc/0x564 > [0.00] acpi_match_madt+0x9c/0x15c > [0.00] acpi_table_parse_entries_array+0x3e0/0x5d8 > [0.00] acpi_table_parse_entries+0xbc/0x114 > [0.00] acpi_table_parse_madt+0x4c/0x80 > [0.00] __acpi_probe_device_table+0x134/0x1ec > [0.00]
Re: WARNING: CPU: 0 PID: 0 at drivers/irqchip/irq-gic-v3-its.c
[+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.00] 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? > [0.00] Modules linked in: > [0.00] CPU: 0 PID: 0 Comm: swapper/0 Tainted: GT > 4.20.0- > rc1+ #7 > [0.00] pstate: 6085 (nZCv daIf -PAN -UAO) > [0.00] pc : its_init+0x588/0xb54 > [0.00] lr : its_init+0x558/0xb54 > [0.00] sp : 29ca79d0 > [0.00] x29: 29ca79d0 x28: 001dc0fb > [0.00] x27: 7fe007703ec0 x26: 3fe2e7a5444e6979 > [0.00] x25: 293a8000 x24: 0001 > [0.00] x23: 29ce61a0 x22: 1fffe40001394f4e > [0.00] x21: 29f84000 x20: 2c0c3000 > [0.00] x19: 28fb2000 x18: 003f > [0.00] x17: x16: > [0.00] x15: 0007 x14: 29ceea80 > [0.00] x13: 29ceea80 x12: 801dc0d60f80 > [0.00] x11: 801dc0d6f080 x10: 29ceea80 > [0.00] x9 : x8 : 801dc0fc > [0.00] x7 : a2a2a2a2a2a2a2a2 x6 : 1003b81f7fff > [0.00] x5 : 801dc0fb x4 : > [0.00] x3 : 003f x2 : dfff2000 > [0.00] x1 : 0001 x0 : 6667f74e4ba50b25 > [0.00] Call trace: > [0.00] its_init+0x588/0xb54 > [0.00] gic_init_bases+0x53c/0x5d4 > [0.00] gic_acpi_init+0x2cc/0x564 > [0.00] acpi_match_madt+0x9c/0x15c > [0.00] acpi_table_parse_entries_array+0x3e0/0x5d8 > [0.00] acpi_table_parse_entries+0xbc/0x114 > [0.00] acpi_table_parse_madt+0x4c/0x80 > [0.00] __acpi_probe_device_table+0x134/0x1ec > [0.00] irqchip_init+0x48/0x74 > [0.00] init_IRQ+0xe4/0x12c > [0.00] start_kernel+0x4d0/0x7d4 > [0.00] irq event stamp: 0 > [0.00] hardirqs last enabled at (0): > [<>] (null) > [0.00] hardirqs last disabled at (0): > [<>] (null) > [0.00] softirqs last enabled at (0): > [<>] (null) > [0.00] softirqs last disabled at (0): > [<>] (null) > [0.00] ---[ end trace f27c5aed63f8afd4 ]--- > [0.00] GICv3: using LPI property table @0x001dc0fb > [0.00] ITS: Using DirectLPI for VPE invalidation > [0.00] ITS: Enabling GICv4 support > [0.00] WARNING: CPU: 0 PID: 0 at drivers/irqchip/irq-gic-v3-its.c:2096 > its_cpu_init_lpis+0x3b4/0x3f0 Same thing here. > [0.00] Modules linked in: > [0.00] CPU: 0 PID: 0 Comm: swapper/0 Tainted: GW T > 4.20.0- > rc1+ #7 > [0.00] pstate: 6085 (nZCv daIf -PAN -UAO) > [0.00] pc : its_cpu_init_lpis+0x3b4/0x3f0 > [0.00] lr : its_cpu_init_lpis+0x3b0/0x3f0 > [0.00] sp : 29ca7a00 > [0.00] x29: 29ca7a00 x28: 29ce6188 > [0.00] x27: 601df1e3 x26: 29ca7a00 > [0.00] x25: 001dc0fc x24: 2c0c3000 > [0.00] x23: 7fe007703f00 x22: 293a8000 > [0.00] x21: 2c18 x20: 29cd9000 > [0.00] x19: 1fffe40001394f4c x18: 003f > [0.00] x17: x16: > [0.00] x15: 0007 x14: 294f050c > [0.00] x13: 294f3cac x12: 294e7248 > [0.00] x11: 294e69e0 x10: 294e9d18 > [0.00] x9 : 1fffe40001394e5c x8 : 040001394edf > [0.00] x7 : 41b58ab3 x6 : f1f1f1f1 > [0.00] x5 : 41b58ab3 x4 : f1f1f1f1 > [0.00] x3 : 040001394f4c x2 : > [0.00] x1 : 0001 x0 : ffed > [0.00] Call trace: > [0.00] its_cpu_init_lpis+0x3b4/0x3f0 > [0.00] its_cpu_init+0xa8/0x220 > [0.00] gic_init_bases+0x540/0x5d4 > [0.00] gic_acpi_init+0x2cc/0x564 > [0.00] acpi_match_madt+0x9c/0x15c > [0.00] acpi_table_parse_entries_array+0x3e0/0x5d8 > [0.00] acpi_table_parse_entries+0xbc/0x114 > [0.00] acpi_table_parse_madt+0x4c/0x80 > [0.00] __acpi_probe_device_table+0x134/0x1ec > [0.00]
