Messages in this thread | | | Date | Thu, 19 Sep 2002 21:20:25 -0700 | From | "Martin J. Bligh" <> | Subject | Re: [BUG] x86_udelay_tsc not honoring notsc |
| |
> At some point in the past, I wrote: >>> If so, it's probably not worth mucking around with the bootstrap >>> sequence to deal with something this minor. It's not like it can >>> be mistaken for having hung, as console output is very consistent. >>> Maybe we should give NUMA-Q a couple of minutes instead of 5s? > > On Thu, Sep 19, 2002 at 09:00:09PM -0700, Martin J. Bligh wrote: >> Nah, just recode the boot sequence to make them all boot in >> parallel ;-) > > Do you think cpu wakeup alone could be doing this? If so, then doing > that bit would be relatively isolated (though a slightly larger diff > than changing an NMI oopser timeout).
Seems odd that you didn't get it in previous versions ... ? But running the NMI oops detection whilst stealing NMIs in order to bootstrap the CPUs is probably a Bad Idea (tm).
> Does 0xFF broadcast cluster, broadcast low nybble work or is waking > them a cluster at a time required? This thing is not swift to boot...
Well, you don't want to send an NMI to yourself (the BSP), I presume? That would probably make it unhappy ;-) The NMIs have to be logically addressed, which precludes the allbutself thingy, IIRC. So you have a choice of serialised unicast (which is probably quite fast enough) or cluster at a time, being careful to exclude yourself when you do the BSP's cluster.
But I think you'd be far better off just disabling the NMI oopser until we've booted - the dual use is too much nefarious incest for my liking.
M. - 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/
| |