On Tue, 24 May 2011, Josip Rodin wrote:
> On Tue, May 24, 2011 at 01:05:14AM +0200, Josip Rodin wrote:
> > + board = of_getintprop_default(dp, "board#", 0);
> > + if (!board) {
>
> > Passing around the 'board' property of 'cpu-unit' looks like it should be done
> > because the same thing is used to seed board_to_cpu[].
> >
> > http://git.kernel.org/?p=linux/kernel/git/davem/prtconfs.git;a=blob;f=ss1000;h=f420dc005d6939b837134d146741316c024d5932;hb=HEAD
> > says both cpu-units have the same, zeroth board, but it might not hurt
> > to check just in case some other machine happens to use a different index.
>
> In fact it looks like 0 is a common valid value in the analogous pieces of
> code that don't even verify the result of that lookup. The above code should
> either not check that lookup either (the simple solution), or set the
> default to -1 so that it can actually discern error state.
>
Hi,
Thanks for your suggestions. I tested this earlier and you are correct, it
has to be -1 to work at all, as the boards are 0-indexed. It does however not
work completly as intended. The same goes for Daniel suggestion about using
the virtual IRQ for the irq registration.
With these changes request_irq completes without errors, and the system
continues to boot. But stalls again during "Calibrating delay loop...".
Closer inspection reveals that this is caused by the system jiffies not
increasing, and the processor being stuck in a spinlock.
I added printouts to the sun4d interrupt handler (Hoping that prom_printf
is interruptsafe). This reveals that it is triggered only once with
the SUN4D_TIMER_IRQ as the pil argument. I guess that the interrupt is not
marked as processed correctly/retriggered.
(sun4d_clear_clock_irq is called, so it should be)
Does anyone have the datasheet for SuperSparc II and MXCC? as there are
some sun4d specific calls being made during interrupt processing that
read some status flags from the MXCC.
-
Kjetil Oftedal
--
To unsubscribe from this list: send the line "unsubscribe sparclinux" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
