Is the Mips interrupt code flawed?

[Bruce Robinson]

Hi Greg and Joel,

Thanks for the detailed replies! I can really see where the interrupt
service and the context switching is implemented by a very complex and
carefully designed piece of code. I'm still concerned that the interrupt
management hasn't been implemented in the optimal way in the mips3 build.
The fact that the SPARC code uses a system call to disable interrupts gives
some credibility to there use on the MIPS processor. In previous threads I
described RTEMS code changes that would avoid the use of the EXL flag for
disabling interrupts. Using system calls that implicitly set the EXL flag
and facilitate clearing the IE bit atomically seems consistent with that
approach.

Until recently, the RTEMS 4.5.0 code has been running rock solid for me, but
now I have a case where my system locks up after a random period of 0 to 3
hours. I'm trying to identify the cause of the problem, with interrupts
being unintentionally disabled as one possibility. I was preparing to make
some changes to the interrupt disable/enable code to see if my problem went
away, but now I'm thinking I should spend some time to test my assumption
that interrupts are getting left disabled. I'll let you know what I find.

Thanks again for the feedback and guidance,
Bruce Robinson


> -----Original Message-----
> From: gregory.menke at gsfc.nasa.gov [mailto:gregory.menke at gsfc.nasa.gov]
> Sent: Wednesday, October 20, 2004 6:42 AM
> To: Bruce Robinson
> Cc: joel.sherrill at OARcorp.com; rtems-users at rtems.com
> Subject: Is the Mips interrupt code flawed?
>
>
>
> 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
>
>