Is the Mips interrupt code flawed?
Joel Sherrill <joel@OARcorp.com>
joel.sherrill at OARcorp.com
Wed Oct 20 11:15:30 UTC 2004
Bruce Robinson wrote:
> To Mips-rtems users,
> I found a knowledge base article on the PMC-Sierra's web site that describes
> using a MIPS system call as the proper way to "atomically" disable
> interrupts. The system call will cause the EXL flag to be set in the status
> register, holding off interrupts while the IE bit is cleared. From my study
> of the MIPS code, it appears that RTEMS disables interrupts by reading the
> status register, adjusting the IP, EXL and IE flags, and then writing the
> value back to the status register. Isn't it possible that an interceding
> interrupt/context switch could result in the status register contents to be
> incorrectly updated?
> Am I missing something?
I don't know for sure since this is so MIPS specific. The SPARC has to
have a disable/enable system call so this is certainly possible.
From an atomicity viewpoint, the critical section for _ISR_Disable
does not start until after the SR is written. As long the ISR code
preserves that register, it is OK. Consider this sequence:
+ T1 -- read SR
+ ISR -
+ ISR - switch to T2
+ return to T1 via tail of _ISR_Dispatch
?? Is the SR maintained
+ T1 twiddles bits in SR
+ T1 saves SR
--> critical section begins here
So logically it is not necessarily an error if the ISR and ISR
preemption logic completely preserves the SR.
> Any feedback would be appreciated!
> Best Regards,
> Bruce Robinson
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