Hi Matt,
I have faced several times the problem of crash dumps not being
available
in kgdb. Many a times I don't have time to debug a panic immediately, so
I keep the machine inside the debugger. A crash dump will enable me to
save
a crash dump and continue testing. I can get back to the core dump
later.
Usually it's a good idea to save cores for all non-trivial problems once
a product goes alpha. If a problem which is supposedly fixed resurfaces,
it's very difficult to say whether it's the same problem in absence of a
core
dump.
In ideal world, all problems should be fixed immediately and completely
using a debugger and we wouldn't need crash dumps.
I guess it's time to think about making kgdb understand lkcd interface.
"Matt D. Robinson" wrote:
>
> "Schaal, Richard" wrote:
> >
> > Hi Matt,
> > When you refer to the "latest code", what is that? I don't see anything on
> > source forge as released code, and the
> > latest from the SGI site has patches up to linux-2.4.4 is that what you were
> > referring to?
> >
> > Thanks,
> > Richard
>
> The latest code is in the SourceForge tree ... look in
> 2.4/drivers/block/dump.c,
> and you'll see the restructuring changes. 'lcrash' has also changed a bit.
> I copied the LKCD group on my last check-in. If you didn't get a copy of it,
> let me know. It touched a bunch of files.
>
> I have to check in new scripts and a new dumpconfig utility next (and fix
> this bloody SMP problem now that I actually have an SMP system again to test
> against).
>
> --Matt
>
> >
> > -----Original Message-----
> > From: Matt D. Robinson [mailto:yakker@xxxxxxxxxxxxxx]
> > Sent: Tuesday, September 04, 2001 4:37 PM
> > To: Schaal, Richard
> > Cc: 'r1vamsi@xxxxxxxxxx'; 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
--
Amit S. Kale
Linux Consultant, Pune, India. (kgdb@xxxxxxxx)
Linux kernel source level debugger http://kgdb.sourceforge.net/
Translation filesystem http://trfs.sourceforge.net/
|