On Thu, 2011-06-09 at 18:59 -0400, David Daney wrote:
> On 06/09/2011 03:06 PM, Guenter Roeck wrote:
> > Hi David,
> > On Thu, Jun 09, 2011 at 05:41:57PM -0400, David Daney wrote:
> >> On 06/09/2011 02:08 PM, Guenter Roeck wrote:
> >>> Hi folks,
> >>> I am trying to get Linux 2.6.39
> >> Where did you get your 2.6.39? Or in othe rwords, what's the SHA1 Kenneth?
> >> From kernel.org. 184.108.40.206, more specifically. We have some local
> >> modifications,
> > but nothing relevant, ie nothing in the mips boot path.
> >> And, what is your .config?
> > Please see attached.
> commit cf29f916c310c9b13c19514b496700c549597e11
> Author: Greg Kroah-Hartman <firstname.lastname@example.org>
> Date: Fri Jun 3 09:34:20 2011 +0900
> Linux 220.127.116.11
> And with the attached config I can do:
> octeon:~# cat /proc/version
> Linux version 18.104.22.168 (email@example.com) (gcc version 4.6.1
> 20110328 (prerelease) [gcc-4_6-branch revision 171639] (GCC) ) #1031 SMP
> Thu Jun 9 15:44:46 PDT 2011
> octeon:~# head /proc/cpuinfo
> system type : EBT3000 (CN3860p3.X-500-NSP)
> processor : 0
> cpu model : Cavium Octeon V0.3
> BogoMIPS : 1000.00
> wait instruction : yes
> microsecond timers : yes
> tlb_entries : 32
> extra interrupt vector : yes
> hardware watchpoint : yes, count: 2, address/irw mask: [0x0ffc, 0x0ffb]
> ASEs implemented :
> Boots on all 16 CPUs.
Turns out my primary problem is that octeon_irq_setup_secondary_ciu()
sets C0_STATUS to 0x1000efe0, ie all interrupts except IP4 are enabled.
This mask is primarily set through octeon_irq_percpu_enable(), which
sets C0_STATUS to 0x1000e3e0. The value differs from CPU 0, where
C0_STATUS is set to 0x10008ce0.
This causes persistent spurious interrupts on our boards (both with
CN38xx and CN58xx), where C0_CAUSE persistently reads as zero in the
interrupt handling code but interrupts are triggered anyway. The
spurious interrupt problem goes away if I mask out IP0, IP1, IP5, and
IP6 at the end of octeon_irq_setup_secondary_ciu().
There is some other problem later on (maybe I disabled too much or
something else is wrong), but with the mask changes the SMP boot
calling tcp_congestion_default+0x0/0xc @ 1
initcall tcp_congestion_default+0x0/0xc returned 0 after 1 usecs
calling initialize_hashrnd+0x0/0x28 @ 1
initcall initialize_hashrnd+0x0/0x28 returned 0 after 11 usecs
Return from do_initcalls [ this is an added log message ]
Warning: unable to open an initial console.
async_waiting @ 1
before I get another hangup.
I'll track that one down next. Key question right now, though, is why
the secondary CPU boot code enables (almost) all interrupts. Any idea ?