Shell bug(?)

[Joel Sherrill]

On Sat, Nov 2, 2019, 12:03 AM <mbenson at windhoverlabs.com> wrote:

> That’s kind of my point.  The low priority shell task is working
> perfectly.  The higher priority task is pended by time.  I do have some
> sleep functions in the driver code but they are short sleeps.  They
> shouldn’t just pens indefinitely until a run any random command in the
> shell.  Unless I’m not understanding the priority model correctly and have
> inadvertently inverted my prioritities.
>

The shell has to be the executing task to run the command and produce
output. It is only running when nothing else is running in your system. But
the reports will never catch another task ready because if it was ready,
the scheduler would pick it to be the executing thread.

It looks and sounds odd but it is exactly what is supposed to happen. It's
lowest priority and produces output when it runs.


> Sent from my iPhone
>
> On Nov 1, 2019, at 14:40, Joel Sherrill <joel at rtems.org> wrote:
>
>
>
> 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/20191102/d1a8099f/attachment.html>