Kernel work increment/decrement prevents MCU going to sleep

[alexandruradovici]

Pull Request Overview

This pull request (hopefully) fixes an issue that seems to prevent the kernel from putting the MCU to sleep. The issue seems to be from the kernel work counter.

While running the following user space app, it seems that the kernel does not sleep the MCU after the process's last yield system call.

char hello[] = "Hello World!\r\n";
char run[] = "system run\r\n";
char texte[] = "texte\r\n";

static void nop(
  int a __attribute__((unused)),
  int b __attribute__((unused)),
  int c __attribute__((unused)),
  void* d __attribute__((unused))) {}


int main(void) {
  putnstr_async(hello, sizeof(hello), nop, NULL);
  putnstr_async(run, sizeof(run), nop, NULL);
  putnstr_async(texte, sizeof(texte), nop, NULL);
  return 0;
}

I did some research and found out that the issue pops up only when there are several subscribes for the same callback (driver_id, subscribe_number). In the kernel:

1. I found that when a callback is overwritten:
   a. the kernel work is incremented
   b. the previous callback is removed, but the kernel work is not decremented accordingly

   This prevents sends the scheduler into an infinite loop.

2. I also noticed that enqueue_task increments the kernel work regardless of whether a callback is scheduled or not. We also experienced an interesting issue when trying to implement a real-time external interrupt counter. It seems that if the kernel drops callbacks, it starts having a strange behavior, the apps jam. I think it might be related to the kernel work. We still need to do some more research.

Testing Strategy

TODO or Help Wanted

N/A

Documentation Updated

• Updated the relevant files in /docs, or no updates are required.

Formatting

• Ran make prepush.

[hudson-ayers]

1. I found that when a callback is overwritten:
   a. the kernel work is incremented
   b. the previous callback is removed, but the kernel work is not decremented accordingly
   This prevents sends the scheduler into an infinite loop.

Good catch!

2. I also noticed that enqueue_task increments the kernel work regardless of whether a callback is scheduled or not. We also experienced an interesting issue when trying to implement a real-time external interrupt counter. It seems that if the kernel drops callbacks, it starts having a strange behavior, the apps jam. I think it might be related to the kernel work. We still need to do some more research.

Another good catch! It also seems incorrect that the kernel work is incremented even in the case that enqueue_task() fails, I think we should fix that in this PR as well.

[alexandruradovici]

1. I found that when a callback is overwritten:
   a. the kernel work is incremented
   b. the previous callback is removed, but the kernel work is not decremented accordingly
   This prevents sends the scheduler into an infinite loop.

Good catch!

1. I also noticed that enqueue_task increments the kernel work regardless of whether a callback is scheduled or not. We also experienced an interesting issue when trying to implement a real-time external interrupt counter. It seems that if the kernel drops callbacks, it starts having a strange behavior, the apps jam. I think it might be related to the kernel work. We still need to do some more research.

Another good catch! It also seems incorrect that the kernel work is incremented even in the case that enqueue_task() fails, I think we should fix that in this PR as well.

I think I fixed this already by moving the increment_work function call. Am I missing something else here?

[hudson-ayers]

I think I fixed this already by moving the increment_work function call. Am I missing something else here?

Oh, I must have been looking at a single commit or something. You did fix it.

[bradjc]

bors r+

[bors]

Build succeeded:

• ci-build (macos-latest)
• ci-build (ubuntu-latest)
• ci-format (macos-latest)
• ci-format (ubuntu-latest)
• ci-qemu
• ci-tests (macos-latest)
• ci-tests (ubuntu-latest)