[PATCH] sptests/spsem04: new test case for PIP starvation

Gedare Bloom gedare at rtems.org
Thu Dec 21 16:01:56 UTC 2017


On Thu, Dec 21, 2017 at 3:52 AM, Sebastian Huber
<sebastian.huber at embedded-brains.de> wrote:
> On 20/12/17 17:02, Gedare Bloom wrote:
>>
>> On Wed, Dec 20, 2017 at 10:58 AM, Gedare Bloom <gedare at rtems.org> wrote:
>>>
>>> On Wed, Dec 20, 2017 at 1:02 AM, Sebastian Huber
>>> <sebastian.huber at embedded-brains.de> wrote:
>>>>
>>>> I think this is already covered by test_inherit_nested_vertical() in
>>>> spmutex01.
>>>>
>>> Thanks for the pointer, you're correct. I need this kind of test for
>>> some release/maintenance to fix PIP in 4.10 (and checking it on 4.11).
>>>
>> FYI: I have this spsem04 on 4.10 and 4.11, and it demonstrates the
>> broken PIP we know and love.
>>
>>> I may try to unpack the parts of spmutex01 that are backward-compatible.
>>>
>> If I can't easily port backward spmutex01, I may like to add these
>> tests to the release branches if acceptable.
>>
>> I intend to implement some solution similar to the one you suggested
>> in https://devel.rtems.org/ticket/2412
>
>
> I am not opposed to duplicated tests in general, but we should keep a bit
> the test run time in mind. Individual test programs require a boot cycle.
>
Understood. There is a tradeoff made though, by lumping more tests in
a single test application the test complexity increases, and test
failures become slightly harder to investigate. I guess it makes sense
to have these combined tests like spmutex01 after the
components-under-test have been fully developed, but it does make
debugging an individual component more difficult.

> I don't care about the tests in 4.10 and 4.11 that much.
>
>
> --
> Sebastian Huber, embedded brains GmbH
>
> Address : Dornierstr. 4, D-82178 Puchheim, Germany
> Phone   : +49 89 189 47 41-16
> Fax     : +49 89 189 47 41-09
> E-Mail  : sebastian.huber at embedded-brains.de
> PGP     : Public key available on request.
>
> Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
>



More information about the devel mailing list