I’m fairly certain I’m running into this reported issue: https://devel.rtems.org/ticket/2792
Is there any status change on this? Is there a temporary workaround recovery procedure? I’m tempted to give the conditional wait a timeout. Sent from my iPhone > On Oct 9, 2019, at 23:05, Mathew Benson <mben...@windhoverlabs.com> wrote: > > 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 <chr...@rtems.org> 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
