RTEMS 5.1 pc686 BSP malloc_info problem?

Joel Sherrill joel at rtems.org
Mon Oct 5 17:06:21 UTC 2020


On Mon, Oct 5, 2020 at 11:07 AM Alan Cudmore <alan.cudmore at gmail.com> wrote:

> I built the tools shortly after the announced 5.1 release. I'm using
> the 5.1 branches for everything.
> But some additional info..I built the full testsuite, and ran the
> malloctest with no problems. It calls malloc_info a couple of times.
>
> I also compiled my RTEMS Kernel Image (RKI) for this BSP and the
> "malloc info" shell command works on that. This is the same way I
> tested the sparc/leon3 BSP so at least that is consistent.
>
> This has to come down to a configuration issue for the application
> (core flight system pc-rtems test platform)
> I'm going to check over the configuration options and compiler options
> used. It will most likely be another case of user error, which I
> prefer!
>

This wouldn't be a user error. Just a case where the bug was found
after the release. :)

--joel

>
> Thanks,
> Alan
>
> On Mon, Oct 5, 2020 at 11:58 AM Joel Sherrill <joel at rtems.org> wrote:
> >
> >
> >
> > On Mon, Oct 5, 2020 at 10:34 AM Gedare Bloom <gedare at rtems.org> wrote:
> >>
> >> This is an SMP related bug?  Can you send the rtems configure command,
> >> and the qemu run command?
> >>
> >> It might also help to know the number of tasks and their priorities.
> >> The CONFIGURE* macros might also help.
> >>
> >> My first guess is that the lock primitive is somehow broken in the
> >> pc686, maybe it gets caught in a buggy CAS/TAS loop? It would help if
> >> you can narrow down the task spinning to a particular section of code
> >> and send the disassembly (or file/line if it is in RTEMS)
> >
> >
> > Hmmm.. When did you build your i386 tools? git says 9/19 for the last
> change
> > but it was very much likely a few days after that when I pushed it.
> >
> > --joel
> >>
> >>
> >> On Sun, Oct 4, 2020 at 2:06 PM Alan Cudmore <alan.cudmore at gmail.com>
> wrote:
> >> >
> >> > Hi,
> >> > I have a problem in RTEMS 5.1 where the pc686 running on QEMU seems to
> >> > block or spin when trying to acquire a lock for the malloc_info call.
> >> > The CPU utilization goes up to 100 (on the QEMU host) leading me to
> >> > think the calling task is spinning waiting on the lock. Tasks with
> >> > lower priority than the calling task stop running as well. I also get
> >> > this problem when running the "malloc info" shell command.
> >> > I don't see this problem with the leon3 BSP built from the same source
> >> > tree and executed on QEMU.
> >> >
> >> > Is there an SMP related initialization or perhaps QEMU option I might
> >> > be missing? I can run the same code without problems on the RTEMS 4.11
> >> > release (same QEMU binary and QEMU options)
> >> >
> >> > Thanks,
> >> > Alan
> >> > _______________________________________________
> >> > devel mailing list
> >> > devel at rtems.org
> >> > http://lists.rtems.org/mailman/listinfo/devel
> >> _______________________________________________
> >> devel mailing list
> >> devel at rtems.org
> >> http://lists.rtems.org/mailman/listinfo/devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20201005/27f9e974/attachment.html>


More information about the devel mailing list