All of lore.kernel.org
 help / color / mirror / Atom feed
From: ZAK Magnus <zakmagnus@google.com>
To: Don Zickus <dzickus@redhat.com>
Cc: linux-kernel@vger.kernel.org, Ingo Molnar <mingo@elte.hu>,
	Mandeep Singh Baines <msb@chromium.org>
Subject: Re: [PATCH v3 2/2] Make hard lockup detection use timestamps
Date: Fri, 29 Jul 2011 16:12:32 -0700	[thread overview]
Message-ID: <CAAuSN93ouWrPn9xWb9Zd3E2Dp0hQxC4JmFH1utbyy1_aMnfkLA@mail.gmail.com> (raw)
In-Reply-To: <20110729205538.GD14343@redhat.com>

Are you saying that any call to printk() will touch the watchdogs? I
wasn't aware of that and it doesn't seem to comply with my
observations too well, either. Then again, at the moment I don't
understand some of the things I'm currently seeing so I could just be
wrong.

On Fri, Jul 29, 2011 at 1:55 PM, Don Zickus <dzickus@redhat.com> wrote:
> On Thu, Jul 28, 2011 at 05:16:00PM -0700, ZAK Magnus wrote:
>> No news?
>>
>> I've been testing and looking into issues and I realized dump_stack()
>> calls touch_nmi_watchdog(). That wrecks what the patch is trying to do
>> so I'm changing it to save the trace and print it later after the
>> stall has completed. This would also resolve some other things you
>> were saying weren't so good. Hopefully the logic is similar enough
>> that some things you may have learned still apply.
>
> So yeah, the acting of printing was resesting the softlockup counter and
> delaying it forever.  In parallel, rcu has its own stall detector that was
> going off after a minute or two.
>
> Once I routed the printk to trace_printk and disabled dump_stack,
> everything started working as expected.
>
> Now the question is how to avoid shooting ourselves in the foot by
> printk'ing a message without resetting the hard/soft lock watchdogs.
>
> I'll have to think about how to do that.  If you can come up with any
> ideas let me know.
>
> We almost need a quiet dump_stack that dumps to a buffer instead of the
> console.  But I am not sure that is worth the effort.
>
> Hmm.
>
> Cheers,
> Don
>

  reply	other threads:[~2011-07-29 23:44 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-07-21 18:11 [PATCH v3 2/2] Make hard lockup detection use timestamps Alex Neronskiy
2011-07-22 19:53 ` Don Zickus
2011-07-22 22:34   ` ZAK Magnus
2011-07-25 12:44     ` Don Zickus
2011-07-29  0:16       ` ZAK Magnus
2011-07-29 13:10         ` Don Zickus
2011-07-29 20:55         ` Don Zickus
2011-07-29 23:12           ` ZAK Magnus [this message]
2011-08-01 12:52             ` Don Zickus
2011-08-01 18:33               ` ZAK Magnus
2011-08-01 19:24                 ` Don Zickus
2011-08-01 20:11                   ` ZAK Magnus
2011-08-03 18:27                     ` ZAK Magnus
2011-08-03 19:44                       ` Don Zickus
2011-08-03 19:11                     ` Don Zickus

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAAuSN93ouWrPn9xWb9Zd3E2Dp0hQxC4JmFH1utbyy1_aMnfkLA@mail.gmail.com \
    --to=zakmagnus@google.com \
    --cc=dzickus@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=msb@chromium.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.