Enabling smptests for i386/pc386 (for #2138)

Joel Sherrill joel at rtems.org
Thu Mar 8 23:56:42 UTC 2018


On Thu, Mar 8, 2018 at 12:22 PM, Amaan Cheval <amaan.cheval at gmail.com>
wrote:

> In reference to #2138; I'd like to give fixing this issue a shot to get my
> feet
> wet with RTEMS.
>
> I tried enabling the tests in ./testsuites/smptests/ to find a way to make
> the
> test fail at first, so I'd have a frame of reference, but I couldn't quite
> get
> the test to be compiled for i386 at all.
>
> (I'm not quite sure yet how --enable-tests determines which of the
> testsuites
> get built - I think bspopts.h.in is generated based on the BSP-specific
> config?)
>
> Based on the little note about --enable-smp in the docs[1], I added the
> switch,
> along with --enable-tests during the configure stage.
>
> Full command:
>
> ../kernel/configure --prefix=$HOME/bin/rtems/5-i386 --target=i386-rtems5
> --enable-rtemsbsp=pc386 --enable-posix --enable-tests --enable-smp
>

I don't think it is your problem but you have to build a higher CPU model
to have atomic instructions. I think pc586-sse is OK.

I tried to build it and got these build errors:

In file included from
../../../../../../../../rtems/c/src/../../cpukit/score/cpu/i386/cpu.c:29:0:
/home/joel/rtems-work/rtems/cpukit/include/rtems/score/percpu.h:384:23:
error: variable or field 'Interrupt_frame' declared void
   CPU_Interrupt_frame Interrupt_frame;
                       ^~~~~~~~~~~~~~~
/home/joel/rtems-work/rtems/cpukit/include/rtems/score/percpu.h:520:8:
error: size of array 'unused_space_for_cache_line_alignment' is too large
   char unused_space_for_cache_line_alignment
        ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Is that what you see?

The history of the SMP effort is that the SPARC, PowerPC, and ARM
turned out to be more attractive to developers and early adopters. The
i386 didn't get updated as the SMP evolved.

The i386 has a handful of known SMP issues with tickets and apparently
some bitrot as the SMP implementation evolved and no one kept the
i386 up to date.

It would be appreciated to fix build errors and get it working no matter
what the issues are. Look at the comparable code in the architectures
I listed to see what the proper thing to do is. I suspect the i386 is not
that
far off.

Disclaimer: the pc386 is based primarily on legacy hardware. It supports
just enough of the new PIC to handle SMP interrupts. This limits the number
of IRQ sources. There is an open project related to that. But the SMP
did work and should be a few patches of rot and known bugs away.


> This results in a failure at the make step[2] (at least as of commit cf2024
> (and
> a quick test against 828049, after running bootstrap -H as well)).
>
> Before the preinstall stage was removed, BSP_HAS_SMP in
> ./c/src/lib/libbsp/i386/pc386/include/bspopts.h.in was undef'd as well,
> which
> seems to be relevant.
>
> I haven't dug enough into what may be causing the error; I'm sending this
> email
> erring on the side of asking too many questions, since I figured it'd be
> more
> effective to just get help and work faster from the collective genius of
> the
> community!
>
> Am I just doing something inherently misguided in even trying to enable
> these
> tests for i386?
>
>
> [1]
> https://docs.rtems.org/branches/master/c-user/symmetric_multiprocessing_
> services.html#introduction
> [2] https://gist.github.com/AmaanC/03566c18793ff61a25328bfaf395df09
> _______________________________________________
> 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/20180308/474ee44e/attachment-0002.html>


More information about the devel mailing list