Chat
Is there a Slack or Discord channel to discuss RTEMS? I don't want to flood everybody's inbox with emails. I want to port RTEMS to the Xilinx Zynq Ultrascale+ R5. I've taken the RTEMS training, but that was a couple years ago. I think I'll be fine once I can just get through the build system and can focus on just code, but the build system seems very foreign to me. There still seems to be either fragments of an old build system or just files that don't seem to serve any purpose. It would appear that "/spec/build/bsps/arm/xilinx-zynqmp" is where my build set definition begins, but then what is "/bsps/arm/xilinx-zynqmp/config" for? Also, everything still seems to be organized by architecture, the board. How do you want the Zynq Ultrascale organized? It has multiple architectures on the same SoC. Should it be under "arm" or "aarch64"? Is it possible to build two kernels in a single step, or should it contain an entry in "arm" for the R5 and an entry in "aarch64" for the A53? -- *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: RTEMS on the Zynq Ultrascale+ R5
Yes. Side processor only. I wasn't sure how to ask that. I thought it would. Thanks. I figured I could write drivers to use either shared memory or Xilinx's mailbox IP as a serial device for inter processor IO. Does RTEMS already support OpenAMP? I'm running Linux on the A53 side. There are no mailbox drivers in the Linux mainline, but OpenAMP is supported. I'm hoping that if I can implement a serial device using OpenAMP / LibMetal, add it to the Linux device tree, then the other end of the device will just magically appear on the Linux side. For now, I'm using a dedicated UART for the console. I might go virtual later. On Mon, Aug 9, 2021 at 1:27 PM Joel Sherrill wrote: > > > On Mon, Aug 9, 2021 at 12:53 PM Mathew Benson > wrote: > >> I might take that on. When I took the RTEMS training a couple years ago, >> the repository was still in the middle of a restructuring and build system >> upgrade so it was a little confusing. I just looked at it and the new >> documentation and it looks a lot less daunting. >> > > That's good feedback. > > Hopefully this is mostly a BSP with possibly a few tweaks to the ARM > specific code if the CPU model has differences not yet accounted for. > > If used as a side processor only, it might not have many peripheral > drivers which would make things simpler. The timer for the clock and > interrupt controller are quite likely already supported. > > One thing that does need to be addressed in the BSP and software stack is > how to communicate with it as a side processor. There are standard open > source packages out there for that and whatever one is used here would need > to be ported. > > I'm guessing here but the console may be virtual through that > communications bridge to the main cores. > > --joel > >> >> >> On Mon, Aug 9, 2021 at 12:35 PM Joel Sherrill wrote: >> >>> On Mon, Aug 9, 2021 at 11:49 AM Gedare Bloom wrote: >>> > >>> > Hi Mathew, >>> > >>> > Not that I'm aware of, so probably not. There is ongoing work that is >>> > improving the Zynq Ultrascale+ support, and there is also work ongoing >>> > for the Xilinx Versal, which shares some features including R5F >>> > co-processors. OAR has been pushing on Ultrascale, but I couldn't tell >>> > you what their scope is, and I have been working with Chris Johns on >>> > the Versal but the R5F is not yet in scope for me. >>> >>> Gedare's right. OAR did the aarch64 bit port but we haven't touched the >>> R5 yet. Everytime someone (you?) ask, I always think of the R52 FVP and >>> tms570 BSPs but those aren't what you need. >>> >>> This is certainly something we'd like to see for RTEMS. It just needs a >>> sponsor. :) >>> >>> --joel >>> > >>> > Gedare >>> > >>> > On Sat, Aug 7, 2021 at 2:22 PM Mathew Benson < >>> mben...@windhoverlabs.com> wrote: >>> > > >>> > > Has anybody started or completed porting RTEMS to the R5? >>> > > >>> > > Sent from my iPad >>> > > ___ >>> > > 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 >>> >> >> >> -- >> *Mathew Benson* >> CEO | Chief Engineer >> Windhover Labs, LLC >> 832-640-4018 >> >> >> www.windhoverlabs.com >> >> -- *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: RTEMS on the Zynq Ultrascale+ R5
I might take that on. When I took the RTEMS training a couple years ago, the repository was still in the middle of a restructuring and build system upgrade so it was a little confusing. I just looked at it and the new documentation and it looks a lot less daunting. On Mon, Aug 9, 2021 at 12:35 PM Joel Sherrill wrote: > On Mon, Aug 9, 2021 at 11:49 AM Gedare Bloom wrote: > > > > Hi Mathew, > > > > Not that I'm aware of, so probably not. There is ongoing work that is > > improving the Zynq Ultrascale+ support, and there is also work ongoing > > for the Xilinx Versal, which shares some features including R5F > > co-processors. OAR has been pushing on Ultrascale, but I couldn't tell > > you what their scope is, and I have been working with Chris Johns on > > the Versal but the R5F is not yet in scope for me. > > Gedare's right. OAR did the aarch64 bit port but we haven't touched the > R5 yet. Everytime someone (you?) ask, I always think of the R52 FVP and > tms570 BSPs but those aren't what you need. > > This is certainly something we'd like to see for RTEMS. It just needs a > sponsor. :) > > --joel > > > > Gedare > > > > On Sat, Aug 7, 2021 at 2:22 PM Mathew Benson > wrote: > > > > > > Has anybody started or completed porting RTEMS to the R5? > > > > > > Sent from my iPad > > > ___ > > > 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 > -- *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
RTEMS on the Zynq Ultrascale+ R5
Has anybody started or completed porting RTEMS to the R5? Sent from my iPad ___ users mailing list users@rtems.org http://lists.rtems.org/mailman/listinfo/users
Microblaze
The website states there is no Microblaze support. Is that still true? Just checking. Sent from my iPad ___ 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
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
Re: shell output
"SHED" = scheduler_name, but that traces back to:
name.name_u32 = _Thread_Scheduler_get_home( rtems_thread )->name;
_Objects_Name_to_string(
name,
false,
canonical_task->scheduler_name,
sizeof( canonical_task->scheduler_name )
);
Shelve that one until later...
"STATE" = state. That traces back to rtems_monitor_dump_state()... which
eventually traces back to:
static const rtems_assoc_32_pair state_pairs[] = {
{ STATES_WAITING_FOR_MUTEX, "MTX" },
{ STATES_WAITING_FOR_SEMAPHORE, "SEM" },
{ STATES_WAITING_FOR_EVENT, "EV" },
{ STATES_WAITING_FOR_SYSTEM_EVENT, "SYSEV" },
{ STATES_WAITING_FOR_MESSAGE,"MSG" },
{ STATES_WAITING_FOR_CONDITION_VARIABLE, "CV" },
{ STATES_WAITING_FOR_FUTEX, "FTX" },
{ STATES_WAITING_FOR_BSD_WAKEUP, "WK" },
{ STATES_WAITING_FOR_TIME, "TIME" },
{ STATES_WAITING_FOR_PERIOD, "PER" },
{ STATES_WAITING_FOR_SIGNAL, "SIG" },
{ STATES_WAITING_FOR_BARRIER,"BAR" },
{ STATES_WAITING_FOR_RWLOCK, "RW" },
{ STATES_WAITING_FOR_JOIN_AT_EXIT, "JATX" },
{ STATES_WAITING_FOR_JOIN, "JOIN" },
{ STATES_SUSPENDED, "SUSP" },
{ STATES_WAITING_FOR_SEGMENT,"SEG" },
{ STATES_LIFE_IS_CHANGING, "LIFE" },
{ STATES_DEBUGGER, "DBG" },
{ STATES_INTERRUPTIBLE_BY_SIGNAL,"IS" },
{ STATES_WAITING_FOR_RPC_REPLY, "RPC" },
{ STATES_ZOMBIE, "ZOMBI" },
{ STATES_DORMANT,"DORM" }
modes traces t o rtems_monitor_dump_modes(), which eventually traces to:
static const rtems_assoc_t rtems_monitor_modes_assoc[] = {
{ "nP", RTEMS_NO_PREEMPT, 0 },
{ "T", RTEMS_TIMESLICE, 0 },
{ "nA", RTEMS_NO_ASR, 0 },
{ 0, 0, 0 },
};
On Fri, Nov 1, 2019 at 11:07 AM Mathew Benson
wrote:
> The task command doesn't appear to be defined there. I found the header
> in libmisc/monitor/mon-task.c:rtems_monitor_task_dump_header(). It gets a
> little buried in function callbacks from there. I'm trying to trace it
> back now, but I recommend the documentation be improved to include what the
> output actually means.
>
> On Fri, Nov 1, 2019 at 9:50 AM Jonathan Brandmeyer <
> jbrandme...@planetiq.com> wrote:
>
>> cpukit/libmisc/shell/ has many of the entry points for the shell
>> functions.
>>
>> On Fri, Nov 1, 2019 at 6:39 AM wrote:
>>
>>> I take it that’s a no on the documentation. Can somebody just tell me
>>> what these mean or point me where in the code it is? It’s not an easy
>>> follow.
>>>
>>> Sent from my iPhone
>>>
>>> On Oct 31, 2019, at 13:43, Mathew Benson
>>> wrote:
>>>
>>> is there any documentation that explains the actual output of the shell
>>> commands? For example, the documentation for the task command says how to
>>> run it, and gives the following sample output:
>>>
>>> SHLL [/] # task
>>> ID NAME SHED PRI STATE MODESEVENTS WAITINFO
>>> --
>>> 0a010001 UI1 UPD 254 EV P:T:nA NONE
>>> 0a010002 SHLL UPD 100 READY P:T:nA NONE
>>>
>>>
>>> But doesn't actually explain what the data in the columns mean. What do
>>> the following "STATE" values mean: EV, SIG:IS, READY, MSG, SEM, and TIME?
>>> What do the MODES mean? Same question for the "sema" command output.
>>>
>>> --
>>> *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
>>
>>
>>
>> --
>> Jonathan Brandmeyer
>> Vice President of Software Engineering
>> PlanetiQ
>>
>
>
> --
> *Mathew Benson*
> CEO | Chief Engineer
> Windhover Labs, LLC
> 832-640-4018
>
>
> www.windhoverlabs.com
>
>
--
*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 output
The task command doesn't appear to be defined there. I found the header in libmisc/monitor/mon-task.c:rtems_monitor_task_dump_header(). It gets a little buried in function callbacks from there. I'm trying to trace it back now, but I recommend the documentation be improved to include what the output actually means. On Fri, Nov 1, 2019 at 9:50 AM Jonathan Brandmeyer wrote: > cpukit/libmisc/shell/ has many of the entry points for the shell functions. > > On Fri, Nov 1, 2019 at 6:39 AM wrote: > >> I take it that’s a no on the documentation. Can somebody just tell me >> what these mean or point me where in the code it is? It’s not an easy >> follow. >> >> Sent from my iPhone >> >> On Oct 31, 2019, at 13:43, Mathew Benson >> wrote: >> >> is there any documentation that explains the actual output of the shell >> commands? For example, the documentation for the task command says how to >> run it, and gives the following sample output: >> >> SHLL [/] # task >> ID NAME SHED PRI STATE MODESEVENTS WAITINFO >> -- >> 0a010001 UI1 UPD 254 EV P:T:nA NONE >> 0a010002 SHLL UPD 100 READY P:T:nA NONE >> >> >> But doesn't actually explain what the data in the columns mean. What do >> the following "STATE" values mean: EV, SIG:IS, READY, MSG, SEM, and TIME? >> What do the MODES mean? Same question for the "sema" command output. >> >> -- >> *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 > > > > -- > Jonathan Brandmeyer > Vice President of Software Engineering > PlanetiQ > -- *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
shell output
is there any documentation that explains the actual output of the shell commands? For example, the documentation for the task command says how to run it, and gives the following sample output: SHLL [/] # task ID NAME SHED PRI STATE MODESEVENTS WAITINFO -- 0a010001 UI1 UPD 254 EV P:T:nA NONE 0a010002 SHLL UPD 100 READY P:T:nA NONE But doesn't actually explain what the data in the columns mean. What do the following "STATE" values mean: EV, SIG:IS, READY, MSG, SEM, and TIME? What do the MODES mean? Same question for the "sema" command output. -- *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: File system deadlock troubleshooting
I enabled RTEMS_RAMDISK_TRACE. That appears to be dead code in my build. Change didn't do anything. I checked the symbol table and none of those functions are in my build. The actual ram disk driver is in a different location and didn't have a trace equivalent. Is there another way to get a trace from ramdisk? On Wed, Oct 9, 2019 at 6:01 PM Chris Johns wrote: > On 10/10/19 6:23 am, Mathew Benson wrote: > > I added the tracerfs command to the shell. Not sure why that's not > already > > there. > > The command is not in the shell directory and I did not add it to the > config for > the shell. Maybe is should be. I am not sure. > > > I enabled all with "tracerfs set all". It took a while, but I did run > > into the problem. The end of the log is below. Can you see what the > kernel is > > trying to do and what its waiting on from this? It's going to be a > while, > > reading through kernel code, to understand exactly what this means. > > Thank you for this. I am travelling from tomorrow for a while. I will try > and > have a look while in transit if I can. > > Chris > -- *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: File system deadlock troubleshooting
1494 1476 1467 1448 1427 1406 1326 1292 1246 1236 1218 1199 1181 1162 1053 : not found rtems-rfs: buffer-scan: count=5, block=2270: 1 2269 2268 2267 2266 : not found All trace events immediately stop here. On Tue, Oct 8, 2019 at 9:30 AM Mathew Benson wrote: > I don't have a test case that I can post or give away, yet. I may put one > together later. > > Yes. All 4 tasks are on that same conditional wait. The condition is a > response from a block device. The test case is hammering the RAM disk. I > wrote some of the flash drivers but as far as I know, the RAM disk was used > as is so I haven't looked at the code. That conditional wait does not have > a time out so it just pends forever. > > Thanks. I'll try the RFS trace when I have time. Unfortunately, this is > late in the development cycle so I don't have ready access to the article > under test. Loading it with non production code takes time. Trying to > reproduce it on a non production environment. For now, all I have is shell > commands and manually decoding dumped memory. > > Somebody more knowledgable on the inner workings of the RTEMS kernel > expressed concern a while ago that heavy use of the RAM disk could > basically out run the kernel worker thread. I noted it but didn't ask > about the mechanics of how or why that could happen. Are requests to the > worker threads in a lossy queue? Is it possible the request is getting > dropped? > > On Mon, Oct 7, 2019 at 11:30 PM Chris Johns wrote: > >> On 8/10/19 12:53 pm, Mathew Benson wrote: >> > I'm using RTEMS 5 on a LEON3. I'm troubleshooting a failure condition >> that >> > occurs when stress test reading and writing to and from RAM disk. RAM >> disk to >> > RAM disk. When the condition is tripped, it appears that I have 4 >> tasks that >> > are pending on conditions that just never happens. >> >> Do you have a test case? >> >> > The task command shows: >> > >> > ID NAME SHED PRI STATE MODESEVENTS WAITINFO >> > >> -- >> > 0a01000c TSKA UPD 135 MTXP:T:nA NONE RFS >> > 0a01001f TSKB UPD 135 CV P:T:nA NONE bdbuf >> access >> > 0a010020 TSKC UPD 150 MTXP:T:nA NONE RFS >> > 0a010032 TSKD UPD 245 MTXP:T:nA NONE RFS >> >> It looks like TSKA, TSKC and TSKD are waiting for the RFS lock and TSKB is >> blocked in a bdbuf access. I wonder why that is blocked? >> >> The RFS hold's it lock over the bdbuf calls. >> > >> > None of my tasks appear to be failed. Nobody is pending on anything >> noticeable >> > except the 4 above. The conditional wait is a single shared resource >> so any >> > attempt to access the file system after this happens results in yet >> another >> > forever pended task. >> > >> > Digging into source code, it appears that the kernel is waiting for a >> specific >> > response from a block device, but just didn't get what its expecting. >> The next >> > thing is to determine which block device the kernel is pending on, what >> the >> > expected response is, and what the block device actually did. Can >> anybody shed >> > some light on this or recommend some debugging steps? I'm trying to >> exhaust >> > all I can do before I start manually decoding machine code. >> >> The RFS has trace support you can access via >> `rtems/rfs/rtems-rfs-trace.h`. You >> can set the trace mask in your code or you can can call >> `rtems_rfs_trace_shell_command()` with suitable arguments or hook it to an >> existing shell. There is a buffer trace flag that show the release calls >> to bdbuf .. >> >> RTEMS_RFS_TRACE_BUFFER_RELEASE >> >> There is no trace call to get or read. Maybe add a get/read trace as well. >> >> The RAM disk also has trace in the code which can be enabled by editing >> the file. >> >> Chris >> > > > -- > *Mathew Benson* > CEO | Chief Engineer > Windhover Labs, LLC > 832-640-4018 > > > www.windhoverlabs.com > > -- *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: File system deadlock troubleshooting
I don't have a test case that I can post or give away, yet. I may put one together later. Yes. All 4 tasks are on that same conditional wait. The condition is a response from a block device. The test case is hammering the RAM disk. I wrote some of the flash drivers but as far as I know, the RAM disk was used as is so I haven't looked at the code. That conditional wait does not have a time out so it just pends forever. Thanks. I'll try the RFS trace when I have time. Unfortunately, this is late in the development cycle so I don't have ready access to the article under test. Loading it with non production code takes time. Trying to reproduce it on a non production environment. For now, all I have is shell commands and manually decoding dumped memory. Somebody more knowledgable on the inner workings of the RTEMS kernel expressed concern a while ago that heavy use of the RAM disk could basically out run the kernel worker thread. I noted it but didn't ask about the mechanics of how or why that could happen. Are requests to the worker threads in a lossy queue? Is it possible the request is getting dropped? On Mon, Oct 7, 2019 at 11:30 PM Chris Johns wrote: > On 8/10/19 12:53 pm, Mathew Benson wrote: > > I'm using RTEMS 5 on a LEON3. I'm troubleshooting a failure condition > that > > occurs when stress test reading and writing to and from RAM disk. RAM > disk to > > RAM disk. When the condition is tripped, it appears that I have 4 tasks > that > > are pending on conditions that just never happens. > > Do you have a test case? > > > The task command shows: > > > > ID NAME SHED PRI STATE MODESEVENTS WAITINFO > > > -- > > 0a01000c TSKA UPD 135 MTXP:T:nA NONE RFS > > 0a01001f TSKB UPD 135 CV P:T:nA NONE bdbuf > access > > 0a010020 TSKC UPD 150 MTXP:T:nA NONE RFS > > 0a010032 TSKD UPD 245 MTXP:T:nA NONE RFS > > It looks like TSKA, TSKC and TSKD are waiting for the RFS lock and TSKB is > blocked in a bdbuf access. I wonder why that is blocked? > > The RFS hold's it lock over the bdbuf calls. > > > > None of my tasks appear to be failed. Nobody is pending on anything > noticeable > > except the 4 above. The conditional wait is a single shared resource so > any > > attempt to access the file system after this happens results in yet > another > > forever pended task. > > > > Digging into source code, it appears that the kernel is waiting for a > specific > > response from a block device, but just didn't get what its expecting. > The next > > thing is to determine which block device the kernel is pending on, what > the > > expected response is, and what the block device actually did. Can > anybody shed > > some light on this or recommend some debugging steps? I'm trying to > exhaust > > all I can do before I start manually decoding machine code. > > The RFS has trace support you can access via > `rtems/rfs/rtems-rfs-trace.h`. You > can set the trace mask in your code or you can can call > `rtems_rfs_trace_shell_command()` with suitable arguments or hook it to an > existing shell. There is a buffer trace flag that show the release calls > to bdbuf .. > > RTEMS_RFS_TRACE_BUFFER_RELEASE > > There is no trace call to get or read. Maybe add a get/read trace as well. > > The RAM disk also has trace in the code which can be enabled by editing > the file. > > Chris > -- *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
File system deadlock troubleshooting
I'm using RTEMS 5 on a LEON3. I'm troubleshooting a failure condition that occurs when stress test reading and writing to and from RAM disk. RAM disk to RAM disk. When the condition is tripped, it appears that I have 4 tasks that are pending on conditions that just never happens. The task command shows: ID NAME SHED PRI STATE MODESEVENTS WAITINFO -- 0a01000c TSKA UPD 135 MTXP:T:nA NONE RFS 0a01001f TSKB UPD 135 CV P:T:nA NONE bdbuf access 0a010020 TSKC UPD 150 MTXP:T:nA NONE RFS 0a010032 TSKD UPD 245 MTXP:T:nA NONE RFS None of my tasks appear to be failed. Nobody is pending on anything noticeable except the 4 above. The conditional wait is a single shared resource so any attempt to access the file system after this happens results in yet another forever pended task. Digging into source code, it appears that the kernel is waiting for a specific response from a block device, but just didn't get what its expecting. The next thing is to determine which block device the kernel is pending on, what the expected response is, and what the block device actually did. Can anybody shed some light on this or recommend some debugging steps? I'm trying to exhaust all I can do before I start manually decoding machine code. -- *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
RTEMS on Zynq
Could somebody point me to documentation or exchange emails with me to help me through running RTEMS on a Zedboard? I got it running in qemu (zynq) no problem. I should have everything built. I'm just struggling my way through u-boot now. -- *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: task info
Not easily. That's good to know though. Thanks. On Thu, Mar 21, 2019 at 7:23 PM Ian Caddy wrote: > Hi Matthew, > > Do you have access to the shell on a serial or telnet console? > > The RTEMS shell has a "task" command that shows the state of all the tasks > running in your system: > > MNTB [/] # task > ID NAME SHED PRI STATE MODESEVENTS WAITINFO > > -- > 0a010001 USBd UPD 200 TIME P:T:nA NONE > 0a010003 ERRM UPD 55 MSGP:T:nA NONE 22010003 > 0a010004 ADLT UPD 92 MSGP:T:nA NONE 22010006 > > Based on the wait info, you can work out what it is waiting on using the > other shell commands, such as: > > queue or sema > > MNTB [/] # queue > ID NAME ATTRIBUTES PEND MAXPEND MAXSIZE > > -- > 22010001 USBrDEFAULT030001 > 22010002 USBtDEFAULT 401 1 > 22010003 EMIQPR 0 15 32 > > In the example above, the task ERRM is waiting for a message on the queue > EMIQ. > > If you do not have access to the shell, you can try to follow through what > the shell actually does in the code, and hopefully it will provide the > information that you are looking for. > > regards, > > Ian Caddy > > > > On 22/03/2019 3:41 am, Mathew Benson wrote: > > What's the best way to determine the status of a task? Is there an API to > determine if its pending or a runnable state? Is there an API to determine > what its pending on? I'm trying to determine what some tasks stopped > executing and I can't use a debugger. Preferably, can somebody point me to > a symbol that I can peek? > > -- > *Mathew Benson* > CEO | Chief Engineer > Windhover Labs, LLC > 832-640-4018 > > > www.windhoverlabs.com > > > ___ > users mailing listusers@rtems.orghttp://lists.rtems.org/mailman/listinfo/users > > ___ > 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
task info
What's the best way to determine the status of a task? Is there an API to determine if its pending or a runnable state? Is there an API to determine what its pending on? I'm trying to determine what some tasks stopped executing and I can't use a debugger. Preferably, can somebody point me to a symbol that I can peek? -- *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: CPU utilization
I like this idea. I signed up for the mailing list. I'll try to submit something in the next few days. Thanks. On Thu, Jul 12, 2018 at 12:56 PM, Sebastian Huber < sebastian.hu...@embedded-brains.de> wrote: > - Am 12. Jul 2018 um 19:48 schrieb Mathew Benson > mathew.ben...@gmail.com: > > > I assume symbols prefixed with "_" are to be considered part of the > private > > API. What are the guidelines and legalities, if any, of bringing in > these > > private symbols into our own code? > > Functions, variables, and so on starting with an underscore "_" should > never be used by application code. If a certain functionality is not > provided by a public API in RTEMS, then a public API for this functionality > should be proposed to de...@rtems.org (or via a ticket). It should be > documented and tested. > ___ > 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: CPU utilization
I assume symbols prefixed with "_" are to be considered part of the private
API. What are the guidelines and legalities, if any, of bringing in these
private symbols into our own code?
On Thu, Jul 12, 2018 at 11:10 AM, Fabrício de Novaes Kucinskis <
fabricio.kucins...@inpe.br> wrote:
> Hi Mathew and Joel,
>
>
>
> On the past, I’ve used the following code to get individual task usage and
> monitor tasks behavior through time. It’s completely based on
> rtems_cpu_usage_report_with_plugin and I know it’s not the best way to do
> it, but worked for me .
>
>
>
> Regards,
>
>
>
> Fabrício.
>
>
>
> /**
>
> * Returns the task usage in us. If the taskId is zero, returns the time
> since boot.
>
> * Code based on ‘rtems_cpu_usage_report_with_plugin’.
>
> **/
>
> uint64_t *TasksStatusList::GetCpuUsagePerTask*(*const* rtems_id )
>
> {
>
> *if* (taskId == 0)
>
> {
>
>*struct* timespec uptime;
>
>*struct* timespec total;
>
>
>
>*rtems_clock_get_uptime*();
>
>
> *_Timespec_Subtract*(_usage_Uptime_at_last_reset,
> , );
>
>
>
>uint64_t totalCpuUsageInUs = (total.tv_sec
> * *static_cast*(100)) + (total.tv_nsec / *static_cast*<
> uint64_t>(1000));
>
>
>
>*return* totalCpuUsageInUs;
>
> }
>
> *else*
>
> {
>
>Objects_Information *ptObjInformation =
> NULL;
>
>Thread_Control
> *ptThread = NULL;
>
>Thread_CPU_usage_t timeRan;
>
>
>
>*for* (uint32_t i = 1; i <=
> OBJECTS_APIS_LAST; i++)
>
>{
>
>*if*
> (!_Objects_Information_table[i])
>
>{
>
>*continue*;
> // that’s ugly, but it works
>
>}
>
>
>
>ptObjInformation =
> _Objects_Information_table[i][1];
>
>
>
>*if* (ptObjInformation !=
> NULL)
>
>{
>
>*for* (
> uint32_t j = 1; j <= ptObjInformation->maximum; j++)
>
>{
>
>
> ptThread = *reinterpret_cast*(ptObjInformation->local_
> table[j]);
>
>
>
>
> *if* (ptThread == NULL)
>
>
> {
>
>
> *continue*; // still
> ugly, still works
>
>
> }
>
>
>
>
> // if the caller task asks for its own cpu usage, the time since the last
> context switch will not be computed
>
>
> *if* (ptThread->Object.id == taskId)
>
>
> {
>
>
> timeRan = ptThread->cpu_time_used;
>
>
>
>
> uint64_t cpuUsageInUs =
> (_Timestamp_Get_seconds() * *static_cast*(100)) +
> (_Timestamp_Get_nanoseconds() / *static_cast*(1000));
>
>
>
>
> *return* cpuUsageInUs;
>
>
> }
>
> }
>
>}
>
>}
>
>
>
>// if the rtemsId doesn’t exist...
>
>*return* 0;
>
> }
>
> }
>
>
>
> *De:* users [mailto:users-boun...@rtems.org] *Em nome de *Joel Sherrill
> *Enviada em:* quinta-feira, 12 de julho de 2018 11:37
> *Para:* Mathew Benson
> *Cc:* RTEMS
> *Assunto:* Re: CPU utilization
>
>
>
>
>
>
>
> On Tue, Jul 10, 2018 at 2:30 PM, Mathew Benson
> wrote:
>
> What would be the recommend way to read CPU utilization? Am I correct in
> saying, the best way would be to call rtems_cpu_usage_report_with_plugin()?
> Its ill advised to access the private symbols utilized by the
> rtems_cpu_usage_report_with_plugin() call directly, right? Is there
> another function that I can call to return a structure rather than parsing
> it with the rtems_printer plugin? I haven't dug into the rtems_printer
> object yet, but I'm ass
CPU utilization
What would be the recommend way to read CPU utilization? Am I correct in saying, the best way would be to call rtems_cpu_usage_report_with_plugin()? Its ill advised to access the private symbols utilized by the rtems_cpu_usage_report_with_plugin() call directly, right? Is there another function that I can call to return a structure rather than parsing it with the rtems_printer plugin? I haven't dug into the rtems_printer object yet, but I'm assuming I could use it and parse a string sent to it. -- *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
