From: Andrew Morton <akpm@digeo.com>
To: "Martin J. Bligh" <mbligh@aracnet.com>
Cc: linux-kernel <linux-kernel@vger.kernel.org>,
jejb@steeleye.com, Rusty Russell <rusty@rustcorp.com.au>,
dipankar@in.ibm.com
Subject: Re: Strange panic as soon as timer interrupts are enabled (recent 2.5)
Date: Wed, 06 Nov 2002 14:32:50 -0800 [thread overview]
Message-ID: <3DC99892.A3750D7E@digeo.com> (raw)
In-Reply-To: 132110000.1036622931@flay
"Martin J. Bligh" wrote:
>
> ...
> ---------------------
>
> BOOT CPU:
>
> init
> smp_prepare_cpus
> smp_boot_cpus
> setup_local_APIC
> foreach cpu
> do_boot_cpu
> wakeup_secondary_via_(NMI|INIT)
> {set bit in cpu_callout_map}
> {spin on cpu_callin_map}
> setup_IO_APIC
> synchronize_tsc_bp
> smp_init
> foreach cpu
> cpu_up
> notifier_call_chain(CPU_UP_PREPARE)
> __cpu_up
> {set bit in smp_commenced_mask}
> {spin on cpu_online_map}
> notifier_call_chain(CPU_ONLINE)
> smp_cpus_done
> smp_commence
Nice!
> ------------------------
>
> SECONDARY CPU:
>
> start_secondary
> cpu_init
> smp_callin
> {spin on cpu_callout_map}
> setup_local_APIC
> local_irq_enable
> calibrate_delay
> disable_APIC_timer
> {set our bit in cpu_callin_map}
> synchronise_tsc_api
> {spin on smp_commenced_mask}
> enable_APIC_timer
> {set our bit in cpu_online_map}
> idle
So this is the bug, isn't it? Can the calibrate_delay stuff be moved
until _after_ the bit has been set in smp_commenced_mask??
>
>
> > 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.
> >
> > At least, that's how I'd have designed it.
>
> Well that makes sense to me. Apart from when I started doing it,
> it seems that in smp_callin we do calibrate_delay, which looks
> like it needs interrupts enabled (I could be wrong). I suppose
> I could just disable them at the end of smp_callin again, but
> it's all rather ugly. Maybe after we do disable_APIC_timer in
> smp_callin.
Maybe you could copy the boot cpu's calibrate_delay result
over to all cpu_possible secondaries, then redo the calibration
for real once the secondary is actually legally up and running.
next prev parent reply other threads:[~2002-11-06 22:26 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 [this message]
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
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=3DC99892.A3750D7E@digeo.com \
--to=akpm@digeo.com \
--cc=dipankar@in.ibm.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.