Messages in this thread | | | Date | Wed, 28 Mar 2007 10:51:18 -0400 | From | Prarit Bhargava <> | Subject | Re: [patch 3/4] Locally disable the softlockup watchdog rather than touching it |
| |
Jeremy Fitzhardinge wrote: > Prarit Bhargava wrote: > >> I don't like the idea of having touch_softlockup_watchdog exported >> with your new code -- we still have two methods of effecting the >> softlockup watchdog and that's confusing and its going to cause >> serious problems down the road. >> > > It's legacy. There are a few places where it wasn't obvious to me how > to replace the touch_softlockup_watchdog, so I left them for now. But > ideally I think they should all go away. > > >> Is there a reason that you're pushing the enable/disable? All the >> cases called out seem to be just fine with calls to either effect that >> CPU's softlockup watchdog or doing all CPU's softlockup watchdogs. >> > > Doing all CPUs is meaningless to me. How does that make sense? It >
You don't have to do them all -- you could do one with (as in my previous patch -- which I'm not married to BTW ;) )
touch_cpu_softlockup_watchdog()
and all with
touch_softlockup_watchdog()
> Zach has reported seeing spurious softlockup messages on idle machines > running under a hypervisor. And there was also the discussion about how > to deal with a flash update system in which all CPUs are taken over by > the bios for a long period of time, which was causing softlockup to > trigger. It seemed to me that these could all be dealt with in much the > same way, and that disable/enable semantics for dealing with > long-running timer holdoffs is more natural than trying to work out how > to periodically touch the watchdog timer. > > But wouldn't a call to touch_[cpu_]softlockup_watchdog at the end of the flash update fix the problem? And ditto for all other areas of the kernel where we know we're holding off scheduling?
P.
> J > - 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/
| |