Topics

Sanity check and test cases


Yannis Damigos
 

Hi all,

a quick question regarding sanity check and test cases.
I modified the test-fifo test case reducing the amount of memory statically allocated for fibers' stack.
This permits the test_nano to compile on boards like nucleo-f103rb and arduino 101 sss.

I run the sanitycheck script:

./scripts/sanitycheck --inline-logs --all -T ./tests/kernel/test_fifo/

and all the tests passes:

Cleaning output directory /home/xekarfwtos/projects/zephyr/sanity-out
Selecting all possible platforms per test case
Building testcase defconfigs...
25 tests selected, 3 tests discarded due to filters
total complete: 25/ 25 failed: 0
25 of 25 tests passed with 0 warnings in 95 seconds


Is it safe to submit the patch to gerrit or should I first test it on real hardware (I do not own any of the platforms)?

best regards,
Yannis


Maciek Borzecki <maciek.borzecki@...>
 

Hi,

On Wed, Mar 30, 2016 at 4:21 PM, Yannis Damigos
<giannis.damigos(a)gmail.com> wrote:
Hi all,

a quick question regarding sanity check and test cases.
I modified the test-fifo test case reducing the amount of memory statically allocated for fibers' stack.
This permits the test_nano to compile on boards like nucleo-f103rb and arduino 101 sss.

I run the sanitycheck script:

./scripts/sanitycheck --inline-logs --all -T ./tests/kernel/test_fifo/

and all the tests passes:

Cleaning output directory /home/xekarfwtos/projects/zephyr/sanity-out
Selecting all possible platforms per test case
Building testcase defconfigs...
25 tests selected, 3 tests discarded due to filters
total complete: 25/ 25 failed: 0
25 of 25 tests passed with 0 warnings in 95 seconds


Is it safe to submit the patch to gerrit or should I first test it on real hardware (I do not own any of the platforms)?
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 couple of kBs. My idea was to go through the
failing ones and see if it's possible trim the amount of memory
required in the manner similar to what was done to the latency
benchmarks. If that's not possible, the test will get disabled for
this particular target.

Cheers,
--
Maciek Borzecki


Maciek Borzecki <maciek.borzecki@...>
 

On Wed, Mar 30, 2016 at 4:47 PM, Maciek Borzecki
<maciek.borzecki(a)gmail.com> wrote:
Hi,

On Wed, Mar 30, 2016 at 4:21 PM, Yannis Damigos
<giannis.damigos(a)gmail.com> wrote:
Hi all,

a quick question regarding sanity check and test cases.
I modified the test-fifo test case reducing the amount of memory statically allocated for fibers' stack.
This permits the test_nano to compile on boards like nucleo-f103rb and arduino 101 sss.

I run the sanitycheck script:

./scripts/sanitycheck --inline-logs --all -T ./tests/kernel/test_fifo/

and all the tests passes:

Cleaning output directory /home/xekarfwtos/projects/zephyr/sanity-out
Selecting all possible platforms per test case
Building testcase defconfigs...
25 tests selected, 3 tests discarded due to filters
total complete: 25/ 25 failed: 0
25 of 25 tests passed with 0 warnings in 95 seconds


Is it safe to submit the patch to gerrit or should I first test it on real hardware (I do not own any of the platforms)?
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 couple of kBs. My idea was to go through the
failing ones and see if it's possible trim the amount of memory
required in the manner similar to what was done to the latency
benchmarks. If that's not possible, the test will get disabled for
this particular target.
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 really simple, like initializing the stack
area with some known pattern (ex. '.') and once the fiber/task is
finished, scan the stack to find the low point and print it out to the
console. Do you guys think this is reasonable?

Cheers,
--
Maciek Borzecki


Kalowsky, Daniel <daniel.kalowsky@...>
 

Hey Yannis,

-----Original Message-----
From: Yannis Damigos [mailto:giannis.damigos(a)gmail.com]
Sent: Wednesday, March 30, 2016 7:22 AM
To: devel(a)lists.zephyrproject.org
Subject: [devel] Sanity check and test cases

Hi all,

a quick question regarding sanity check and test cases.
I modified the test-fifo test case reducing the amount of memory statically
allocated for fibers' stack.
This permits the test_nano to compile on boards like nucleo-f103rb and
arduino 101 sss.

I run the sanitycheck script:

./scripts/sanitycheck --inline-logs --all -T ./tests/kernel/test_fifo/

and all the tests passes:

Cleaning output directory /home/xekarfwtos/projects/zephyr/sanity-out
Selecting all possible platforms per test case
Building testcase defconfigs...
25 tests selected, 3 tests discarded due to filters
total complete: 25/ 25 failed: 0
25 of 25 tests passed with 0 warnings in 95 seconds


Is it safe to submit the patch to gerrit or should I first test it on real hardware
(I do not own any of the platforms)?
Since you've already submitted the patch, and that should be good enough. I've added Inaky to the thread who can more than likely run this through a series of hardware tests pretty quickly.


Benjamin Walsh <benjamin.walsh@...>
 

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 couple of kBs. My idea was to go through the
failing ones and see if it's possible trim the amount of memory
required in the manner similar to what was done to the latency
benchmarks. If that's not possible, the test will get disabled for
this particular target.
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 really simple, like initializing the stack
area with some known pattern (ex. '.') and once the fiber/task is
That part is already in the kernel: CONFIG_INIT_STACKS fills the stacks
with 0xaa when threads are initialized.

finished, scan the stack to find the low point and print it out to the
console. Do you guys think this is reasonable?


Perez-Gonzalez, Inaky <inaky.perez-gonzalez@...>
 

On Wed, 2016-03-30 at 15:38 +0000, Kalowsky, Daniel wrote:
Hey Yannis,

 

Is it safe to submit the patch to gerrit or should I first test it
on real hardware
(I do not own any of the platforms)?
Since you've already submitted the patch, and that should be good
enough.  I've added Inaky to the thread who can more than likely run
this through a series of hardware tests pretty quickly.
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


Nashif, Anas
 

On 30/03/2016, 11:52, "Benjamin Walsh" <benjamin.walsh(a)windriver.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 couple of kBs. My idea was to go through the
failing ones and see if it's possible trim the amount of memory
required in the manner similar to what was done to the latency
benchmarks. If that's not possible, the test will get disabled for
this particular target.
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 really simple, like initializing the stack
area with some known pattern (ex. '.') and once the fiber/task is
That part is already in the kernel: CONFIG_INIT_STACKS fills the stacks
with 0xaa when threads are initialized.
also look at

include/misc/stack.h

for Stack usage analysis helpers

Anas


finished, scan the stack to find the low point and print it out to the
console. Do you guys think this is reasonable?


Yannis Damigos
 

On 03/30/2016 07:17 PM, Perez-Gonzalez, Inaky wrote:
On Wed, 2016-03-30 at 15:38 +0000, Kalowsky, Daniel wrote:
Hey Yannis,



Is it safe to submit the patch to gerrit or should I first test it
on real hardware
(I do not own any of the platforms)?
Since you've already submitted the patch, and that should be good
enough. I've added Inaky to the thread who can more than likely run
this through a series of hardware tests pretty quickly.
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
I have pushed it to gerrit:
https://gerrit.zephyrproject.org/r/#/c/1142/
https://gerrit.zephyrproject.org/r/#/c/1143/


Maciek Borzecki <maciek.borzecki@...>
 

On Wed, Mar 30, 2016 at 6:33 PM, Nashif, Anas <anas.nashif(a)intel.com> wrote:





On 30/03/2016, 11:52, "Benjamin Walsh" <benjamin.walsh(a)windriver.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 couple of kBs. My idea was to go through the
failing ones and see if it's possible trim the amount of memory
required in the manner similar to what was done to the latency
benchmarks. If that's not possible, the test will get disabled for
this particular target.
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 really simple, like initializing the stack
area with some known pattern (ex. '.') and once the fiber/task is
That part is already in the kernel: CONFIG_INIT_STACKS fills the stacks
with 0xaa when threads are initialized.
also look at

include/misc/stack.h

for Stack usage analysis helpers
Thanks. Looks like we have everything in place then.

Cheers,
--
Maciek Borzecki


Boie, Andrew P
 

On Wed, 2016-03-30 at 19:45 +0300, Yannis Damigos wrote:

I have pushed it to gerrit:
https://gerrit.zephyrproject.org/r/#/c/1142/
https://gerrit.zephyrproject.org/r/#/c/1143/
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