On Fri, Mar 9, 2018 at 5:26 AM Joel Sherrill <j...@rtems.org> wrote:
> On Thu, Mar 8, 2018 at 12:22 PM, Amaan Cheval <amaan.che...@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@rtems.org >> http://lists.rtems.org/mailman/listinfo/devel _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
