Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

nrf52 telnet_shell panic. Mutex using in ISR. #22697

Closed
ToJIka4 opened this issue Feb 10, 2020 · 3 comments · Fixed by #22725
Closed

nrf52 telnet_shell panic. Mutex using in ISR. #22697

ToJIka4 opened this issue Feb 10, 2020 · 3 comments · Fixed by #22725
Assignees
Labels
bug The issue is a bug, or the PR is fixing a bug priority: medium Medium impact/importance bug

Comments

@ToJIka4
Copy link
Contributor

ToJIka4 commented Feb 10, 2020

Stack is

#0  assert_post_action (file=file@entry=0x4ab31 "ZEPHYR_BASE/kernel/include/ksched.h", line=line@entry=269) at ZEPHYR_BASE/lib/os/assert.c:45
#1  0x0003086a in z_sched_lock () at ZEPHYR_BASE/kernel/include/ksched.h:269
#2  z_impl_k_mutex_unlock (mutex=mutex@entry=0x200023d8 <contexts+248>) at ZEPHYR_BASE/kernel/mutex.c:232
#3  0x0003c556 in k_mutex_unlock (mutex=mutex@entry=0x200023d8 <contexts+248>) at zephyr/include/generated/syscalls/kernel.h:644
#4  0x0003c692 in net_context_send (context=0x200023d0 <contexts+240>, buf=0x20000938 <shell_transport_telnet_shell_telnet+8>, len=13, cb=cb@entry=0x5399 <telnet_sent_cb>, timeout=timeout@entry=-1, user_data=user_data@entry=0x0 <sys_pm_notify_power_state_entry>) at ZEPHYR_BASE/subsys/net/ip/net_context.c:1668
#5  0x0000525e in telnet_send () at ZEPHYR_BASE/subsys/shell/shell_telnet.c:138
#6  0x00032eea in z_timer_expiration_handler (t=0x200009a4 <shell_transport_telnet_shell_telnet+116>) at ZEPHYR_BASE/kernel/timer.c:65
#7  0x00032dc4 in z_clock_announce (ticks=<optimized out>) at ZEPHYR_BASE/kernel/timeout.c:204
#8  0x00007dee in _isr_wrapper () at ZEPHYR_BASE/arch/arm/core/aarch32/isr_wrapper.S:163
#9  <signal handler called>

Since timer handlers in nrf52 is in ISR and network uses mutexes we got panic. Maybe moving telnet_send in separate thread will resolve this issue.

@ToJIka4 ToJIka4 added the bug The issue is a bug, or the PR is fixing a bug label Feb 10, 2020
@rlubos
Copy link
Contributor

rlubos commented Feb 11, 2020

Reproduced with telnet sample running over BLE IPSP. I'll try to put telnet_send on a system workqueue instead of calling it directly from a timer handler. If it solves the issue I'll come up with a PR.

@ToJIka4
Copy link
Contributor Author

ToJIka4 commented Feb 11, 2020

Fast solution. Works for me.

--- a/subsys/shell/shell_telnet.c
+++ b/subsys/shell/shell_telnet.c
@@ -150,7 +150,15 @@ static int telnet_send(void)
        return 0;
 }

+static struct k_work send_work;
+
 static void telnet_send_prematurely(struct k_timer *timer)
+{
+       //(void)telnet_send();
+       k_work_submit(&send_work);
+}
+
+static void telnet_send_work(struct k_work *work)
 {
        (void)telnet_send();
 }
@@ -344,6 +352,8 @@ static int init(const struct shell_transport *transport,

        k_fifo_init(&sh_telnet->rx_fifo);
        k_timer_init(&sh_telnet->send_timer, telnet_send_prematurely, NULL);
+
+       k_work_init(&send_work, telnet_send_work);

        return 0;
 }

@rlubos
Copy link
Contributor

rlubos commented Feb 11, 2020

Yeah, I've originally thought of something similar, but eventually, I've ended up using a k_delayed_work. Will submit a PR.

rlubos added a commit to rlubos/zephyr that referenced this issue Feb 11, 2020
A `k_timer` callback is called from the ISR context on certain devices
(nRF), which resulted in an assert in the kernel, as `telnet_send`, and
thus `net_context_send` used a mutex.

Fix the issue by replacing a timer used by the `shell_telnet` module
with a delayed work, which will execute it's callback in a system
workqueue context.

Fixes zephyrproject-rtos#22697

Signed-off-by: Robert Lubos <[email protected]>
@jukkar jukkar added has-pr priority: medium Medium impact/importance bug labels Feb 11, 2020
jukkar pushed a commit that referenced this issue Feb 12, 2020
A `k_timer` callback is called from the ISR context on certain devices
(nRF), which resulted in an assert in the kernel, as `telnet_send`, and
thus `net_context_send` used a mutex.

Fix the issue by replacing a timer used by the `shell_telnet` module
with a delayed work, which will execute it's callback in a system
workqueue context.

Fixes #22697

Signed-off-by: Robert Lubos <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug The issue is a bug, or the PR is fixing a bug priority: medium Medium impact/importance bug
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants