On Thu, Jun 29, 2017 at 11:44:06AM -0400, Don Zickus wrote: > On Wed, Jun 28, 2017 at 01:14:04PM -0700, Andi Kleen wrote: > > It can be a useful debugging tool for a specific class of bugs: > > when kernel software is looping forever. > > > > But if that happens does it really matter how many iterations the > > loop does before it is stopped? > > > > Even the current timeout is essentially eternity in CPU time, and 3x > > eternity is still eternity. > > That isn't true. We have customers that test the accuracy and file bugs. I > had to write a RHEL whitepaper a number of years ago explaining why the > softlockup took 62 seconds to fire instead of 60. Ok that makes sense. It seems like a broken QA test from your customer, not a real issue, but yes explaining and documenting that can be difficult. > > The question is, if the real solution is going to take a while, what is the > least sucky solution for now? Or how do we minimize it to a specific class > of Intel boxes. You can't minimize it because there's no forward looking solution to detect a large turbo range, and also whatever issue you have in the generic case would apply to them too. Thomas' patch to modulate the frequency seemed reasonable to me. It made the NMI watchdog depend on accurate ktime, but that's probably ok. -Andi