While I like getting these emails, any reason why I've received 3 different copies today, and at that they all seem to have different data in them?

Problem Statement: Currently, there is no way to know if a driver fails initialization. Problem Description: Zephyr currently does not provide a way to check programmatically whether a device can be

NEW within last 24 hours: - https://gerrit.zephyrproject.org/r/1230 : test: kernel/test_timer/nanokernel increase timeout. - https://gerrit.zephyrproject.org/r/1251 : sensor: make runtime

NEW within last 24 hours: - https://gerrit.zephyrproject.org/r/1227 : doc: Editing notices page to be more concise and relevant to Zephyr - https://gerrit.zephyrproject.org/r/1228 : sensor:

Hi, We tagged v1.2.0 and merge window for the next release is now open. Changes since v1.2.0-rc1 are below: Alexandre d'Alton (2): arc: implement stack checking arc: remove unecessary

NEW within last 24 hours: UPDATED within last 24 hours: - https://gerrit.zephyrproject.org/r/1072 : drivers/nble: Implement notification response - https://gerrit.zephyrproject.org/r/1208 :

NEW within last 24 hours: - https://gerrit.zephyrproject.org/r/1213 : test: ignore - https://gerrit.zephyrproject.org/r/1212 : Zephyr 1.2.0 - https://gerrit.zephyrproject.org/r/1211 :

NEW within last 24 hours: - https://gerrit.zephyrproject.org/r/1199 : drivers/nble: Add support for attr iteration functions - https://gerrit.zephyrproject.org/r/1195 :

Hi, We tagged release candidate 2 and planning to release 1.2.0 end of the day Friday. There are already a few bug fixes on top of rc2 that will be in the final release. Below is the log since

Andrew, Eval is widely used in many projects, e.g. yocto. Its safety depends on what area you apply it. To build up a public server which allow any user input, maybe it is unsafe. For testcase

Thanks for doing this. I believe test_sema also has this problem, in addition to test_fifo/test_lifo. -- Andrew Boie Staff Engineer - EOS Zephyr Intel Open Source Technology Center

Thanks. Looks like we have everything in place then. Cheers, -- Maciek Borzecki

I have pushed it to gerrit: https://gerrit.zephyrproject.org/r/#/c/1142/ https://gerrit.zephyrproject.org/r/#/c/1143/

also look at include/misc/stack.h for Stack usage analysis helpers Anas

Can you point me to the patch? I can't see it in the original email in the thread (save my email doing funky stuff :) Thanks

That part is already in the kernel: CONFIG_INIT_STACKS fills the stacks with 0xaa when threads are initialized.

Hey Yannis,

<maciek.borzecki(a)gmail.com> wrote: Now that I've seen the patch it got me thinking. What if we added an opt-in debug code for fiber/tasks that helped to measure stack usage? This could be something

I briefly considered this approach but after doing some reading concluded it was unsafe. http://nedbatchelder.com/blog/201206/eval_really_is_dangerous.html Andrew

Hi, <giannis.damigos(a)gmail.com> wrote: You can post the patch and add me for review. From what I've seen, there's ~10 tests that fail under sanitycheck with SRAM overflow from hundreds of bytes, to