[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <6szkkqxpsw26zajwysdrwplpjvhl5abpnmxgu2xuj3dkzjnvsf@4daqrz4mf44k>
Date: Fri, 2 Aug 2024 11:45:23 +0300
From: Serge Semin <fancer.lancer@...il.com>
To: Thomas Bogendoerfer <tsbogend@...ha.franken.de>,
Jiaxun Yang <jiaxun.yang@...goat.com>, Thomas Gleixner <tglx@...utronix.de>
Cc: Serge Semin <fancer.lancer@...il.com>,
Andrew Morton <akpm@...ux-foundation.org>, Arnd Bergmann <arnd@...db.de>,
Keguang Zhang <keguang.zhang@...il.com>, Gregory CLEMENT <gregory.clement@...tlin.com>,
Théo Lebrun <theo.lebrun@...tlin.com>, Vladimir Kondratiev <vladimir.kondratiev@...ileye.com>,
Tawfik Bayouk <tawfik.bayouk@...ileye.com>, Huacai Chen <chenhuacai@...nel.org>, linux-mips@...r.kernel.org,
linux-kernel@...r.kernel.org
Subject: [RFC] MIPS: smp: Sleeping func called from start_secondary()
Hi folks,
To debug some another problem I recently enabled the
CONFIG_DEBUG_ATOMIC_SLEEP config for my SoC based on the 2xP5600 cores
with MIPS GIC as IRQ-controller. That caused the next BUG backtrace
started being printed to the system log during the device boot-up:
[ 0.118053] BUG: sleeping function called from invalid context at kernel/locking/mutex.c:283
[ 0.118062] in_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 0, name: swapper/1
[ 0.118069] preempt_count: 1, expected: 0
[ 0.118074] RCU nest depth: 0, expected: 0
[ 0.118078] Preemption disabled at:
[ 0.118082] [<80105040>] arch_dup_task_struct+0x20/0x118
[ 0.118116] CPU: 1 UID: 0 PID: 0 Comm: swapper/1 Not tainted 6.11.0-rc1-bt1-00312-gca6f9469050c-dirty #2460
[ 0.118134] Stack : 816d0000 801b89bc 81870000 00000004 a02d0c08 00000000 84ae7dcc 801b84c0
[ 0.118167] 00000000 00000002 00000000 00000000 00000000 00000001 84ae7d70 84aaf200
[ 0.118195] 00000000 00000000 81115acc 00000000 00000059 84ae7bec 00000000 00000000
[ 0.118222] 00000000 ffffffff ffffffea 00000020 816d0000 00000000 81115acc 00000002
[ 0.118250] 00000000 04240021 a02d0c08 00000000 00000000 00000000 30400000 ac24242a
[ 0.118277] ...
[ 0.118286] Call Trace:
[ 0.118289] [<8010af2c>] show_stack+0x88/0x120
[ 0.118309] [<80f09dfc>] dump_stack_lvl+0x78/0xb0
[ 0.118323] [<801778d0>] __might_resched+0x190/0x1f0
[ 0.118349] [<80f10f80>] mutex_lock+0x20/0x74
[ 0.118365] [<801c8590>] irq_create_mapping_affinity+0x48/0x104
[ 0.118390] [<801121ec>] r4k_clockevent_init+0x58/0x38c
[ 0.118402] [<80116658>] start_secondary+0x34/0x134
[ 0.118411] [<80f0b1e4>] smp_bootstrap+0x68/0x98
[ 0.118424]
I managed to investigate the problem a bit and the reason turned out to be
in the irq_create_mapping() method eventually invoked in the framework of the
secondary CPU start-up procedure. The more detailed calls chain is:
start_secondary()
+-> mips_clockevent_init()
+-> r4k_clockevent_init()
+-> get_c0_compare_int()
+-> gic_get_c0_compare_int()
+-> irq_create_mapping()
+-> irq_create_mapping_affinity()
+-> mutex_lock()
+-> might_sleep()
+-> might_resched()
+-> __might_resched()
+-> Print the log above
I currently lack of free time for further investigation in an attempt to
find a reasonable solution. So here is just a report and a short summary
of the problem. Should you have any idea of how to fix the problem I'll be
very glad to test it out on a short notice.
-Serge(y)
Powered by blists - more mailing lists