"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
|