Linus Torvalds wrote:
> [ The exception being that I think hw breakpoint support should be added
> back in - never mind that it won't work if the "native kernel" also uses
> them. Tough.
>
> If the debugger screws up the hw breakpoint state, that's a debugger
> error. I'd hope that the remote debug
On Fri, Feb 15, 2008 at 01:35:36PM +0100, Jan Kiszka wrote:
> Andi Kleen wrote:
> >> This includes things like having "breakpoint reservations" (discussed
> >> earlier) and just generally trying to add lots of infrastructure to make
> >> kgdb "fit in" to the kernel.
> >
> > I think that part is
Andi Kleen wrote:
>> This includes things like having "breakpoint reservations" (discussed
>> earlier) and just generally trying to add lots of infrastructure to make
>> kgdb "fit in" to the kernel.
>
> I think that part is actually mostly ok now (old kgdb stubs were
> much worse in this regard)
* Andi Kleen <[EMAIL PROTECTED]> wrote:
> 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.
Andi, please refrain from misrepr
On Tue, Feb 12, 2008 at 02:34:51PM -0500, Frank Ch. Eigler wrote:
> Hi -
>
> On Tue, Feb 12, 2008 at 10:20:10AM -0800, Andrew Morton wrote:
> > [...] Bear in mind that one of the things you do with kgdb is to
> > modify kernel memory [...]
>
> Just for completeness, keep in mind that one can alr
Hi -
On Tue, Feb 12, 2008 at 10:20:10AM -0800, Andrew Morton wrote:
> [...] Bear in mind that one of the things you do with kgdb is to
> modify kernel memory [...]
Just for completeness, keep in mind that one can already
do these sorts of things on a batch basis using systemtap:
> int foo;
>
On Tue, 12 Feb 2008, Andi Kleen wrote:
>
> There tend to be timeouts (e.g. softlock/nmi watchdog at least). I think
> some of the IPIs eventually time out too. In general losing a lot
> of time can lead to weird side effects.
I do agree that kgdb and watchdogs aren't like to work well togethe
On Tue, Feb 12, 2008 at 10:11:13AM -0800, Linus Torvalds wrote:
>
>
> On Tue, 12 Feb 2008, Andi Kleen 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 send
On Tue, Feb 12, 2008 at 10:20:10AM -0800, Andrew Morton wrote:
> On Tue, 12 Feb 2008 19:20:24 +0100 Andi Kleen <[EMAIL PROTECTED]> 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
> > >
On Tue, 12 Feb 2008 19:20:24 +0100 Andi Kleen <[EMAIL PROTECTED]> 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
> >
On Tue, 12 Feb 2008, Andi Kleen 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 nothi
> - 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
* Ingo Molnar <[EMAIL PROTECTED]> wrote:
> > In other words, is it perhaps possible to just *get*rid*of* that
> > "kgdb_active" and "nmicallback" and the whole multi-CPU roundup?
> > Just use a kgdb spinlock around the stuff that actually sends and
> > receives individual packets, and expect t
* Linus Torvalds <[EMAIL PROTECTED]> wrote:
> In other words, is it perhaps possible to just *get*rid*of* that
> "kgdb_active" and "nmicallback" and the whole multi-CPU roundup? Just
> use a kgdb spinlock around the stuff that actually sends and receives
> individual packets, and expect the de
Andi Kleen wrote:
>> It is more than a simple recursion check (which is already in the code)
>> because there are some conditions we can recover from. I'd rather not
>> crash the system out if it can be recovered.
>>
>
> Ok I'm trying to understand the code as you describe it. As far
> as I
On Tue, 12 Feb 2008, Ingo Molnar wrote:
>
> * Andi Kleen <[EMAIL PROTECTED]> wrote:
> >
> > Stopping all CPUs for indefinite time very much seems like "breaking a
> > correctly working system" to me. [...]
>
> well, this is a small detail, but still you are wrong, and on a
> correctly workin
* Linus Torvalds <[EMAIL PROTECTED]> wrote:
> > Yes and the session has no fixed time limit.
>
> Quite frankly, if kgdb starts doing somethign "fancy", there is no way
> I'll merge it.
>
> This includes things like having "breakpoint reservations" (discussed
> earlier) and just generally tryi
> It is more than a simple recursion check (which is already in the code)
> because there are some conditions we can recover from. I'd rather not
> crash the system out if it can be recovered.
Ok I'm trying to understand the code as you describe it. As far
as I can see (in kgdb-light-v10) it is:
> This includes things like having "breakpoint reservations" (discussed
> earlier) and just generally trying to add lots of infrastructure to make
> kgdb "fit in" to the kernel.
I think that part is actually mostly ok now (old kgdb stubs were
much worse in this regard)
I still think the ultima
On Tue, Feb 12, 2008 at 05:24:08PM +0100, Ingo Molnar wrote:
>
> * Andi Kleen <[EMAIL PROTECTED]> wrote:
>
> > Anyways the slight risk of the other CPUs eventually recovering would
> > seem a acceptable trade off versus not being able to use the debugger
> > to debug the system with hanging CPU
On Tue, 12 Feb 2008, Andi Kleen wrote:
> >
> > KGDB does a very straightforward "all CPUs enter controlled state"
> > transition when the session begins, and at the end an "all CPUs
> > continue" transition.
>
> Yes and the session has no fixed time limit.
Quite frankly, if kgdb starts doing
* Andi Kleen <[EMAIL PROTECTED]> wrote:
> Anyways the slight risk of the other CPUs eventually recovering would
> seem a acceptable trade off versus not being able to use the debugger
> to debug the system with hanging CPUs.
see? There's the difference between us. The initial merge of KGDB doe
Andi Kleen wrote:
>> Basically when you reach this chunk of code it is before the hand off
>> to the source debugger. We cannot continue because there was a
>> breakpoint in a part of the system kgdb was using while doing its
>> normal work. The reality is that KGDB is not self contained. It
>>
On Tue, Feb 12, 2008 at 07:59:02AM -0600, Jason Wessel wrote:
>
> I doubt the .config you posted was the one you used, because there were
> no KGDB options specified at all.
indeed it was of a parisc.. :)
here is the right one:
#
# Automatically generated make config: don't edit
# Linux kernel v
On Tue, Feb 12, 2008 at 04:28:46PM +0100, Ingo Molnar wrote:
>
> * Andi Kleen <[EMAIL PROTECTED]> wrote:
>
> > > do spinning for now: we dont _ever_ want to break a correctly
> > > working system with kgdb.
> >
> > Stopping all CPUs for indefinite time very much seems like "breaking a
> > corr
* Andi Kleen <[EMAIL PROTECTED]> wrote:
> > do spinning for now: we dont _ever_ want to break a correctly
> > working system with kgdb.
>
> Stopping all CPUs for indefinite time very much seems like "breaking a
> correctly working system" to me. [...]
well, this is a small detail, but still y
Ingo Molnar <[EMAIL PROTECTED]> writes:
> * Andi Kleen <[EMAIL PROTECTED]> wrote:
>
>> On Tue, Feb 12, 2008 at 01:38:39PM +0100, Ingo Molnar wrote:
>> > So unless i forgot about something (please yell if so), it seems to
>> > me kgdb is now pretty ready for an upstream merge.
>>
>> I don't know
* Andi Kleen <[EMAIL PROTECTED]> wrote:
> On Tue, Feb 12, 2008 at 01:38:39PM +0100, Ingo Molnar wrote:
> > So unless i forgot about something (please yell if so), it seems to
> > me kgdb is now pretty ready for an upstream merge.
>
> I don't know -- I have not reread everything. Please don't co
> Basically when you reach this chunk of code it is before the hand off
> to the source debugger. We cannot continue because there was a
> breakpoint in a part of the system kgdb was using while doing its
> normal work. The reality is that KGDB is not self contained. It
> relies on some external
Andi Kleen wrote:
>> We might be best served to add a comment to explain the purpose of
>> kgdb_arch_pc() and put it in the optional implementation function
>> headers in include/linux/kgdb.h
>>
>> On some archs certain exceptions do not report the address that the
>> exception occurred at when you
On Tue, Feb 12, 2008 at 07:30:15AM -0600, Jason Wessel wrote:
> This is not a technical argument, but I am not a big fan of hard hanging
> the system if you cannot sync all the CPUs.
Me neither.
> We might be best served to add a comment to explain the purpose of
> kgdb_arch_pc() and put it in t
Domenico Andreoli wrote:
> Hi,
>
> On Tue, Feb 12, 2008 at 12:27:47PM +0100, Ingo Molnar wrote:
>
>> this is kgdb-light, version -v10 (against Linus-latest), and can be
>> pulled from:
>>
>>git://git.kernel.org/pub/scm/linux/kernel/git/mingo/linux-2.6-kgdb.git
>>
>> shortlog, diffstat and f
Ingo Molnar wrote:
> * Andi Kleen <[EMAIL PROTECTED]> wrote:
>
>
>>> i went for correctness and simplicity first. If a system is hung,
>>> the debugging CPU might hang too at any time. A timeout on the other
>>> hand introduces the possibility of a 'dead' CPU just coming back to
>>> life afte
Hi,
On Tue, Feb 12, 2008 at 12:27:47PM +0100, Ingo Molnar wrote:
>
> this is kgdb-light, version -v10 (against Linus-latest), and can be
> pulled from:
>
>git://git.kernel.org/pub/scm/linux/kernel/git/mingo/linux-2.6-kgdb.git
>
> shortlog, diffstat and full patch can be found further below
On Tue, Feb 12, 2008 at 01:38:39PM +0100, Ingo Molnar wrote:
> So unless i forgot about something (please yell if so), it seems to me
> kgdb is now pretty ready for an upstream merge.
I don't know -- I have not reread everything. Please don't consider
my comments as approval of the code base. I s
i'm glad that there are no other valid-looking (to me) objections left
against kgdb-light -v10, other than "it would be nice to have more kgdb
functionality" and "it would be nice to rewrite the parser", right?
:-)
(It seems we do have a fundamental disagreement about how kgdb should
act: in m
On Tue, Feb 12, 2008 at 12:27:47PM +0100, Ingo Molnar wrote:
> > > + return pid_max + raw_smp_processor_id();
> >
> > Whatever that shadowpid is. [...]
>
> GDB wants to track threads, but on the Linux side each idle task has PID
> 0, so GDB cannot track them. The shadow PID is this remapped spac
37 matches
Mail list logo
