diff --git a/arch/x86/src/i486/up_schedulesigaction.c b/arch/x86/src/i486/up_schedulesigaction.c
index f8289cf8df6..e037696e47f 100644
--- a/arch/x86/src/i486/up_schedulesigaction.c
+++ b/arch/x86/src/i486/up_schedulesigaction.c
@@ -114,14 +114,15 @@ void up_schedule_sigaction(struct tcb_s *tcb, sig_deliver_t sigdeliver)
             }
 
           /* CASE 2:  We are in an interrupt handler AND the interrupted task
-           * is the same as the one that must receive the signal, then we will
-           * have to modify the return state as well as the state in the TCB.
+           * is the same as the one that must receive the signal, then we
+           * will have to modify the return state as well as the state in the
+           * TCB.
            *
            * Hmmm... there looks like a latent bug here: The following logic
            * would fail in the strange case where we are in an interrupt
-           * handler, the thread is signalling itself, but a context switch to
-           * another task has occurred so that g_current_regs does not refer to
-           * the thread of this_task()!
+           * handler, the thread is signalling itself, but a context switch
+           * to another task has occurred so that g_current_regs does not
+           * refer to the thread of this_task()!
            */
 
           else
diff --git a/arch/x86_64/src/intel64/up_schedulesigaction.c b/arch/x86_64/src/intel64/up_schedulesigaction.c
index 76227ac3ff7..dce91a6477c 100644
--- a/arch/x86_64/src/intel64/up_schedulesigaction.c
+++ b/arch/x86_64/src/intel64/up_schedulesigaction.c
@@ -106,20 +106,23 @@ void up_schedule_sigaction(struct tcb_s *tcb, sig_deliver_t sigdeliver)
 
           if (!g_current_regs)
             {
-              /* In this case just deliver the signal with a function call now. */
+              /* In this case just deliver the signal with a function call
+               * now.
+               */
 
               sigdeliver(tcb);
             }
 
           /* CASE 2:  We are in an interrupt handler AND the interrupted task
-           * is the same as the one that must receive the signal, then we will
-           * have to modify the return state as well as the state in the TCB.
+           * is the same as the one that must receive the signal, then we
+           * will have to modify the return state as well as the state in the
+           * TCB.
            *
            * Hmmm... there looks like a latent bug here: The following logic
            * would fail in the strange case where we are in an interrupt
-           * handler, the thread is signalling itself, but a context switch to
-           * another task has occurred so that g_current_regs does not refer to
-           * the thread of this_task()!
+           * handler, the thread is signalling itself, but a context switch
+           * to another task has occurred so that g_current_regs does not
+           * refer to the thread of this_task()!
            */
 
           else