From: Kjetil Oftedal <oftedal@gmail.com>
To: sparclinux@vger.kernel.org
Subject: Re: Sun4d boot crash in sun4d_init_timers
Date: Tue, 24 May 2011 17:43:21 +0000 [thread overview]
Message-ID: <Pine.LNX.4.64.1105241854260.7984@oizys.tordivel.org> (raw)
In-Reply-To: <Pine.LNX.4.64.1105231908050.7984@oizys.tordivel.org>
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ô20dc005d6939b837134d146741316c024d5932;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
next prev parent reply other threads:[~2011-05-24 17:43 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-05-23 17:28 Sun4d boot crash in sun4d_init_timers Kjetil Oftedal
2011-05-23 18:59 ` daniel
2011-05-23 23:05 ` Josip Rodin
2011-05-24 8:59 ` Josip Rodin
2011-05-24 17:43 ` Kjetil Oftedal [this message]
2011-05-27 22:13 ` Tom Callaway
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Pine.LNX.4.64.1105241854260.7984@oizys.tordivel.org \
--to=oftedal@gmail.com \
--cc=sparclinux@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.