Re: [PATCH] x86_64: sync_tsc fix the race (so we can boot)

Eric, Latest tree works. YH Booting processor 1/4 APIC 0x1 Initializing CPU#1 masked ExtINT on CPU#1 Calibrating delay using timer specific routine.. 4000.31 BogoMIPS (lpj=8000624) CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line) CPU: L2 Cache: 1024K (64 bytes/line) CPU 1(1)

Re: [PATCH] x86_64: sync_tsc fix the race (so we can boot)

I will use linus's latest tree to have a try. YH On 7/29/05, Eric W. Biederman <[EMAIL PROTECTED]> wrote: > yhlu <[EMAIL PROTECTED]> writes: > > > if using you patch, the > > "synchronized TSC with CPU" never come out. > > > > then with your patch, I add back patch that moving set callin_map

Re: [PATCH] x86_64: sync_tsc fix the race (so we can boot)

yhlu <[EMAIL PROTECTED]> writes: > if using you patch, the > "synchronized TSC with CPU" never come out. > > then with your patch, I add back patch that moving set callin_map from > smp_callin to start_secondary. It told me can not inquire the apic for > the CPU 12 Hmm. You didn't post

Re: [PATCH] x86_64: sync_tsc fix the race (so we can boot)

Can we put tsc_sync_wait() back to smp_callin? So that it will be executed serially and we can get "synchronized TSC with CPU"? YH - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at

Re: [PATCH] x86_64: sync_tsc fix the race (so we can boot)

if using you patch, the "synchronized TSC with CPU" never come out. then with your patch, I add back patch that moving set callin_map from smp_callin to start_secondary. It told me can not inquire the apic for the CPU 12 YH Initializing CPU#1 masked ExtINT on CPU#1 Calibrating delay

Re: [PATCH] x86_64: sync_tsc fix the race (so we can boot)

Andi Kleen <[EMAIL PROTECTED]> writes: > On Wed, Jul 27, 2005 at 10:03:04PM -0600, Eric W. Biederman wrote: >> 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

Re: [PATCH] x86_64: sync_tsc fix the race (so we can boot)

Andi Kleen <[EMAIL PROTECTED]> writes: > There are some style problems, but that can be fixed later. > > How did you track that nasty it down? I had a consistent reproducer. I ruled out hangs in the tsc sync code itself, by implementing timeouts in all of the loops. I looked for

Re: [PATCH] x86_64: sync_tsc fix the race (so we can boot)

On Wed, Jul 27, 2005 at 10:03:04PM -0600, Eric W. Biederman wrote: > 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 >

Re: [PATCH] x86_64: sync_tsc fix the race (so we can boot)

On Wed, Jul 27, 2005 at 10:03:04PM -0600, Eric W. Biederman wrote: 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

Re: [PATCH] x86_64: sync_tsc fix the race (so we can boot)

Andi Kleen [EMAIL PROTECTED] writes: There are some style problems, but that can be fixed later. How did you track that nasty it down? I had a consistent reproducer. I ruled out hangs in the tsc sync code itself, by implementing timeouts in all of the loops. I looked for differences

Re: [PATCH] x86_64: sync_tsc fix the race (so we can boot)

Andi Kleen [EMAIL PROTECTED] writes: On Wed, Jul 27, 2005 at 10:03:04PM -0600, Eric W. Biederman wrote: 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

Re: [PATCH] x86_64: sync_tsc fix the race (so we can boot)

if using you patch, the synchronized TSC with CPU never come out. then with your patch, I add back patch that moving set callin_map from smp_callin to start_secondary. It told me can not inquire the apic for the CPU 12 YH Initializing CPU#1 masked ExtINT on CPU#1 Calibrating delay using

Re: [PATCH] x86_64: sync_tsc fix the race (so we can boot)

Can we put tsc_sync_wait() back to smp_callin? So that it will be executed serially and we can get synchronized TSC with CPU? YH - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at

Re: [PATCH] x86_64: sync_tsc fix the race (so we can boot)

yhlu [EMAIL PROTECTED] writes: if using you patch, the synchronized TSC with CPU never come out. then with your patch, I add back patch that moving set callin_map from smp_callin to start_secondary. It told me can not inquire the apic for the CPU 12 Hmm. You didn't post enough of

Re: [PATCH] x86_64: sync_tsc fix the race (so we can boot)

Eric, Latest tree works. YH Booting processor 1/4 APIC 0x1 Initializing CPU#1 masked ExtINT on CPU#1 Calibrating delay using timer specific routine.. 4000.31 BogoMIPS (lpj=8000624) CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line) CPU: L2 Cache: 1024K (64 bytes/line) CPU 1(1) -

Re: [PATCH] x86_64: sync_tsc fix the race (so we can boot)

yhlu <[EMAIL PROTECTED]> writes: > I have some problem with this patch. > > YH > > On 7/28/05, yhlu <[EMAIL PROTECTED]> wrote: >> Do you mean solve the timing problem for 2 way dual core or 4 way >> single core above? As best as I can determine the problem is possible any time you have more than

Re: [PATCH] x86_64: sync_tsc fix the race (so we can boot)

I have some problem with this patch. YH On 7/28/05, yhlu <[EMAIL PROTECTED]> wrote: > Do you mean solve the timing problem for 2 way dual core or 4 way > single core above? > > YH > > On 7/27/05, Eric W. Biederman <[EMAIL PROTECTED]> wrote: > > > > sync_tsc was using smp_call_function to ask

Re: [PATCH] x86_64: sync_tsc fix the race (so we can boot)

Do you mean solve the timing problem for 2 way dual core or 4 way single core above? YH On 7/27/05, Eric W. Biederman <[EMAIL PROTECTED]> wrote: > > 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 >

Re: [PATCH] x86_64: sync_tsc fix the race (so we can boot)

Do you mean solve the timing problem for 2 way dual core or 4 way single core above? YH On 7/27/05, Eric W. Biederman [EMAIL PROTECTED] wrote: 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

Re: [PATCH] x86_64: sync_tsc fix the race (so we can boot)

I have some problem with this patch. YH On 7/28/05, yhlu [EMAIL PROTECTED] wrote: Do you mean solve the timing problem for 2 way dual core or 4 way single core above? YH On 7/27/05, Eric W. Biederman [EMAIL PROTECTED] wrote: sync_tsc was using smp_call_function to ask the boot

Re: [PATCH] x86_64: sync_tsc fix the race (so we can boot)

yhlu [EMAIL PROTECTED] writes: I have some problem with this patch. YH On 7/28/05, yhlu [EMAIL PROTECTED] wrote: Do you mean solve the timing problem for 2 way dual core or 4 way single core above? As best as I can determine the problem is possible any time you have more than 2 cpus (from

[PATCH] x86_64: sync_tsc fix the race (so we can boot)

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

[PATCH] x86_64: sync_tsc fix the race (so we can boot)

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