Hello Sebastian, On Tuesday 06 of September 2016 20:33:08 Sebastian Huber wrote: > The interrupt locks are simple interrupt disable/enable or spin locks. So, > they always work.
Allmost, on UP they are simple local IRQ disable. But on SMP they are spinlock combined with IRQ disable. But spinlock requires that corresponding memory location is initialized. It is initialized to 0,0 as ticked lock or combination with some debug/non-zero information depending on RTEMS_DEBUG, RTEMS_PROFILING etc. The locks ends in BSS for zero case and I expect that it is source of my problems. I have experienced hard lock of RPi BSP on rpi_select_pin_function() in SMP build when I use it in bsp_start_hook_0(), this is before bsp_start_copy_sections(). I use that for hacking to enable JTAG early in boot for BSP debugging https://github.com/ppisa/rtems/blob/rtems-rpi-devel-160621/c/src/lib/libbsp/arm/raspberrypi/startup/bspstarthooks.c#L85 I am sure that deadlock has been in rpi_select_pin_function(). Removing JTAG setup helped. I am sure that skipping locks would help. But you are right that I have not analyzed where _System_state_Is_up( _System_state_Get() ) global variable is placed. If it is in BSS then it is only matter of luck that it does not match system up state when BSS is not initialized yet. So value of patch for real BSP use case is questionable. My use case is corner or even more obscure and can be solved by setup in u-boot or definition of the function variant without locking. Anyway, thanks for review. I expect that you are quite overloaded after return from vacations but I would be really happy if you can say your comments/ACK/NACK to the rest or RPi SMP series in next days. There is that problem with generic RTL, caches on ARM and RPi BSP mostly unusable with actual firmaware on 4.11 branch. I understand, that my proposal of backport of most of related fixes from master to 4.11 is sensitive question. Again your income/voting to debate (ideally with Joel, Chris and Gedare) could help in steering 4.11 branch. Best wishes, Pavel PS: Congratulation to "Rework thread priority management". This is big/fundamental step forward for RTEMS. _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel