As far as 'kdb' and 'lkcd' is concerned (excluding 'kgdb' for
the moment), anyone hankering to work on this? Otherwise, it
goes on the list of things-to-do. I've got a few things on
my plate at the moment so I can't go off and do this right now.
Later, yes, but if someone wants this in 4.0, please speak up
now so it's on the list of included items. :)
--Matt
r1vamsi@xxxxxxxxxx wrote:
>
> Richard,
>
> I agree with you completely on the rationale for wanting to dump from kdb.
> In fact, one could choose to trigger a dump (after which the system will
> likely continue to run), not just from KDB, which requires manual
> intervention, but from other debugging tools such as the IBM Dynamic
> Probes, where this could be done automatically.
>
> We are building "non-disruptive" dumps capability into lkcd, which will let
> the system continue normal execution after the dump is taken.
>
> These features will probably find more use when dumps are used for
> debugging other problem situations like performace related problems besides
> oops/panics.
>
> Regards.. Vamsi.
>
> Vamsi Krishna S.
> Linux Technology Center,
> IBM Software Lab, Bangalore.
> Ph: +91 80 5262355 Extn: 3959
> Internet: r1vamsi@xxxxxxxxxx
>
> "Matt D. Robinson" <yakker@xxxxxxxxxxxxxx> on 09/05/2001 05:07:14 AM
>
> Please respond to "Matt D. Robinson" <yakker@xxxxxxxxxxxxxx>
>
> To: "Schaal, Richard" <richard.schaal@xxxxxxxxx>
> cc: S Vamsikrishna/India/IBM@IBMIN, lkcd@xxxxxxxxxxx,
> akale@xxxxxxxxxxxxxxxxxxxxx, kaos@xxxxxxxxxx
> Subject: Re: LKCD + KDB ?
>
> "Schaal, Richard" wrote:
> >
> > I think it would be relatively simple to have the dump_init code register
> a
> > dump system
> > function with the kernel debugger so that you could dump the system on
> > demand. Note that
> > not all problems are Oops related, and that a hung system, or one that is
> > grossly under performing
> > would be useful to get a snapshot of the activity at that time. Manual
> > entry to the debugger
> > and manual dump would seem to be a useful thing. - System survivability
> > after such a dump would be
> > nice, but not a show stopper at this point.
>
> You should already be able to do this with dump_function_ptr in the
> latest code. This should be assigned to dump_execute (at least in
> the last check-in I made). So if you call that address, you'll get
> the dump function pointer.
>
> > So far as the dumping or not after an oops and entering kdb, there is a
> > differentiation as to the reason
> > for entering the debugger - you might derive a dump/no dump directive
> from
> > whether you enter the debugger
> > by reason of breakpoint or oops?
>
> I'm curious, how many people drop into kdb, and then want to take a dump?
> I'd think that this is very useful for developers, but not as useful for
> customers who want to crash and reboot.
>
> > I used to work for Stratus Computer - at that time, a panic or oops would
> > put us into the debugger, and if we
> > were successful in patching up the problem, the system could resume
> > execution. In Linux, after an oops, maybe
> > a "nodump" command would be useful as well to disable the dumping that
> might
> > normally occur.
>
> This is fine -- I think these are all reasonable extensions to KDB, and
> I can work with that developer if need be to make that happen. There's
> an easy solution, one way or another.
>
> --Matt
>
> > Regards,
> > Richard
> >
> > -----Original Message-----
> > From: r1vamsi@xxxxxxxxxx [mailto:r1vamsi@xxxxxxxxxx]
> > Sent: Monday, September 03, 2001 2:55 AM
> > To: Matt D. Robinson
> > Cc: richard.schaal@xxxxxxxxx; lkcd@xxxxxxxxxxx
> > Subject: Re: LKCD + KDB ?
> >
> > When both KDB and LKCD patches are applied, we drop into KDB on an oops.
> > dump_execute will be called after we exit the debugger.
> >
> > If all you want is to disable dump taking after exiting debugger, that is
> > easy enough with editing the dump_okay flag from within the debugger (or
> > add a kdb command to do this) as Matt points out. Assuming there is a
> good
> > reason for wanting to take the dump from within the debugger, one should
> > add a simple dump command to kdb, which will just call dump_execute with
> > proper regs. What you could do today is to set eip to dump_execute from
> > with in the kernel, editing the stack to push correct params :-) (not as
> > hard as it sounds, really)
> >
> > However, the cleaner approach obviously is to add the kdb dump command,
> > once we understand a little better why exactly would one want to dump
> from
> > within the debugger (on an oops).
> >
> > Regards.. Vamsi.
> >
> > Vamsi Krishna S.
> > Linux Technology Center,
> > IBM Software Lab, Bangalore.
> > Ph: +91 80 5262355 Extn: 3959
> > Internet: r1vamsi@xxxxxxxxxx
> >
> > Please respond to "Matt D. Robinson" <yakker@xxxxxxxxxxxxxx>
> >
> > To: richard.schaal@xxxxxxxxx
> > cc: lkcd@xxxxxxxxxxx (bcc: S Vamsikrishna/India/IBM)
> > Subject: Re: LKCD + KDB ?
> >
> > Richard Schaal wrote:
> > >
> > >
> > > My question is this - I have been a fan of the kernel debugger for some
> > > time, and have had a bit of difficulty
> > > resolving how to configure both capabilities into my kernel. I guess
> > > what I'd like to have happen is to
> > > have the system enter the debugger on an oops, then have the option of
> > > dumping the system from the debugger, or
> > > to dump the system automatically after the debugger is exited.
> >
> > There's no great way to do this right now. If in kdb you can set the
> > field of 'dump_okay' field to FALSE, then reset it after dropping back
> > from the debugger state, that'd be fine. I guess we could also add in
> > something for kdb, a one-time thing, so kdb can set dump_kdb to TRUE,
> > and when dump_execute() gets called, dump_kdb is checked, and if set
> > to TRUE, resets it to FALSE. Then add a kdb command that sets the
> > field for you ...
> >
> > Would that work?
> >
> > --Matt
> >
> > > What is your thinking on this? Did I goof something up in applying the
> > > patches for the two features?
> > >
> > > Thanks,
> > > Richard
> > >
> > > --
> > > Richard.Schaal@xxxxxxxxx Intel Corporation
> > > Ph: (408)765-1579 Richard Schaal
> > > Mail Stop SC12-308
> > > 3600 Juliette Lane
> > > "I can type faster than I think!" Santa Clara, CA 95052
|