Shell bug(?)

[Gedare Bloom]

The question is whether your driver is actually pending indefinitely as you
think, or just the shell is running during the small sleeps.

On Sat, Nov 2, 2019, 9:06 AM Joel Sherrill <joel at rtems.org> wrote:

>
>
> 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/2759403f/attachment-0001.html>