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
* Roland McGrath <[EMAIL PROTECTED]> wrote:
> At any rate, I think it would be good if the hw breakpoint support in
> kgdb were chopped out into a separate patch. First make kgdb work
> with no code touching debug registers at all. Then a second patch can
> add the hw breakpoint support. Th
> You silently overwrite any user ptrace hw breakpoints right? To do it cleanly
> would still require a reservation frame work.
There was work underway on that before (hw_breakpoint). I'm not entirely
sure you want to use fancy stuff like that in kgdb. It's nice for kgdb to
be as self-contained
>
> > +/**
> > + * kgdb_arch_handle_exception - Handle architecture specific GDB packets.
>
> All the kerneldoc comments are useless if you don't add the file
> to Documentation/DocBook/*.tmpl
1) The content is valid no matter the formatting
2) It is a well known format
3) And it is widely used
On Tue, Feb 12, 2008 at 12:03:35AM +0100, Ingo Molnar wrote:
> > The synchronization code looks as bad as it was before.
First nobody answered the "kgdb clean enough for a module"
high level question yet. Is it good enough for that?
>
> i reworked and cleaned up all the kgdb locking code complet
* Jan Kiszka <[EMAIL PROTECTED]> wrote:
> Domenico Andreoli wrote:
> > On Sun, Feb 10, 2008 at 11:20:26PM +0100, Ingo Molnar wrote:
> >> this is -v7 of the KGDB-light tree, which can be pulled from:
> >>
> >> git://git.kernel.org/pub/scm/linux/kernel/git/mingo/linux-2.6-kgdb.git
> >
> > my git
On Mon, Feb 11, 2008 at 05:55:07PM +0100, Jan Kiszka wrote:
> Domenico Andreoli wrote:
> > On Sun, Feb 10, 2008 at 11:20:26PM +0100, Ingo Molnar wrote:
> >> this is -v7 of the KGDB-light tree, which can be pulled from:
> >>
> >> git://git.kernel.org/pub/scm/linux/kernel/git/mingo/linux-2.6-kgdb.g
Domenico Andreoli wrote:
> On Sun, Feb 10, 2008 at 11:20:26PM +0100, Ingo Molnar wrote:
>> this is -v7 of the KGDB-light tree, which can be pulled from:
>>
>> git://git.kernel.org/pub/scm/linux/kernel/git/mingo/linux-2.6-kgdb.git
>
> my git hangs on this..
Just booting? Or using the debugger? I
* Jan Kiszka <[EMAIL PROTECTED]> wrote:
> Ingo Molnar wrote:
> > In any case, if there are any open issues we are very much ready and
> > willing to address them now or after any potential upstream merge of
> > this codebase. This has meanwhile become one of the best-reviewed pieces
> > of ker
Ingo Molnar wrote:
> In any case, if there are any open issues we are very much ready and
> willing to address them now or after any potential upstream merge of
> this codebase. This has meanwhile become one of the best-reviewed pieces
> of kernel code in living memory ;-)
>
I spotted one... :
> after a quick glance i'm happy to conclude that all but one of Andi's
At least the weird in_interrupt_stack() code seems to be still
in there.
I also still see a lot of open coded hex manipulation.
The synchronization code looks as bad as it was before.
The getthread magic pids are also stil
On Sun, Feb 10, 2008 at 11:20:26PM +0100, Ingo Molnar wrote:
>
> this is -v7 of the KGDB-light tree, which can be pulled from:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/mingo/linux-2.6-kgdb.git
my git hangs on this..
-[ Domenico Andreoli, aka cavok
--[ http://www.dandreoli.com/gp
* Jan Kiszka <[EMAIL PROTECTED]> wrote:
> Maybe, maybe not. I followed the comment in the original code, saying
> that we need word-wise access for I/O memory poking. Can I assume
> across a all archs that __copy_to/from_user will not perform byte
> accesses if count is 2, 4, or 8? I would be
* Ingo Molnar <[EMAIL PROTECTED]> wrote:
> all other places already use probe_kernel_{read|write}. (Now, there
> are a few stray TASK_SIZE checks still, i'll double check them and
> convert them to access_ok() checks.)
all the TASK_SIZE checks relate to the soft breakpoint write accesses.
and
* Linus Torvalds <[EMAIL PROTECTED]> wrote:
> > +static int kgdb_get_mem(char *addr, unsigned char *buf, int count)
> > {
> > + if ((unsigned long)addr < TASK_SIZE)
> > + return -EFAULT;
> >
> > + return probe_kernel_read(buf, addr, count);
> > }
>
> Ok, so this is a pretty fun
Linus Torvalds wrote:
On Sun, 10 Feb 2008, Jan Kiszka wrote:
+static int kgdb_get_mem(char *addr, unsigned char *buf, int count)
{
+ if ((unsigned long)addr < TASK_SIZE)
+ return -EFAULT;
+ return probe_kernel_read(buf, addr, count);
}
Ok, so this is a pretty function
* Linus Torvalds <[EMAIL PROTECTED]> wrote:
> > +static int kgdb_get_mem(char *addr, unsigned char *buf, int count)
> > {
> > + if ((unsigned long)addr < TASK_SIZE)
> > + return -EFAULT;
> >
> > + return probe_kernel_read(buf, addr, count);
>
> Ok, so this is a pretty function a
On Sun, 10 Feb 2008, Jan Kiszka wrote:
>
> +static int kgdb_get_mem(char *addr, unsigned char *buf, int count)
> {
> + if ((unsigned long)addr < TASK_SIZE)
> + return -EFAULT;
>
> + return probe_kernel_read(buf, addr, count);
> }
Ok, so this is a pretty function after all
* Jan Kiszka <[EMAIL PROTECTED]> wrote:
> [This still runs fine here, but sharp eyes are always welcome!]
>
> Cleanup of the way kgdb
> - accesses unsafe memory via probe_kernel_*
> - converts to/from hex representation
> - passes errors due to such accesses around
>
> At this chance I also
>
> so lets please all keep that goal in mind. This is not about "will we
> have KGDB support or not", this is about "WHERE will we have KGDB
> support", and i strongly support the notion that it should be in the
> core kernel, where we can keep it clean, tidy and architecturally agile.
I thin
On Feb 10, 2008 9:39 AM, Jan Kiszka <[EMAIL PROTECTED]> wrote:
> Ray Lee wrote:
> > unsigned int void u64_to_hex(u64 val, unsigned char *buf)
> > {
> > int i;
> > for (i=15; i>=0; i--) {
> > buf[i] = hexchars[ val & 0x0f ];
> > val >>= 4;
> >
[This still runs fine here, but sharp eyes are always welcome!]
Cleanup of the way kgdb
- accesses unsafe memory via probe_kernel_*
- converts to/from hex representation
- passes errors due to such accesses around
At this chance I also fix kgdb_ebin2mem, which was broken /wrt escape
sequence
Ray Lee wrote:
> On Feb 10, 2008 8:36 AM, Ingo Molnar <[EMAIL PROTECTED]> wrote:
>> +#ifdef CONFIG_64BIT
>> + } else if ((count == 8) && (((long)mem & 7) == 0)) {
>> + u64 tmp_ll;
>> + if (probe_kernel_address(mem, tmp_ll))
>> + return ERR_PTR
On Feb 10, 2008 8:36 AM, Ingo Molnar <[EMAIL PROTECTED]> wrote:
> +#ifdef CONFIG_64BIT
> + } else if ((count == 8) && (((long)mem & 7) == 0)) {
> + u64 tmp_ll;
> + if (probe_kernel_address(mem, tmp_ll))
> + return ERR_PTR(-EINVAL);
> +
> +
On Sat, Feb 09, 2008 at 09:42:59PM +0100, Ingo Molnar wrote:
> Linus,
>
> while this is probably one of the last days of the merge window, please
> still consider pulling the "kgdb light" git tree from:
>
>git://git.kernel.org/pub/scm/linux/kernel/git/mingo/linux-2.6-kgdb.git
Without postin
Linus,
while this is probably one of the last days of the merge window, please
still consider pulling the "kgdb light" git tree from:
git://git.kernel.org/pub/scm/linux/kernel/git/mingo/linux-2.6-kgdb.git
See the shortlog below.
This is a slimmed-down and cleaned up version of KGDB that i'v
62 matches
Mail list logo
