RTEMS 5.1 pc686 BSP malloc_info problem?

[Alan Cudmore]

On Thu, Oct 15, 2020 at 3:03 PM Chris Johns <chrisj at rtems.org> wrote:
>
> On 16/10/20 5:22 am, Alan Cudmore wrote:
> > On Thu, Oct 15, 2020 at 11:19 AM Gedare Bloom <gedare at rtems.org> wrote:
> >>
> >> On Thu, Oct 15, 2020 at 6:35 AM Joel Sherrill <joel at rtems.org> wrote:
> >>>
> >>>
> >>>
> >>> On Thu, Oct 15, 2020, 7:15 AM Alan Cudmore <alan.cudmore at gmail.com> wrote:
> >>>>
> >>>> Thanks for all of the help, and thanks for the patch Chris! I was
> >>>> hoping to submit a patch this weekend, so you just gave me back some
> >>>> time :)
> >>>
> >>>
> >>> Glad you found this!
> >>>
> >>> The RFS was new in 4.10 as I recall. You guys have missions using this. Do you need to locally fix this?
> >
> > We have one active mission that uses it. I will be worth trying to
> > determine what word of memory is affected before trying to fix it,
> > since it has been operating normally for 5.5 years with the issue.
> >
>
> The number of bits needs to align to a value that fits the whole 32 bit mask so
> the last is used to trigger the bug.

How can I calculate this? It would be great if I could tell known
users that they don't need to worry about it.
For example, in the open source cFS bundle where I encountered the
issue, it creates an RFS formatted RAM disk that is 0x200000 bytes in
size (2 Mbytes). I would imagine that is a nice round number of bitmap
elements.

Thanks,
Alan

>
> Chris