Oh.
On 8/12/05, Andi Kleen <[EMAIL PROTECTED]> wrote:
> On Fri, Aug 12, 2005 at 09:18:07AM -0700, yhlu wrote:
> > good, I will produce one patch next week.
>
> I already did it in my tree.
>
> -Andi
>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a mess
On Fri, Aug 12, 2005 at 09:18:07AM -0700, yhlu wrote:
> good, I will produce one patch next week.
I already did it in my tree.
-Andi
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.o
good, I will produce one patch next week.
YH
On 8/12/05, Andi Kleen <[EMAIL PROTECTED]> wrote:
> On Thu, Aug 11, 2005 at 11:59:21PM -0700, yhlu wrote:
> > andi,
> >
> > is it possible for
> > after the AP1 call_in is done and before AP1 get in tsc_sync_wait
> > The AP2 call_in done. and then AP1
On Thu, Aug 11, 2005 at 11:59:21PM -0700, yhlu wrote:
> andi,
>
> is it possible for
> after the AP1 call_in is done and before AP1 get in tsc_sync_wait
> The AP2 call_in done. and then AP1 get in tsc_sync_wait and before it
> done, AP2 get in tsc_sync_wait too.
>
> sync_master can not figure ou
andi,
it seems ia64 is after done with the tsc_sync then set the callin_map.
YH
if (!(sal_platform_features & IA64_SAL_PLATFORM_FEATURE_ITC_DRIFT)) {
/*
* Synchronize the ITC with the BP. Need to do this
after irqs are
* enabled because
andi,
is it possible for
after the AP1 call_in is done and before AP1 get in tsc_sync_wait
The AP2 call_in done. and then AP1 get in tsc_sync_wait and before it
done, AP2 get in tsc_sync_wait too.
sync_master can not figure out from AP1 or AP2 because only have
go[MASTER] and go{SLAVE].
YH
On
On Wed, Aug 10, 2005 at 05:43:23PM -0700, yhlu wrote:
> Yes, I mean more aggressive
>
> static void __init smp_init(void)
> {
> unsigned int i;
>
> /* FIXME: This should be done in userspace --RR */
> for_each_present_cpu(i) {
> if (num_online_cpus() >= max
Yes, I mean more aggressive
static void __init smp_init(void)
{
unsigned int i;
/* FIXME: This should be done in userspace --RR */
for_each_present_cpu(i) {
if (num_online_cpus() >= max_cpus)
break;
if (!cpu_online(i)
On Wed, Aug 10, 2005 at 05:23:31PM -0700, yhlu wrote:
> I wonder if you can make the bsp can start the APs callin in the same
> time, and make it asynchronous, So you make spare 2s or more.
The setting of cpu_callin_map in the AP could be moved earlier yes.
But it's not entirely trivial because th
I wonder if you can make the bsp can start the APs callin in the same
time, and make it asynchronous, So you make spare 2s or more.
YH
On 8/10/05, yhlu <[EMAIL PROTECTED]> wrote:
> In LinuxBIOS, we could init_ecc asynchronous and the time reduced from
> 8x to 2.1x for 8 ways system. 1x mean 5s fo
In LinuxBIOS, we could init_ecc asynchronous and the time reduced from
8x to 2.1x for 8 ways system. 1x mean 5s for 4G in one cpu. If 16G
will take 20s.
for TSC_SYNC asynchronous maybe you can get back 0.1s...
YH
On 8/10/05, Andi Kleen <[EMAIL PROTECTED]> wrote:
> > So my patch still can be used
> So my patch still can be used with Eric's, It just serialize the
> TSC_SYNC between cpu.
>
> I wonder it you can refine to make TSC_SYNC serialize that beteen CPU.
> That will make
> CPU X:synchronized TSC ...
> in fixed postion and timming.
Why would we want that?
Boot time is critical so i
Andi Kleen wrote:
On Wed, Aug 10, 2005 at 04:14:19PM -0700, Mike Waychison wrote:
YhLu wrote:
andi,
please refer the patch, it will move cpu_set(, cpu_callin_map) from
smi_callin to start_secondary.
This patch fixes an apparent race / lockup on our 2-way dual cores (when
applied against
andi,
you can see the difference with the patch
Booting processor 1/1 rip 6000 rsp 810181c61f58
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 Ca
Mike Waychison wrote:
This patch fixes an apparent race / lockup on our 2-way dual cores (when
applied against 2.6.12.3). The machine was locking up after
"Initializing CPU#2".
the better ways is to use the patch from Eric that Andi posted to stable
yesterday:
http://x86-64.org/lis
On Wed, Aug 10, 2005 at 04:14:19PM -0700, Mike Waychison wrote:
> YhLu wrote:
> >andi,
> >
> >please refer the patch, it will move cpu_set(, cpu_callin_map) from
> >smi_callin to start_secondary.
>
>
> This patch fixes an apparent race / lockup on our 2-way dual cores (when
> applied against 2.6
PU 0 (last diff -4 cycles, maxerr 1097 cycles)
Brought up 4 CPUs
-Original Message-
From: YhLu
Sent: Wednesday, July 06, 2005 3:25 PM
To: Andi Kleen
Cc: Peter Buckingham; linux-kernel@vger.kernel.org
Subject: 2.6.13-rc2 with dual way dual core ck804 MB
andi,
the core1/node0 take a long
ux-kernel@vger.kernel.org;
> '[EMAIL PROTECTED]'
> Subject: RE: 2.6.13-rc2 with dual way dual core ck804 MB
>
> andi,
>
> please refer the patch, it will move cpu_set(,
> cpu_callin_map) from smi_callin to start_secondary.
>
> ---
> /home/yhlu/xx1/linux-2
2, boot_cpu_id= 00
sync_master: 2 smp_processor_id() = 00, boot_cpu_id= 00
CPU 3: synchronized TSC with CPU 0 (last diff -4 cycles, maxerr 1097 cycles)
Brought up 4 CPUs
> -Original Message-
> From: YhLu
> Sent: Wednesday, July 06, 2005 3:25 PM
> To: Andi Kleen
> Cc: Peter Buckingham
andi,
the core1/node0 take a long while to get TSC synchronized. Is it normal?
i guess
"CPU 1: synchronized TSC with CPU 0" should be just after "CPU 1: Syncing
TSC to CPU0"
YH
cpu 1: setting up apic clock
cpu 1: enabling apic timer
CPU 1: Syncing TSC to CPU 0.
CPU has booted.
waiting for cpu
20 matches
Mail list logo
