On Thu, Jun 29, 2017 at 09:12:20AM -0700, Andi Kleen wrote: > 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, Agreed. > but yes explaining and documenting that can be difficult. Yes. > > > > > 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. Ok, did Kan finish testing this patch (with the small fix on top)? Cheers, Don