On Tue, 2011-06-14 at 12:55 -0400, David Daney wrote:
> On 06/13/2011 08:34 PM, Guenter Roeck wrote:
> > On Mon, Jun 13, 2011 at 05:51:11PM -0400, Guenter Roeck wrote:
> > [ ... ]
> >>>>
> >>>> The actual interrupt causing trouble and spurious interrupts in my case is,
> >>>> oddly enough, STATUSF_IP0. So far I have been unable to track down how that
> >>>> is triggered; I don't see the bit being set set in C0_CAUSE anywhere.
> >>>>
> >>>> Are there any means to trigger an IP0 interrupt other than by writing STATUSF_IP0
> >>>> into the C0_CAUSE register ?
> >>>>
> >>>
> >>> No. Nothing that I know of ever uses IP0 and IP1, so they should always
> >>> be cleared.
> >>>
> >> Exactly what I figured, yet I still get those spurious interrupts if IP0 is enabled.
> >> Something odd is definitely going on in my system.
> >>
> >> Besides the above, my hopefully final problem is that timer interrupts are only
> >> received by CPU 0. Any idea what to look for to fix this problem ?
> >>
> > Found the problem. Apparently the BIOS resets CvmCtl[IPTI] to 0.
>
> That is clearly erroneous behavior. Although you can set any value, the
> HRM clearly states that 2..7 are the only legal values.
>
.. and one that I didn't expect at all. Yet here it is:
/* Force the default state (all 0), including BE mode. */
dmtc0 zero, CVMC0_CVM_CTL
Guess someone didn't know or care what the "default state" is. Cost me
10 days - by far the most expensive single line of assembler I ever
wrote :(.
> The Cavuim/Octeon u-boot just leave it at the default value of 7, and
> the kernel basically expects it to be 7, and never explicitly sets it.
>
> We do set the IPPCI to 6 in the kernel, and for performance reasons,
> expect it to have a different value than IPTI. IP{2,3,4} are basically
> reserved for use by the system interrupt controller, so really these
> things must be on one of IP{5,6,7}.
>
Yes, I noticed. I fixed my problem by setting IPTI to 7 at the same
location.
Thanks,
Guenter
