Shell bug(?)

Sat Nov 2 05:03:34 UTC 2019

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.

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/214142f2/attachment-0001.html>