"Amit S. Kale" wrote:
>
> 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.
This should be a pretty straightfoward thing to add. If you don't want
to do it, let me know, so I can put it on my list. I think it's a high
enough priority to get done for the next release, if humanly possible.
Your latest stuff is in the source tarballs on kgdb.sourceforge.net?
--Matt
> "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/
|