nanosleep blocks inifinity (internal rtems deathlock?) even CPU is in idle Task

[Joel Sherrill]

On 11/16/2012 2:42 AM, Sebastian Huber wrote:
> On 11/16/2012 08:48 AM, Matthias Goldhoorn wrote:
>> On 15.11.2012 19:45, Chris Johns wrote:
>>> Matthias Goldhoorn wrote:
>>>> On 15.11.2012 14:52, Sebastian Huber wrote:
>>>>> On 11/15/2012 01:26 PM, Matthias Goldhoorn wrote:
>>>>>> On 15.11.2012 11:52, Sebastian Huber wrote:
>>>>>>> On 11/15/2012 10:44 AM, Matthias Goldhoorn wrote:
>>>>>>>
>>>>>> Yeah it's both defined.
>>>>>> The nanosleep sometimes (mostly) works.
>>>>>> Only if some interrupts during the sleep i got this non-awaking
>>>>>> behavior it seems strange.
>>> Which interrupts are happening that cause the sleep to not wake up, ie the
>>> timer to not fire ?
>>>
>>> What concerns me with the 'rtems_posix_threads' list you posted is no IDLE
>>> task which leads me to think any classic threads are not listed. Is there
>>> something else loading the CPU ? Maybe a classic thread created by the BSP.
>>>
>>> Chris
>> First of all:
>>
>> Questions to _Watchdog_Ticks_since_boot
>> the _Watchdog_Ticks_since_boot is incrementing after watch interrupt that
>> results of the br to rtems_clock_tick()
> The _Watchdog_Ticks_since_boot value is incremented with each call to
> rtems_clock_tick().  The rtems_clock_tick() is called normally by the clock
> driver interrupt handler.
>
>>
>> Question regarding to an simple example or my current setup:
>> i attached the RTEMS initialization classes for my base-system. The whole rest
>> is rock standard, but i don't have an out of the box bootstrap or simple
>> example because i glued rock and rtems together.
>> I currently working by side of this problem to integrate the whole RTEMs think
>> into ROCK itself as an clean bootstrap. If i finished this (hopefully in the
>> next days) i could send you the link howto bootstrap this.
>> This might then also be interesting for RTEMs users that to Robot control in
>> general. But i got offtopic...
> If you don't know the exact stack requirements, then it my help to use the
> stack checker (for <rtems/confdefs.h>).
>
> #define CONFIGURE_STACK_CHECKER_ENABLED
>
> You can also use the "stackuse" RTEMS shell command.
>
>> Questions to another bsp:
>> Not yet
>>
>> Regarding to the missing idle thread:
>> I think this idle function is only directly called from the scheduler and not
>> an "real" rtems thread or thread?!
> The idle thread is a normal thread.  The only restriction is that it must not
> call a potentially blocking function.
RTEMS ALWAYS operates on a set of threads. There is no special magic thread.
The scheduler will always execute the highest priority ready thread although
since preemption may be disabled, there are situations where this is not
the case.

The problem is most likely NOT what the subject and all the discussion
and suggestions have been addressing.  We all went for the "old school"
reasons people don't come back from sleeping which is focused on
not configuring the clock driver and BSP issues. Incorrectly configuring
  a system to accidentally leave out the clock driver should be much
harder to accidentally do now. And this is the pc386 BSP so VERY
unlikely something is wrong with the BSP.

Chris latched onto a key piece of information:

**** THERE ARE POSIX THREADS ****

Matthias is porting code to RTEMS which is used to running in Linux.
The first challenge this presents is that the default pthread attributes
are different for RTEMS and Linux. More generally, POSIX does not
define the default set of pthread attributes.   Even experienced RTEMS
developers get bit by this one.

Second, if Matthias has mixed Classic API and POSIX threads, there is
a chance that he has fallen into another pit. In the Classic API, 1 is
the highest thread priority. In the POSIX threads API, 1 is the lowest
priority.

I suggest he look into this. And pop onto #rtems on IRC.freenode.net
so we can run this down quicker.

I suspect a few minutes of giving advice on what to look for
interactively will solve this.

First things to check:

+ What are the attributes used on the call(s) to pthread_create()?

+ Second (and likely easier for RTEMS developers), we can break on
the call to nanosleep() and quickly spot the priority and preemption
settings of that thread.

>> To the point no source lines available:
>> I dont know why GDB could not figure out the code inside of the clock interrupt
>> function for everything expect this function i have code lines...
> Particular easy to use simulators are the built-in GDB simulators for the
> "sis", "psim", or "jmr3904" BSPs.
>


-- 
Joel Sherrill, Ph.D.             Director of Research & Development
joel.sherrill at OARcorp.com        On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
Support Available                (256) 722-9985