Messages in this thread |  | | Date | Thu, 12 Sep 2002 17:48:22 +1000 | From | Rusty Russell <> | Subject | Re: [patch] fix NMI watchdog, 2.5.34 |
| |
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/
|  |