Re: [BUG] x86_udelay_tsc not honoring notsc

[Martin J. Bligh]

> 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.