Re: Shell bug(?)
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 wrote: > > > On Sat, Nov 2, 2019, 12:03 AM 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 wrote: >> >> >> >> On Fri, Nov 1, 2019 at 12:33 PM Gedare Bloom wrote: >> >>> >>> On Fri, Nov 1, 2019 at 10:52 AM Mathew Benson >>> 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 wrote: > > > On Fri, Nov 1, 2019, 11:24 AM Mathew Benson > 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@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@rtems.org http://lists.rtems.org/mailman/listinfo/users >>> >>> ___ users mailing list users@rtems.org http://lists.rtems.org/mailman/listinfo/users
Re: Shell bug(?)
On Sat, Nov 2, 2019, 12:03 AM 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 wrote: > > > > On Fri, Nov 1, 2019 at 12:33 PM Gedare Bloom wrote: > >> >> On Fri, Nov 1, 2019 at 10:52 AM Mathew Benson >> 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 wrote: >>> On Fri, Nov 1, 2019, 11:24 AM Mathew Benson 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@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@rtems.org >>> http://lists.rtems.org/mailman/listinfo/users >> >> ___ users mailing list users@rtems.org http://lists.rtems.org/mailman/listinfo/users
Re: Shell bug(?)
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 wrote: > > > >> On Fri, Nov 1, 2019 at 12:33 PM Gedare Bloom wrote: >> >>> On Fri, Nov 1, 2019 at 10:52 AM Mathew Benson >>> 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 wrote: > On Fri, Nov 1, 2019, 11:24 AM Mathew Benson > 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@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@rtems.org >>> http://lists.rtems.org/mailman/listinfo/users ___ users mailing list users@rtems.org http://lists.rtems.org/mailman/listinfo/users
Re: Shell bug(?)
On Fri, Nov 1, 2019 at 12:33 PM Gedare Bloom wrote: > > On Fri, Nov 1, 2019 at 10:52 AM Mathew Benson > 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 wrote: >> >>> >>> >>> On Fri, Nov 1, 2019, 11:24 AM Mathew Benson >>> 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@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@rtems.org >> http://lists.rtems.org/mailman/listinfo/users > > ___ users mailing list users@rtems.org http://lists.rtems.org/mailman/listinfo/users
Re: Shell bug(?)
On Fri, Nov 1, 2019 at 10:52 AM Mathew Benson wrote: > So no matter what priority the shell task is initialized as, it preempts > all other tasks? > > No. 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. As Joel hinted, if you're using POSIX threads, then 250 is higher priority than 235. Gedare > On Fri, Nov 1, 2019 at 11:36 AM Joel Sherrill wrote: > >> >> >> On Fri, Nov 1, 2019, 11:24 AM Mathew Benson >> 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@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@rtems.org > http://lists.rtems.org/mailman/listinfo/users ___ users mailing list users@rtems.org http://lists.rtems.org/mailman/listinfo/users
Re: Shell bug(?)
So no matter what priority the shell task is initialized as, it preempts all other tasks? On Fri, Nov 1, 2019 at 11:36 AM Joel Sherrill wrote: > > > On Fri, Nov 1, 2019, 11:24 AM Mathew Benson > 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@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@rtems.org http://lists.rtems.org/mailman/listinfo/users
Re: Shell bug(?)
On Fri, Nov 1, 2019, 11:24 AM Mathew Benson 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@rtems.org > http://lists.rtems.org/mailman/listinfo/users ___ users mailing list users@rtems.org http://lists.rtems.org/mailman/listinfo/users
Shell bug(?)
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? -- *Mathew Benson* CEO | Chief Engineer Windhover Labs, LLC 832-640-4018 www.windhoverlabs.com ___ users mailing list users@rtems.org http://lists.rtems.org/mailman/listinfo/users
