From: Andrew Morton <akpm@osdl.org>
To: "Martin J. Bligh" <mbligh@mbligh.org>
Cc: linux-kernel@vger.kernel.org
Subject: Re: 2.6.13-rc3-mm3
Date: Thu, 28 Jul 2005 23:08:20 -0700 [thread overview]
Message-ID: <20050728230820.236cba84.akpm@osdl.org> (raw)
In-Reply-To: <159600000.1122616708@[10.10.2.4]>
"Martin J. Bligh" <mbligh@mbligh.org> wrote:
>
>
> > - There's a pretty large x86_64 update here which naughty maintainer wants
> > in 2.6.13. Extra testing, please.
>
> Is still regressed as of 2.6.12 for me, at least. Crashes in TSC sync.
> Talked to Andi about it at OLS, but then drank too much to remember the
> conclusion ... however, it's still broken ;-)
>
> Matrix is here (see left hand column).
>
> http://test.kernel.org/
>
> Example boot log is here:
>
> http://test.kernel.org/9447/debug/console.log
Does Eric's recent fix fix it?
From: Eric W. Biederman <ebiederm@xmission.com>
sync_tsc was using smp_call_function to ask the boot processor to report
it's tsc value. smp_call_function performs an IPI_send_allbutself which is
a broadcast ipi. There is a window during processor startup during which
the target cpu has started and before it has initialized it's interrupt
vectors so it can properly process an interrupt. Receveing an interrupt
during that window will triple fault the cpu and do other nasty things.
Why cli does not protect us from that is beyond me.
The simple fix is to match ia64 and provide a smp_call_function_single.
Which avoids the broadcast and is more efficient.
This certainly fixes the problem of getting stuck on boot which was very
easy to trigger on my SMP Hyperthreaded Xeon, and I think it fixes it for
the right reasons.
I believe this patch suffers from apicid versus logical cpu number
confusion. I copied the basic logic from smp_send_reschedule and I can't
find where that translates from the logical cpuid to apicid. So it isn't
quite correct yet. It should be close enough that it shouldn't be too hard
to finish it up.
More bug fixes after I have slept but I figured I needed to get this
one out for review.
Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
---
arch/x86_64/kernel/smp.c | 65 +++++++++++++++++++++++++++++++++++++++++++
arch/x86_64/kernel/smpboot.c | 18 +++++++----
include/asm-x86_64/smp.h | 2 +
3 files changed, 79 insertions(+), 6 deletions(-)
diff -puN arch/x86_64/kernel/smpboot.c~x86_64-sync_tsc-fix-the-race-so-we-can-boot arch/x86_64/kernel/smpboot.c
--- devel/arch/x86_64/kernel/smpboot.c~x86_64-sync_tsc-fix-the-race-so-we-can-boot 2005-07-28 22:07:55.000000000 -0700
+++ devel-akpm/arch/x86_64/kernel/smpboot.c 2005-07-28 22:07:55.000000000 -0700
@@ -280,7 +280,7 @@ get_delta(long *rt, long *master)
return tcenter - best_tm;
}
-static __cpuinit void sync_tsc(void)
+static __cpuinit void sync_tsc(unsigned int master)
{
int i, done = 0;
long delta, adj, adjust_latency = 0;
@@ -294,9 +294,17 @@ static __cpuinit void sync_tsc(void)
} t[NUM_ROUNDS] __cpuinitdata;
#endif
+ printk(KERN_INFO "CPU %d: Syncing TSC to CPU %u.\n",
+ smp_processor_id(), master);
+
go[MASTER] = 1;
- smp_call_function(sync_master, NULL, 1, 0);
+ /* It is dangerous to broadcast IPI as cpus are coming up,
+ * as they may not be ready to accept them. So since
+ * we only need to send the ipi to the boot cpu direct
+ * the message, and avoid the race.
+ */
+ smp_call_function_single(master, sync_master, NULL, 1, 0);
while (go[MASTER]) /* wait for master to be ready */
no_cpu_relax();
@@ -340,16 +348,14 @@ static __cpuinit void sync_tsc(void)
printk(KERN_INFO
"CPU %d: synchronized TSC with CPU %u (last diff %ld cycles, "
"maxerr %lu cycles)\n",
- smp_processor_id(), boot_cpu_id, delta, rt);
+ smp_processor_id(), master, delta, rt);
}
static void __cpuinit tsc_sync_wait(void)
{
if (notscsync || !cpu_has_tsc)
return;
- printk(KERN_INFO "CPU %d: Syncing TSC to CPU %u.\n", smp_processor_id(),
- boot_cpu_id);
- sync_tsc();
+ sync_tsc(boot_cpu_id);
}
static __init int notscsync_setup(char *s)
diff -puN arch/x86_64/kernel/smp.c~x86_64-sync_tsc-fix-the-race-so-we-can-boot arch/x86_64/kernel/smp.c
--- devel/arch/x86_64/kernel/smp.c~x86_64-sync_tsc-fix-the-race-so-we-can-boot 2005-07-28 22:07:55.000000000 -0700
+++ devel-akpm/arch/x86_64/kernel/smp.c 2005-07-28 22:07:55.000000000 -0700
@@ -294,6 +294,71 @@ void unlock_ipi_call_lock(void)
}
/*
+ * this function sends a 'generic call function' IPI to one other CPU
+ * in the system.
+ */
+static void __smp_call_function_single (int cpu, void (*func) (void *info), void *info,
+ int nonatomic, int wait)
+{
+ struct call_data_struct data;
+ int cpus = 1;
+
+ data.func = func;
+ data.info = info;
+ atomic_set(&data.started, 0);
+ data.wait = wait;
+ if (wait)
+ atomic_set(&data.finished, 0);
+
+ call_data = &data;
+ wmb();
+ /* Send a message to all other CPUs and wait for them to respond */
+ send_IPI_mask(cpumask_of_cpu(cpu), CALL_FUNCTION_VECTOR);
+
+ /* Wait for response */
+ while (atomic_read(&data.started) != cpus)
+ cpu_relax();
+
+ if (!wait)
+ return;
+
+ while (atomic_read(&data.finished) != cpus)
+ cpu_relax();
+}
+
+/*
+ * Run a function on another CPU
+ * <func> The function to run. This must be fast and non-blocking.
+ * <info> An arbitrary pointer to pass to the function.
+ * <nonatomic> Currently unused.
+ * <wait> If true, wait until function has completed on other CPUs.
+ * [RETURNS] 0 on success, else a negative status code.
+ *
+ * Does not return until the remote CPU is nearly ready to execute <func>
+ * or is or has executed.
+ */
+
+int smp_call_function_single (int cpu, void (*func) (void *info), void *info,
+ int nonatomic, int wait)
+{
+
+ int me = get_cpu(); /* prevent preemption and reschedule on another processor */
+
+ if (cpu == me) {
+ printk("%s: trying to call self\n", __func__);
+ put_cpu();
+ return -EBUSY;
+ }
+ spin_lock_bh(&call_lock);
+
+ __smp_call_function_single(cpu, func,info,nonatomic,wait);
+
+ spin_unlock_bh(&call_lock);
+ put_cpu();
+ return 0;
+}
+
+/*
* this function sends a 'generic call function' IPI to all other CPUs
* in the system.
*/
diff -puN include/asm-x86_64/smp.h~x86_64-sync_tsc-fix-the-race-so-we-can-boot include/asm-x86_64/smp.h
--- devel/include/asm-x86_64/smp.h~x86_64-sync_tsc-fix-the-race-so-we-can-boot 2005-07-28 22:07:55.000000000 -0700
+++ devel-akpm/include/asm-x86_64/smp.h 2005-07-28 22:07:55.000000000 -0700
@@ -48,6 +48,8 @@ extern void unlock_ipi_call_lock(void);
extern int smp_num_siblings;
extern void smp_flush_tlb(void);
extern void smp_message_irq(int cpl, void *dev_id, struct pt_regs *regs);
+extern int smp_call_function_single (int cpuid, void (*func) (void *info), void *info,
+ int retry, int wait);
extern void smp_send_reschedule(int cpu);
extern void smp_invalidate_rcv(void); /* Process an NMI */
extern void zap_low_mappings(void);
_
next prev parent reply other threads:[~2005-07-29 6:09 UTC|newest]
Thread overview: 96+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-07-28 9:58 2.6.13-rc3-mm3 Andrew Morton
2005-07-28 10:44 ` [-mm patch] fix MTRR compilation with SMP=n Adrian Bunk
2005-07-28 17:11 ` 2.6.13-rc3-mm3 Christoph Lameter
2005-07-28 19:52 ` 2.6.13-rc3-mm3 Russell King
2005-07-28 20:06 ` 2.6.13-rc3-mm3 Christoph Lameter
2005-07-28 19:11 ` 2.6.13-rc3-mm3 Rafael J. Wysocki
2005-07-28 19:16 ` 2.6.13-rc3-mm3 Andrew Morton
2005-07-28 21:40 ` 2.6.13-rc3-mm3 Rafael J. Wysocki
2005-07-28 23:31 ` 2.6.13-rc3-mm3 Andrew Morton
2005-07-29 7:06 ` 2.6.13-rc3-mm3 Matthias Urlichs
2005-07-29 9:27 ` 2.6.13-rc3-mm3 Andrew Morton
2005-07-29 12:01 ` 2.6.13-rc3-mm3 Matthias Urlichs
2005-07-29 14:12 ` Regression hunting with git (was: Re: 2.6.13-rc3-mm3) Matthias Urlichs
2005-07-28 20:34 ` 2.6.13-rc3-mm3 Adrian Bunk
2005-07-28 22:09 ` 2.6.13-rc3-mm3 Michael Thonke
2005-07-28 20:15 ` 2.6.13-rc3-mm3 Andrew Morton
2005-07-28 20:56 ` 2.6.13-rc3-mm3 Nick Sillik
2005-07-28 23:16 ` 2.6.13-rc3-mm3 Michael Thonke
2005-07-28 20:29 ` 2.6.13-rc3-mm3 Adrian Bunk
2005-07-28 23:29 ` 2.6.13-rc3-mm3 Michael Thonke
2005-07-28 22:02 ` 2.6.13-rc3-mm3 Dirk
2005-07-28 23:46 ` 2.6.13-rc3-mm3 Andrew Morton
2005-07-29 15:48 ` 2.6.13-rc3-mm3 Michael Thonke
2005-07-29 19:33 ` 2.6.13-rc3-mm3 Andrew Morton
2005-07-30 0:00 ` 2.6.13-rc3-mm3 Michael Thonke
2005-07-29 5:58 ` 2.6.13-rc3-mm3 Martin J. Bligh
2005-07-29 6:08 ` Andrew Morton [this message]
2005-07-29 15:21 ` 2.6.13-rc3-mm3 Martin J. Bligh
2005-07-29 16:15 ` 2.6.13-rc3-mm3 Eric W. Biederman
2005-07-29 6:01 ` 2.6.13-rc3-mm3 Martin J. Bligh
2005-07-29 6:10 ` 2.6.13-rc3-mm3 Andrew Morton
2005-08-03 1:17 ` 2.6.13-rc3-mm3 Martin J. Bligh
2005-08-03 4:21 ` 2.6.13-rc3-mm3 Martin J. Bligh
2005-08-07 23:23 ` 2.6.13-rc3-mm3 Martin J. Bligh
2005-07-29 6:02 ` 2.6.13-rc3-mm3 Martin J. Bligh
2005-07-29 23:05 ` 2.6.13-rc3-mm3 Khalid Aziz
2005-07-29 23:17 ` 2.6.13-rc3-mm3 Andrew Morton
2005-07-30 15:33 ` 2.6.13-rc3-mm3 Khalid Aziz
2005-07-30 18:02 ` 2.6.13-rc3-mm3 Andrew Morton
2005-08-01 15:36 ` 2.6.13-rc3-mm3 Bjorn Helgaas
2005-07-30 10:27 ` 2.6.13-rc3-mm3 Richard Purdie
2005-07-30 17:05 ` 2.6.13-rc3-mm3 Andrew Morton
2005-07-31 9:04 ` 2.6.13-rc3-mm3 Manuel Lauss
2005-07-31 9:16 ` 2.6.13-rc3-mm3 Andrew Morton
2005-07-31 11:12 ` 2.6.13-rc3-mm3 Manuel Lauss
2005-07-31 12:46 ` 2.6.13-rc3-mm3 Manuel Lauss
2005-07-31 17:35 ` 2.6.13-rc3-mm3 Andrew Morton
2005-07-31 18:21 ` 2.6.13-rc3-mm3 Manuel Lauss
2005-07-31 18:25 ` 2.6.13-rc3-mm3 Linus Torvalds
2005-07-31 18:41 ` 2.6.13-rc3-mm3 Manuel Lauss
2005-07-31 18:59 ` 2.6.13-rc3-mm3 Linus Torvalds
2005-07-31 21:35 ` 2.6.13-rc3-mm3 Stelian Pop
[not found] ` <Pine.LNX.4.58.0507311125360.29650@g5.osdl.org>
[not found] ` <1122846072.17880.43.camel@deep-space-9.dsnet>
[not found] ` <Pine.LNX.4.58.0507311557020.14342@g5.osdl.org>
2005-08-01 14:37 ` 2.6.13-rc3-mm3 Stelian Pop
2005-08-02 9:49 ` 2.6.13-rc3-mm3 Stelian Pop
2005-08-02 10:32 ` 2.6.13-rc3-mm3 Manuel Lauss
2005-08-02 11:40 ` 2.6.13-rc3-mm3 Ivan Kokshaysky
2005-08-02 14:04 ` 2.6.13-rc3-mm3 Manuel Lauss
2005-08-02 15:48 ` 2.6.13-rc3-mm3 Linus Torvalds
2005-08-02 16:50 ` 2.6.13-rc3-mm3 Ivan Kokshaysky
2005-08-02 17:11 ` 2.6.13-rc3-mm3 Linus Torvalds
2005-08-02 21:13 ` 2.6.13-rc3-mm3 Ivan Kokshaysky
2005-08-02 21:21 ` 2.6.13-rc3-mm3 Greg KH
2005-08-02 21:47 ` 2.6.13-rc3-mm3 Ivan Kokshaysky
2005-08-02 21:57 ` 2.6.13-rc3-mm3 Linus Torvalds
2005-08-02 22:59 ` [patch 1/2] increase PCIBIOS_MIN_IO on x86 Ivan Kokshaysky
2005-08-02 23:09 ` [patch 2/2] ACPI: " Ivan Kokshaysky
2005-08-01 1:43 ` 2.6.13-rc3-mm3 Richard Purdie
2005-08-01 16:10 ` 2.6.13-rc3-mm3 Christoph Lameter
2005-08-01 20:02 ` 2.6.13-rc3-mm3 Richard Purdie
2005-08-01 20:36 ` 2.6.13-rc3-mm3 Christoph Lameter
2005-08-01 21:07 ` 2.6.13-rc3-mm3 Richard Purdie
2005-08-01 21:16 ` 2.6.13-rc3-mm3 Christoph Lameter
2005-08-01 21:27 ` 2.6.13-rc3-mm3 Richard Purdie
2005-08-01 21:40 ` 2.6.13-rc3-mm3 Christoph Lameter
2005-08-01 21:52 ` 2.6.13-rc3-mm3 Richard Purdie
2005-08-01 22:02 ` 2.6.13-rc3-mm3 Christoph Lameter
2005-08-01 22:19 ` 2.6.13-rc3-mm3 Christoph Lameter
2005-08-01 23:01 ` 2.6.13-rc3-mm3 Richard Purdie
2005-08-01 23:16 ` 2.6.13-rc3-mm3 Christoph Lameter
2005-08-01 23:32 ` 2.6.13-rc3-mm3 Richard Purdie
2005-08-04 0:19 ` 2.6.13-rc3-mm3 Christoph Lameter
2005-08-04 11:27 ` 2.6.13-rc3-mm3 Richard Purdie
2005-08-04 14:04 ` 2.6.13-rc3-mm3 Christoph Lameter
2005-08-04 14:37 ` 2.6.13-rc3-mm3 Richard Purdie
2005-08-05 15:17 ` 2.6.13-rc3-mm3 Christoph Lameter
2005-08-07 13:44 ` 2.6.13-rc3-mm3 Richard Purdie
2005-08-08 16:48 ` 2.6.13-rc3-mm3 Christoph Lameter
2005-08-08 17:10 ` 2.6.13-rc3-mm3 Russell King
2005-08-08 17:15 ` 2.6.13-rc3-mm3 Christoph Lameter
2005-08-08 20:40 ` 2.6.13-rc3-mm3 Richard Purdie
2005-08-08 22:12 ` 2.6.13-rc3-mm3 Richard Purdie
2005-08-09 0:57 ` 2.6.13-rc3-mm3 Christoph Lameter
2005-09-14 14:32 ` 2.6.13-mm3 and 2.6.14-rc1 both broken (SCSI?) Martin J. Bligh
2005-09-14 14:09 ` Anton Blanchard
2005-07-28 10:40 2.6.13-rc3-mm3 Sebastian Kaergel
2005-07-28 9:54 ` 2.6.13-rc3-mm3 Alexandre Buisse
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=20050728230820.236cba84.akpm@osdl.org \
--to=akpm@osdl.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mbligh@mbligh.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
Powered by JetHome