Can printf() be made SMP safe?

Fri Apr 30 22:42:13 UTC 2021

Thanks Joel!

I said it was crashing, it's actually currently hanging, but it changes.  The common thread is it always seems to be in semaphore access functions w/at least one task in printf(). I don't think it's floating point, it looks like RTEMS_FLOATING_POINT is passed to rtems_task_create(), but I'll have to do some testing to be sure.

The current backtrace I get when I ^c after it hangs is below.

Dave

 CPU 0: Interrupted!
0x6005bad4: 80a08003 cmp %g2, %g3 <_Mutex_Acquire+52>
CPU 1: Interrupted!
0x6005ff98: 80a04002 cmp %g1, %g2 <_SMP_lock_Acquire+40>

grmon3> bt cpu0

%pc %sp
#0 0x6005bad4 0x6047af58 <_Mutex_Acquire+0x34>
#1 0x60047558 0x6047b068 <rtems_termios_imfs_write+0xc>
#2 0x600495a4 0x6047b0e8 <write+0x84>
#3 0x600d558c 0x6047b148 <__sflush_r+0x1bc>
#4 0x600d56f0 0x6047b1a8 <_fflush_r+0x9c>
#5 0x600f086c 0x6047b208 <__sbprintf+0xb4>
#6 0x600db280 0x6047b6e8 <printf+0x2c>
#7 0x60030f30 0x6047b750 <SCH_ProcessNextEntry+0x1e8>
#8 0x60030fd0 0x6047b7f0 <SCH_ProcessNextSlot+0x94>
#9 0x6003111c 0x6047b850 <SCH_ProcessScheduleTable+0xb4>
#10 0x600314b4 0x6047b8b0 <SCH_AppMain+0x23c>
#11 0x60023d28 0x6047b928 <OS_TaskEntryPoint+0xb0>
#12 0x60056d28 0x6047b990 <_Thread_Entry_adaptor_numeric+0x8>
#13 0x60055878 0x6047b9f0 <_Thread_Handler+0xf4>
#14 0x60055784 0x6047ba58 <_Thread_Handler+0>

grmon3> bt cpu1

%pc %sp
#0 0x6005ff98 0x60466ba8 <_SMP_lock_Acquire+0x28>
#1 0x60058164 0x60466ba8 <_Thread_queue_Surrender+0x54>
#2 0x6005bd4c 0x60466c10 <_Mutex_Release+0x7c>
#3 0x600475fc 0x60466d20 <rtems_termios_imfs_write+0xb0>
#4 0x600495a4 0x60466da0 <write+0x84>
#5 0x600d558c 0x60466e00 <__sflush_r+0x1bc>
#6 0x600d56f0 0x60466e60 <_fflush_r+0x9c>
#7 0x600f086c 0x60466ec0 <__sbprintf+0xb4>
#8 0x600db280 0x604673a0 <printf+0x2c>
#9 0x60029074 0x60467408 <SENSORS_dumpBytes+0xe8>
#10 0x60029324 0x604674c0 <SENSORS_ProcessSensorPacketSTUP+0xc4>
#11 0x60029764 0x60467528 <SENSORS_ProcessSPWRxPackets+0x210>
#12 0x600287bc 0x604675a0 <SENSORS_AppMain+0x6c>
#13 0x60023d28 0x60467608 <OS_TaskEntryPoint+0xb0>
#14 0x60056d28 0x60467670 <_Thread_Entry_adaptor_numeric+0x8>
#15 0x60055878 0x604676d0 <_Thread_Handler+0xf4>
#16 0x60055784 0x60467738 <_Thread_Handler+0>

________________________________
From: Joel Sherrill <joel at rtems.org>
Sent: Friday, April 30, 2021 4:21 PM
To: Dave DeGroote
Cc: users at rtems.org
Subject: Re: Can printf() be made SMP safe?

CAUTION: This email originated from outside of the organization.

On Fri, Apr 30, 2021 at 2:07 PM Dave DeGroote <Dave.DeGroote at astrobotic.com<mailto:Dave.DeGroote at astrobotic.com>> wrote:

Hello,

I'm trying to get RTEMS running using SMP on a Leon3/gr712rc (2 cores). I have it partially running, but it crashes intermittently on printf's.  Can anyone tell me if there's a way to make printf() SMP safe?  printf appears to use termios which uses rtems_mutex_init() and rtems_binary_semaphore_init() which I don't think are SMP safe (but I'm also new to this so I'm not sure).

Those are SMP safe. I suspect you are using the Classic API (e.g. rtems_task_) and by default they do not have floating point enabled. You probably just need to enable the floating point attribute on the task create calls (or for the init task).

https://docs.rtems.org/branches/master/c-user/task/directives.html#rtems-task-create<https://docs.rtems.org/branches/master/c-user/task/directives.html#rtems-task-create>

See configuring a system chapter for the init task setting.

If you provide the exception, we would know for sure.

--joel

Disclaimer

The information contained in this communication from the sender is confidential. It is intended solely for use by the recipient and others authorized to receive it. If you are not the recipient, you are hereby notified that any disclosure, copying, distribution or taking action in relation of the contents of this information is strictly prohibited and may be unlawful.

This email has been scanned for viruses and malware, and may have been automatically archived by Mimecast Ltd, an innovator in Software as a Service (SaaS) for business. Providing a safer and more useful place for your human generated data. Specializing in; Security, archiving and compliance. To find out more visit the Mimecast website.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/users/attachments/20210430/eeb4b0be/attachment-0001.html>