All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andi Kleen <andi@firstfloor.org>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: Andi Kleen <andi@firstfloor.org>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Ingo Molnar <mingo@elte.hu>,
	linux-kernel@vger.kernel.org,
	"Frank Ch. Eigler" <fche@redhat.com>,
	Roland McGrath <roland@redhat.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	"H. Peter Anvin" <hpa@zytor.com>
Subject: Re: [git pull] kgdb-light -v10
Date: Tue, 12 Feb 2008 20:16:59 +0100	[thread overview]
Message-ID: <20080212191659.GA6458@one.firstfloor.org> (raw)
In-Reply-To: <20080212102010.d88886f3.akpm@linux-foundation.org>

On Tue, Feb 12, 2008 at 10:20:10AM -0800, Andrew Morton wrote:
> On Tue, 12 Feb 2008 19:20:24 +0100 Andi Kleen <andi@firstfloor.org> wrote:
> 
> > >  - the kgdb commands should always act on the *current* CPU only
> > >  - add one command that says "switch over to CPU #n" which just releases 
> > >    the current CPU and sends an IPI to that CPU #n (no timeouts, no 
> > >    synchronous waiting, no nothing - it's like a "continue", but with a 
> > >    "try to get the other CPU to stop"
> > 
> > The problem I see here is that the kernel tends to get badly confused
> > if one CPU just stops responding. At some point someone does an global
> > IPI and that then hangs.
> 
> Yes.  A stopped CPU is very visible and hence can change the behaviour of
> the system which is being tested.
> 
> >  You would need to hotunplug the CPU which
> > is theoretically possible, but quite intrusive. Or maybe the "isolate CPUs 
> > in cpusets" frame work someone posted recently on l-k could be used.  Still 
> > would probably have all kinds of tricky issues and races.
> 
> I don't think you'd want to be poking around in kernel internals while some
> of the CPUs are continuing to run.  It sounds rather creepy.  You want
> everything to stop.  Including time-related things.

Note I wrote the one above only as a reply to Linus' proposal, not
because I was advocating "live debugging" (or rather I think if you want
that just use gdb vmlinux /proc/kcore) 

I agree with you in principle, but what do you do if one of the CPUs doesn't 
answer? 

Ingo seems to think it's ok for the debugger then to just hang too,
I think it should eventually time out and debug anyways.

Also there are some limits on how much the system should be frozen
down. For example if you're strict about this requirement you
would need to require full DMA quiescence (like kexec does). But that's
obvious not a good idea for the debugger. So it's always shades
of gray, not black/white.

What I find strange with the current patch is that it goes to extreme
measures to stop the CPUs (will hang forever), but not do the whole
thing (DMA quiescence too) 

-Andi


  reply	other threads:[~2008-02-12 18:41 UTC|newest]

Thread overview: 52+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-02-11  1:53 kgdb in git-x86#mm review Andi Kleen
2008-02-11 15:32 ` Frank Ch. Eigler
2008-02-11 16:11   ` Andi Kleen
2008-02-11 16:21   ` [git pull] kgdb-light -v8, (was: Re: kgdb in git-x86#mm review) Ingo Molnar
2008-02-11 16:41     ` [git pull] kgdb-light -v8, Jan Kiszka
2008-02-11 16:54       ` Ingo Molnar
2008-02-11 17:10     ` [git pull] kgdb-light -v8, (was: Re: kgdb in git-x86#mm review) Andi Kleen
2008-02-11 23:03       ` [git pull] kgdb-light -v9 Ingo Molnar
2008-02-12 10:03         ` Andi Kleen
2008-02-12  9:35           ` Sam Ravnborg
2008-02-12 10:26           ` Roland McGrath
2008-02-12 10:34             ` Ingo Molnar
2008-02-12 11:27           ` [git pull] kgdb-light -v10 Ingo Molnar
2008-02-12 12:19             ` Andi Kleen
2008-02-12 12:38               ` Ingo Molnar
2008-02-12 13:30                 ` Jason Wessel
2008-02-12 14:39                   ` Andi Kleen
2008-02-12 14:35                     ` Jason Wessel
2008-02-12 15:36                       ` Andi Kleen
2008-02-12 16:21                         ` Jason Wessel
2008-02-12 17:10                           ` Andi Kleen
2008-02-12 16:48                             ` Jason Wessel
2008-02-12 13:50                 ` Andi Kleen
2008-02-12 15:16                   ` Ingo Molnar
2008-02-12 15:28                     ` Andi Kleen
2008-02-12 15:28                   ` Ingo Molnar
2008-02-12 16:11                     ` Andi Kleen
2008-02-12 16:24                       ` Ingo Molnar
2008-02-12 17:01                         ` Andi Kleen
2008-02-12 16:25                       ` Linus Torvalds
2008-02-12 16:42                         ` Ingo Molnar
2008-02-12 17:07                         ` Andi Kleen
2008-02-15 12:35                           ` [RFC][PATCH] modular kgdb-light (was: Re: [git pull] kgdb-light -v10) Jan Kiszka
2008-02-15 13:32                             ` Andi Kleen
2008-02-15 20:24                               ` [RFC][PATCH] modular kgdb-light Jason Wessel
2008-02-15 20:36                         ` [git pull] kgdb-light -v10 Jason Wessel
2008-02-12 16:46                     ` Linus Torvalds
2008-02-12 17:01                       ` Ingo Molnar
2008-02-12 17:10                         ` Ingo Molnar
2008-02-12 18:20                       ` Andi Kleen
2008-02-12 18:11                         ` Linus Torvalds
2008-02-12 19:22                           ` Andi Kleen
2008-02-12 19:01                             ` Linus Torvalds
2008-02-12 18:20                         ` Andrew Morton
2008-02-12 19:16                           ` Andi Kleen [this message]
2008-02-12 21:01                             ` Ingo Molnar
2008-02-12 19:34                           ` Frank Ch. Eigler
2008-02-12 20:16                             ` Andi Kleen
2008-02-12 13:18             ` Domenico Andreoli
2008-02-12 13:59               ` Jason Wessel
2008-02-12 15:45                 ` Domenico Andreoli
2008-02-11 16:03 ` kgdb in git-x86#mm review Mark Lord

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=20080212191659.GA6458@one.firstfloor.org \
    --to=andi@firstfloor.org \
    --cc=akpm@linux-foundation.org \
    --cc=fche@redhat.com \
    --cc=hpa@zytor.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=roland@redhat.com \
    --cc=tglx@linutronix.de \
    --cc=torvalds@linux-foundation.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.