All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dipankar Sarma <dipankar@gamebox.net>
To: Andrew Morton <akpm@digeo.com>
Cc: "Martin J. Bligh" <mbligh@aracnet.com>,
	"J.E.J. Bottomley" <James.Bottomley@steeleye.com>,
	linux-kernel <linux-kernel@vger.kernel.org>,
	jejb@steeleye.com, Rusty Russell <rusty@rustcorp.com.au>
Subject: Re: Strange panic as soon as timer interrupts are enabled (recent 2.5)
Date: Fri, 8 Nov 2002 00:11:11 +0530	[thread overview]
Message-ID: <20021108001111.A23292@dikhow> (raw)
In-Reply-To: <3DC975DC.77231191@digeo.com>; from akpm@digeo.com on Wed, Nov 06, 2002 at 12:04:44PM -0800

On Wed, Nov 06, 2002 at 12:04:44PM -0800, Andrew Morton wrote:
> > >
> > > The softirq storage is initialised inside the CPU_UP_PREPARE call.
> > > So we're ready for interrupts on that CPU when your architecture's
> > > __cpu_up() is called.  And no sooner than this.
> > 
> > All interrupts, or just softints?
> > 
> 
> I don't know.  This sequencing really needs to be thought about
> and written down, else we'll just have an ongoing fiasco trying
> to graft stuff onto it.
> 
> In this case I'd say "all interrupts".  The secondary really
> should be 100% dormant until all CPU_UP_PREPARE callouts have
> been run and have returned NOTIFY_OK.

Well, the secondaries atleast cannot take the local timer interrupt
since things hooked off it, like timers and RCU, are initiliazed
using CPU_UP_PREPARE callouts. I would agree that it is unsafe to
allow *any* interrupt until CPU_UP_PREPARE callouts are completed.

So, the current way of enabling interrupts in secondaries during
delay calibration is unsafe. For that matter, it seems to me
that with no proper mixed CPU support, calibrate_delay() for
secondaries is meaningless.

Thanks
Dipankar

      parent reply	other threads:[~2002-11-07 18:37 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <Martin.Bligh@us.ibm.com>
2002-11-06 20:11 ` Strange panic as soon as timer interrupts are enabled (recent 2.5) Martin J. Bligh
2002-11-06 19:32   ` J.E.J. Bottomley
2002-11-06 19:46     ` Andrew Morton
2002-11-06 20:45       ` Martin J. Bligh
2002-11-06 20:04         ` Andrew Morton
2002-11-06 22:48           ` Martin J. Bligh
2002-11-06 22:32             ` Andrew Morton
2002-11-07  0:27               ` Martin J. Bligh
2002-11-07 15:18                 ` J.E.J. Bottomley
2002-11-07 15:23                   ` Martin J. Bligh
2002-11-07 18:41           ` Dipankar Sarma [this message]

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=20021108001111.A23292@dikhow \
    --to=dipankar@gamebox.net \
    --cc=James.Bottomley@steeleye.com \
    --cc=akpm@digeo.com \
    --cc=jejb@steeleye.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mbligh@aracnet.com \
    --cc=rusty@rustcorp.com.au \
    /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.