File system deadlock troubleshooting

[mbenson at windhoverlabs.com]

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 <mbenson at 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 <chrisj at 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
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/users/attachments/20191010/bfd3bf37/attachment.html>