Enabling smptests for i386/pc386 (for #2138)

[Amaan Cheval]

On Fri, Mar 9, 2018 at 5:26 AM Joel Sherrill <joel at rtems.org> wrote:



> 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.

Ooh, thanks for the tip!


> 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?

Yep, that's exactly it.


> 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.

Ooh, that context definitely helps. I assumed I was messing it up given that
there was so much SMP code for the i386 as well.


> 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.

Cool, I'll look into patching it to just get it to compile first, leaving
the
specific logical issues to be tackled later (assuming that's what you
meant).

> 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