All of lore.kernel.org
 help / color / mirror / Atom feed
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

  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.