On Mon, Jan 17, 2005 at 01:34:24PM +1100, Rusty Russell wrote:
> On Sat, 2005-01-15 at 05:09 +0100, Andi Kleen wrote:
> > Fix boot up SMP race in timer setup on i386/x86-64.
>
> How's this? Didn't do x86-64, but tested on i386.
Looks ok to me. You're right that the commenced check should
do the
On Sat, 2005-01-15 at 05:09 +0100, Andi Kleen wrote:
> Fix boot up SMP race in timer setup on i386/x86-64.
How's this? Didn't do x86-64, but tested on i386.
Rusty.
Name: x86: no interrupts from secondary CPUs until officially online
Status: Tested on dual Pentium II, 2.6.11-rc1-bk2
Signed-off-b
On Sun, 2005-01-16 at 06:34 +0100, Andi Kleen wrote:
> On Sun, Jan 16, 2005 at 03:20:47PM +1100, Rusty Russell wrote:
> > But adding a bizarro "pre-prepare" notifier verged on nonsensical 8(. I
>
> I don't see the big issue. Preparse is just not as early as you thought.
State machine for non-boo
On Sun, Jan 16, 2005 at 03:20:47PM +1100, Rusty Russell wrote:
> On Sat, 2005-01-15 at 08:59 +0100, Andi Kleen wrote:
> > I think my patch is better. It at least keeps all the
> > baggage out of the normal run paths. Doing this check at each timer
> > interrupt
> > doesn't make much sense.
>
>
On Sat, 2005-01-15 at 08:59 +0100, Andi Kleen wrote:
> I think my patch is better. It at least keeps all the
> baggage out of the normal run paths. Doing this check at each timer interrupt
> doesn't make much sense.
It doesn't penalize the architectures which do the right thing already.
If this
On Sat, Jan 15, 2005 at 06:34:54PM +1100, Rusty Russell wrote:
> > I shortly considered redoing the boot process, but then it looked
> > too risky to me.
> >
> > e.g. I guess on x86-64 it wouldn't be that difficult, just a bit of work,
> > but on i386 with all the weird hardware it could be quit
Rusty Russell <[EMAIL PROTECTED]> wrote:
>
> static inline void do_timer_interrupt_hook(struct pt_regs *regs)
> {
> -do_timer(regs);
> +/* i386 brings up CPU before core is setup. */
> +if (unlikely(!cpu_online(smp_processor_id(
> +jiffies64++;
> +else
> +
On Sat, 2005-01-15 at 06:23 +0100, Andi Kleen wrote:
> I shortly considered redoing the boot process, but then it looked
> too risky to me.
>
> e.g. I guess on x86-64 it wouldn't be that difficult, just a bit of work,
> but on i386 with all the weird hardware it could be quite destabilizing.
> B
> I don't get it. By the time the secondaries enter the idle loop, they've
> already run init_timers_cpu() anyway. You patch doesn't address a
The notifier uns only after smp_prepare_cpus and then all the synchronization
is long done.
> secondary taking a timer interrupt prior to the BP havin
Andi Kleen <[EMAIL PROTECTED]> wrote:
>
> On Fri, Jan 14, 2005 at 10:28:41PM -0800, Andrew Morton wrote:
> > Andi Kleen <[EMAIL PROTECTED]> wrote:
> > >
> > > This fixes a long standing race in 2.6 i386/x86-64 SMP boot.
> > > The per CPU timers would only get initialized after an secondary
> > >
10 matches
Mail list logo
