Hi Niklas,
On Tue, Jan 21, 2025 at 2:59 PM Niklas Söderlund
<niklas.soderlund+renesas@xxxxxxxxxxxx> wrote:
> Use raw_spinlock in order to fix spurious messages about invalid context
> when spinlock debugging is enabled. The lock is only used to serialize
> register access.
>
> [ 4.239592] =============================
> [ 4.239595] [ BUG: Invalid wait context ]
[...]
> [ 4.426274] lock_acquire+0x1c4/0x33c
> [ 4.429942] _raw_spin_lock_irqsave+0x5c/0x80
> [ 4.434307] gpio_rcar_config_interrupt_input_mode+0x34/0x164
> [ 4.440061] gpio_rcar_irq_set_type+0xd4/0xd8
> Signed-off-by: Niklas Söderlund <niklas.soderlund+renesas@xxxxxxxxxxxx>
Thanks for your patch!
This indeed gets rid of the annoying messages on various R-Car boards.
Unfortunately I now start seeing other scary messages during resume
from s2idle/s2ram.
On marzen (R-Car H1):
=============================
[ BUG: Invalid wait context ]
6.13.0-marzen-08235-gb3d2b6c82b8c #193 Not tainted
-----------------------------
swapper/0/0 is trying to lock:
c2d3c994 (&dev->event_lock){..-.}-{3:3}, at: input_event+0x38/0x60
other info that might help us debug this:
context-{2:2}
no locks held by swapper/0/0.
stack backtrace:
CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted
6.13.0-marzen-08235-gb3d2b6c82b8c #193
Hardware name: Generic R8A7779 (Flattened Device Tree)
Call trace:
unwind_backtrace from show_stack+0x10/0x14
show_stack from dump_stack_lvl+0x7c/0xb0
dump_stack_lvl from __lock_acquire+0x38c/0x1698
__lock_acquire from lock_acquire+0x29c/0x338
lock_acquire from _raw_spin_lock_irqsave+0x50/0x64
_raw_spin_lock_irqsave from input_event+0x38/0x60
input_event from gpio_keys_irq_timer+0x30/0x50
gpio_keys_irq_timer from __hrtimer_run_queues+0x208/0x370
__hrtimer_run_queues from hrtimer_interrupt+0xbc/0x1f8
hrtimer_interrupt from twd_handler+0x30/0x3c
twd_handler from handle_percpu_devid_irq+0x58/0xfc
handle_percpu_devid_irq from handle_irq_desc+0x68/0x80
handle_irq_desc from gic_handle_irq+0x74/0x84
gic_handle_irq from generic_handle_arch_irq+0x28/0x3c
generic_handle_arch_irq from __irq_svc+0x8c/0xb8
Exception stack(0xc0e01f30 to 0xc0e01f78)
1f20: ffffffff 00000001
2b229000 00000001
1f40: c0e0be40 c0173ae0 c0e09090 c0e0be40 c0e09054 c0e09090
ffffffff 00000000
1f60: 00000000 c0e01f80 c08d13b8 c08d13c0 200f0013 ffffffff
__irq_svc from cpu_idle_poll+0xc4/0x130
cpu_idle_poll from do_idle+0xb0/0x288
do_idle from cpu_startup_entry+0x28/0x2c
cpu_startup_entry from rest_init+0x150/0x178
rest_init from start_kernel+0x544/0x5d8
On Salvator-X(S) (R-Car Gen3) and Gray/White Hawk (R-Car Gen4):
=============================
WARNING: suspicious RCU usage
6.13.0-rcar3-08235-gb3d2b6c82b8c #174 Tainted: G W
-----------------------------
drivers/net/phy/phy_device.c:1970 suspicious
rcu_dereference_protected() usage!
other info that might help us debug this:
rcu_scheduler_active = 2, debug_locks = 1
5 locks held by s2idle/1070:
#0: ffffff84c6c173f0 (sb_writers#5){.+.+}-{0:0}, at:
file_start_write.isra.0+0x24/0x30
#1: ffffff84cdbf3888 (&of->mutex#2){+.+.}-{4:4}, at:
kernfs_fop_write_iter+0xf8/0x180
#2: ffffff84c1007168 (kn->active#64){.+.+}-{0:0}, at:
kernfs_fop_write_iter+0x100/0x180
#3: ffffffc0812d51e8 (system_transition_mutex){+.+.}-{4:4},
at: pm_suspend+0x84/0x248
#4: ffffff84c211a8f8 (&dev->mutex){....}-{4:4}, at:
device_resume+0xb4/0x1c4
stack backtrace:
CPU: 1 UID: 0 PID: 1070 Comm: s2idle Tainted: G W
6.13.0-rcar3-08235-gb3d2b6c82b8c #174
Tainted: [W]=WARN
Hardware name: Renesas Salvator-X 2nd version board based on
r8a77951 (DT)
Call trace:
show_stack+0x14/0x1c (C)
dump_stack_lvl+0x78/0xa8
dump_stack+0x14/0x1c
lockdep_rcu_suspicious+0x138/0x184
phy_detach+0xc0/0x188
phy_disconnect+0x44/0x50
ravb_close+0x7c/0x1b8
ravb_resume+0xb0/0x130
dpm_run_callback+0x5c/0xc8
device_resume+0xf0/0x1c4
dpm_resume+0x150/0x168
dpm_resume_end+0x14/0x28
suspend_devices_and_enter+0x150/0x59c
pm_suspend+0x214/0x248
state_store+0xa8/0xe8
kobj_attr_store+0x14/0x24
sysfs_kf_write+0x48/0x60
kernfs_fop_write_iter+0x138/0x180
vfs_write+0x148/0x1b4
ksys_write+0x78/0xe0
__arm64_sys_write+0x14/0x1c
invoke_syscall+0x68/0xf0
el0_svc_common.constprop.0+0xb0/0xcc
do_el0_svc+0x18/0x20
el0_svc+0x38/0x90
el0t_64_sync_handler+0x80/0x130
el0t_64_sync+0x158/0x15c
Probably they were just masked by the other issue before?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@xxxxxxxxxxxxxx
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
