On Tue, 10 Sep 2002 20:11:49 +0200 (SAST)
Zwane Mwaikambo <zwane@mwaikambo.name> wrote:
> On Tue, 10 Sep 2002, Rusty Russell wrote:
>
> > Well spotted. You might want to test the following patch which
> > catches calls to smp_call_function() before the cpus are actually
> > online. I ran a variant on my (crappy, old, SMP) box before I sent
> > the patch to Linus, and all I saw was the (harmless) tlb_flush.
>
> hmm...
>
> > diff -urNp --exclude TAGS -X /home/rusty/current-dontdiff --minimal linux-2.5.34/arch/i386/kernel/smpboot.c working-2.5.34-smp_call_cpus/arch/i386/kernel/smpboot.c
> > --- linux-2.5.34/arch/i386/kernel/smpboot.c Sun Sep 1 12:22:57 2002
> > +++ working-2.5.34-smp_call_cpus/arch/i386/kernel/smpboot.c Tue Sep 10 14:35:07 2002
> > @@ -1218,7 +1218,10 @@ int __devinit __cpu_up(unsigned int cpu)
> > return 0;
> > }
> >
> > +unsigned int smp_done = 0;
> > +
> > void __init smp_cpus_done(unsigned int max_cpus)
> > {
> > zap_low_mappings();
> > + smp_done = 1;
>
> I've got an SMP box which dies reliably at zap_low_mappings, i wonder if
> this could be the same problem. My BSP sits spinning on the completion
> check.
Hmmm, I can't see how: you mean it hangs in flush_tlb_all() (waiting for the
ack in smp_call_function()?). If so, that seems really wierd. You could add
a printk("here: %u\n", smp_processor_id()) in flush_tlb_all_ipi() to see which
CPU isn't getting it...
Strange,
Rusty.
-- there are those who do and those who hang on and you don't see too many doers quoting their contemporaries. -- Larry McVoy - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sun Sep 15 2002 - 22:00:28 EST