From: Andi Kleen <andi@xxxxxxxxxxxxxx> Date: Wed, 24 Jun 2009 12:52:23 +0200 > On Wed, Jun 24, 2009 at 03:32:33AM -0700, David Miller wrote: >> From: Andi Kleen <andi@xxxxxxxxxxxxxx> >> Date: Wed, 24 Jun 2009 12:23:25 +0200 >> >> >> And similarly to sparc64, if that 5+ second qla2xxx interrupt >> >> sequence happens after the tick_nohz_stop_sched_tick() call >> >> we can run into the same situation. >> > >> > Yes it would be probably safer to do the tick disabling with >> > interrupts off already. >> >> That only makes sense if you're really putting the cpu to sleep >> until an interrupt or similar happens. > > That is what the idle loop is supposed to do, isn't it? Some sparc64 cpu's don't have a yield, and therefore can't truly "sleep" during this loop. That's what I'm talking about. >> > These days NMI watchdog is not used much on x86 anymore because it's >> > default off, so probably people never noticed that. >> >> I really didn't want to provide the feature that way on sparc64 which >> is why I made it on by default. It would be interesting to reconsider >> x86's default, perhaps even only on a trial basis in -next. > > The reason it was turned off is that there are a few systems (e.g. > laptops from a particular vendor) which don't handle NMIs correctly > in the platform. When the NMI happens while SMI is active > they hang. Also there were a few other strange problems > on other systems that went away when it was disabled. I wonder how many of those "few other strange problems" were of the variety I'm diagnosing here :-) Yes, it's a messy problem to turn on by default on x86 then. Is this realm of systems-with-NMI-issues exclusive to x86-32 or would it be more doable to turn it on by default for 64-bit x86 builds? -- To unsubscribe from this list: send the line "unsubscribe sparclinux" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
