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
|