Is the Mips interrupt code flawed?

[gregory.menke at gsfc.nasa.gov]

Bruce Robinson writes:
 > 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?
 > 
 > Any feedback would be appreciated!
 > 
 > Best Regards,
 > Bruce Robinson

The R4000 status register tweaks are pretty new at this point.  We did
go through the logic a fair bit in conjunction with R3000 and R4000
docs to ensure a working sequence of status register updates for both
cpu classes- but theres always the possiblity of subtle bugs.

A context switch from inside an isr will always completely rewrite the
status register anyway- essentially the cpu has to be taken from the
interrupt state to the state at which the next task went to sleep,
which could be inside another, past interrupt, or because the task was
put to sleep down in the C library (sleep(), select(),
rtems_wake_after() kinds of things).  Likewise, when a task that was
scheduled out from inside an isr is awoken by a context switch down in
the C library, the cpu must be taken from regular "userspace" mode to
an isr state, when then returns to the task.  This is nothing
idiosyncratic to RTEMS, all OS schedulers have to do it.

Its a tricky business to get all that stuff working right.  The R3000
support has proven stable so far, but working R4000 support is
certainly new enough to have more attention paid to it.  When we
started with the R3000 support for the Mongoose, the MIPS cpu_asm code
was pretty deeply broken in general- its gotten lots better.

As far as syscalls are concerned, RTEMS doesn't use them.  The isr
support code must ensure interrupts are disabled while its in
progress, except for while its calling the scheduler, which does its
own interrupt enable/disable dance.  But please do check it further,
more eyes makes for better debugging and all that...

Gregm