[Top] [All Lists]

Re: Linux 2.6.39 on Cavium CN38xx

To: Guenter Roeck <>
Subject: Re: Linux 2.6.39 on Cavium CN38xx
From: David Daney <>
Date: Tue, 14 Jun 2011 09:55:40 -0700
Cc: "" <>
In-reply-to: <>
References: <1307653714.8271.130.camel@groeck-laptop> <> <> <> <1307751642.8271.315.camel@groeck-laptop> <> <> <> <>
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20101027 Fedora/3.0.10-1.fc12 Thunderbird/3.0.10
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 
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 
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.

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}.

David Daney

<Prev in Thread] Current Thread [Next in Thread>