printk 100% interrupt safe?

Smith, Gene Gene.Smith at sea.siemens.com
Thu Oct 11 23:31:36 UTC 2001


>-----Original Message-----
>From: Joel Sherrill [mailto:joel.sherrill at OARcorp.com]
>Sent: Thursday, October 11, 2001 4:48 PM
>To: Smith, Gene
>Cc: rtems-users at oarcorp.com
>Subject: Re: printk 100% interrupt safe?
>
>
>"Smith, Gene" wrote:
>> 
>> Does anyone know if the printk function is interrupt safe, 
>i.e., reentrant?
>> On some boards, I am seeing a spurious interrupt that is 
>*supposed* to be
>> disabled and masked. Yet it still occurs maybe once per 
>hour. The default
>> handler for the interrupt just printk's a short message. On 
>boards that
>> produce the spurious interrupt, a random crash occurs after 
>more than 24
>> hours. I have never seen a crash on boards that don't 
>produce the spurious
>> interrupt. I have taken the printk out of the default 
>handlers and will see
>> if that helps.  (The spurious interrupt might be caused by 
>the non-standard
>> interrupt controller I am using.)
>
>My reading is that printk does not define any global or static 
>variables
>so that much is reentrant safe.  The next thing is examining what it
>calls:
>
>bash$ sparc-rtems-nm --extern-only printk.o 
>         U .udiv
>         U .umul
>         U BSP_output_char
>00000000 T printk
>
>So only BSP_output_char is referenced.  As long as the disable/enable
>interrupt are properly paired and enable just restores things clenaly
>to their state pre-disable, then it should be fine.
>
>The big question mark is what does your BSP_output_char do?

BSP_output_char() only references a single static var, uart_ready, which
I set when the uart is initialized at bootup and it never changes, so
it doesn't seem like that would be a problem. When printk is called before
the uart is ready, I write the char to dual port memory instead of 
the uart (I can see the strings in dpm with a debugger on my other
processor).
I did just now take that out since I no longer need to see what is 
happening that early any more. I don't think it was a problem, but it might
be. Thanks for the help.

>
>> Any information would be most appreciated.
>> 
>> -gene
>
>-- 
>Joel Sherrill, Ph.D.             Director of Research & Development
>joel at OARcorp.com                 On-Line Applications Research
>Ask me about RTEMS: a free RTOS  Huntsville AL 35805
>   Support Available             (256) 722-9985
>



More information about the users mailing list