Shell bug(?)

[Joel Sherrill]

On Fri, Nov 1, 2019 at 12:33 PM Gedare Bloom <gedare at rtems.org> wrote:

>
> On Fri, Nov 1, 2019 at 10:52 AM Mathew Benson <mbenson at windhoverlabs.com>
> wrote:
>
>> So no matter what priority the shell task is initialized as, it preempts
>> all other tasks?
>>
>> No.
>

But an odd artifact of looking at the status of threads in the shell is
that the shell thread has to be **EXECUTING** to do that. Since this is a
single core system, it means all other threads are either blocked or ready
and have a lower priority.


>
> With low priority (250) under the default scheduling (fixed priority
> round-robin), the shell would only run when higher priority tasks are
> blocked. This is typical, and the shell will be preempted when higher
> priority tasks are made ready. The "TIME" state indicates your driver task
> self-suspended on a timer, e.g., nanosleep or wake_after type call. It
> should preempt the shell after the timeout. If it isn't then something is
> going strangely.
>

Yep.

>
> As Joel hinted, if you're using POSIX threads, then 250 is higher priority
> than 235.
>

But I don't know how this is reported by the command he is using. I recall
one command to list Classic API tasks and one for POSIX threads. I don't
recall one which lists all but I could be wrong.

--joel


>
> Gedare
>
>
>> On Fri, Nov 1, 2019 at 11:36 AM Joel Sherrill <joel at rtems.org> wrote:
>>
>>>
>>>
>>> On Fri, Nov 1, 2019, 11:24 AM Mathew Benson <mbenson at windhoverlabs.com>
>>> wrote:
>>>
>>>> My shell task is set to priority 250.  I have another task that I've
>>>> set to a priority of 235.  When I have the shell in the build, that
>>>> priority 235 task appears to pend indefinitely with the shell reporting
>>>> state = "TIME" and I don't know where it would be pending.  The task is
>>>> accessing NOR drivers.  But just by running the shell command, releases
>>>> that priority 235 task.  In fact, any command releases it.  Whether its a
>>>> valid command or not.  But if I remove the shell from the build, everything
>>>> is fine.  The task doesn't pend.  It executes as it should.  Did I miss
>>>> something in the documentation regarding integration of the shell?  Is
>>>> there something we are or are not supposed to do when the shell is
>>>> integrated?
>>>>
>>>
>>> I'm off today and this is from my phone.
>>>
>>> TIME should indicate that the task is sleeping. Assuming these are not
>>> POSIX thread priority The priority 235 task has to be blocked or the shell
>>> task won't run at all. So anytime your shell task runs, the others should
>>> be blocked.
>>>
>>> --joel
>>>
>>>>
>>>> --
>>>> *Mathew Benson*
>>>> CEO | Chief Engineer
>>>> Windhover Labs, LLC
>>>> 832-640-4018
>>>>
>>>>
>>>> www.windhoverlabs.com
>>>>
>>>> _______________________________________________
>>>> users mailing list
>>>> users at rtems.org
>>>> http://lists.rtems.org/mailman/listinfo/users
>>>
>>>
>>
>> --
>> *Mathew Benson*
>> CEO | Chief Engineer
>> Windhover Labs, LLC
>> 832-640-4018
>>
>>
>> www.windhoverlabs.com
>>
>> _______________________________________________
>> users mailing list
>> users at rtems.org
>> http://lists.rtems.org/mailman/listinfo/users
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/users/attachments/20191101/e790834c/attachment.html>