4:39 p.m.
Hi,
Sometimes it is useful to not clutter up my active screen and run
crash in another window so I can examine "help mod" and type the
command in the real session. That, or extract all the help
text into a .texi doc? Something, please, anyway....
Thank you!
Regards, Bruce
example usage:
$ crash --help-mode
crash-help-for>
8:23 a.m.
----- Original Message -----
Hi,
Sometimes it is useful to not clutter up my active screen and run
crash in another window so I can examine "help mod" and type the
command in the real session. That, or extract all the help
text into a .texi doc? Something, please, anyway....
Thank you!
Regards, Bruce
example usage:
$ crash --help-mode
crash-help-for>
Bruce,
Here's what's available:
To see a command's help page without invoking a crash session,
use "crash -h" or "--help", as described in the man page:
$ man crash
... [ cut ] ...
-h [option]
--help [option]
Without an option argument, display a crash usage help message.
If the option argument is a crash command name, the help page
for that command is displayed. If it is the string "input", a
page describing the various crash command line input options is
displayed. If it is the string "output", a page describing com-
mand line output options is displayed. After the help message
is displayed, crash exits.
...
So for the "mod" command:
$ crash -h mod
NAME
mod - module information and loading of symbols and debugging data
SYNOPSIS
mod -s module [objfile] | -d module | -S [directory] | -D | -r | -R | -o | -g
DESCRIPTION
With no arguments, this command displays basic information of the currently
installed modules, consisting of the module address, name, size, the
object file name (if known), and whether the module was compiled with
CONFIG_KALLSYMS.
...
And although it's undocumented, you can get a complete dump of all pages
by entering "crash -h all".
Alternatively, if you've got a browser window open, go to the "Builtin
Help"
page of the crash whitepaper, and just click on the command you're
interested in:
http://people.redhat.com/anderson/crash_whitepaper/#HELP
Dave Anderson
11:01 a.m.
On 02/13/12 06:23, Dave Anderson wrote:
-h [option]
--help [option]
Without an option argument, display a crash usage help message.
If the option argument is a crash command name,
I've learned how to look without seeing sometimes. :( Thanks!
Interactive would be marginally easier, but not enough to make
it worth the effort.
And although it's undocumented, you can get a complete dump of
all pages
by entering "crash -h all".
That would be a good sentence to add to the "--help" clause.
Alternatively, if you've got a browser window open, go to the
"Builtin Help"
page of the crash whitepaper, and just click on the command you're
interested in:
http://people.redhat.com/anderson/crash_whitepaper/#HELP
_That_ is definitely nice!
Now that I'm futzing with this, another RFE or else "Request for how to really do
it":
a "source" command. In my environment, we've got 16 (yes, *sixteen*)
loadable
modules that need to get "mod -s MODNAME /path/to/modname.ko" -ed.
So not being a big fan of typing, my preference would be to:
mod | script-to-look-for-modules > mod-s-commands
source mod-s-commands
and presto, my .ko files are loaded.
So, is there an easier way, or is the "source" command reasonable?
11:20 a.m.
----- Original Message -----
On 02/13/12 06:23, Dave Anderson wrote:
> -h [option]
> --help [option]
> Without an option argument, display a crash usage
> help message.
> If the option argument is a crash command name,
I've learned how to look without seeing sometimes. :( Thanks!
Interactive would be marginally easier, but not enough to make
it worth the effort.
> And although it's undocumented, you can get a complete dump of all pages
> by entering "crash -h all".
That would be a good sentence to add to the "--help" clause.
Yeah, I'll do that. I forgot about that option when the man page
was overhauled recently.
> Alternatively, if you've got a browser window open, go to the "Builtin
Help"
> page of the crash whitepaper, and just click on the command you're
> interested in:
>
> http://people.redhat.com/anderson/crash_whitepaper/#HELP
_That_ is definitely nice!
Now that I'm futzing with this, another RFE or else "Request for how
to really do it":
a "source" command. In my environment, we've got 16 (yes, *sixteen*)
loadable
modules that need to get "mod -s MODNAME /path/to/modname.ko" -ed.
So not being a big fan of typing, my preference would be to:
mod | script-to-look-for-modules > mod-s-commands
source mod-s-commands
and presto, my .ko files are loaded.
So, is there an easier way, or is the "source" command reasonable?
There's 3 possibilities...
Put the mod commands in a .crashrc file in the current directory, or in
your $HOME directory, like this example:
# cat .crashrc
mod -s nfsd
mod -s nfs
# crash
crash 6.0.3
Copyright (C) 2002-2012 Red Hat, Inc.
Copyright (C) 2004, 2005, 2006 IBM Corporation
Copyright (C) 1999-2006 Hewlett-Packard Co
Copyright (C) 2005, 2006 Fujitsu Limited
Copyright (C) 2006, 2007 VA Linux Systems Japan K.K.
Copyright (C) 2005 NEC Corporation
Copyright (C) 1999, 2002, 2007 Silicon Graphics, Inc.
Copyright (C) 1999, 2000, 2001, 2002 Mission Critical Linux, Inc.
This program is free software, covered by the GNU General Public License,
and you are welcome to change it and/or distribute copies of it under
certain conditions. Enter "help copying" to see the conditions.
This program has absolutely no warranty. Enter "help warranty" for details.
GNU gdb (GDB) 7.3.1
Copyright (C) 2011 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-unknown-linux-gnu"...
KERNEL: /usr/lib/debug/lib/modules/2.6.32-70.el6.x86_64/vmlinux
DUMPFILE: /dev/crash
CPUS: 4
DATE: Mon Feb 13 12:11:31 2012
UPTIME: 58 days, 22:21:22
LOAD AVERAGE: 3.30, 3.10, 2.96
TASKS: 340
NODENAME: waste.usersys.redhat.com
RELEASE: 2.6.32-70.el6.x86_64
VERSION: #1 SMP Wed Aug 25 10:17:53 EDT 2010
MACHINE: x86_64 (2792 Mhz)
MEMORY: 1 GB
PID: 2405
COMMAND: "crash"
TASK: ffff88003c3e94a0 [THREAD_INFO: ffff880027f02000]
CPU: 0
STATE: TASK_RUNNING (ACTIVE)
crash> mod -s nfsd
MODULE NAME SIZE OBJECT FILE
ffffffffa05955c0 nfsd 302737
/lib/modules/2.6.32-70.el6.x86_64/kernel/fs/nfsd/nfsd.ko
crash> mod -s nfs
MODULE NAME SIZE OBJECT FILE
ffffffffa0619120 nfs 348522
/lib/modules/2.6.32-70.el6.x86_64/kernel/fs/nfs/nfs.ko
crash>
Note that the two mod commands above were not entered manually, but were
displayed and done automatically.
Or do it during a crash session by putting the commands in a file,
and run the command's contents by redirecting:
crash> !cat input
mod -s nfsd
mod -s nfs
crash> < input
crash> mod -s nfsd
MODULE NAME SIZE OBJECT FILE
ffffffffa05955c0 nfsd 302737
/lib/modules/2.6.32-70.el6.x86_64/kernel/fs/nfsd/nfsd.ko
crash> mod -s nfs
MODULE NAME SIZE OBJECT FILE
ffffffffa0619120 nfs 348522
/lib/modules/2.6.32-70.el6.x86_64/kernel/fs/nfs/nfs.ko
crash>
There's also the new redirection capability for individual commands, where
each line in the input file will be appended to the command line entered:
crash> !cat input
nfsd
nfs
crash> mod -s < input
MODULE NAME SIZE OBJECT FILE
ffffffffa05955c0 nfsd 302737
/lib/modules/2.6.32-70.el6.x86_64/kernel/fs/nfsd/nfsd.ko
MODULE NAME SIZE OBJECT FILE
ffffffffa0619120 nfs 348522
/lib/modules/2.6.32-70.el6.x86_64/kernel/fs/nfs/nfs.ko
crash>
Hopefully one of the above suits your needs...
Dave
12:02 p.m.
On 02/13/12 09:20, Dave Anderson wrote:
> a "source" command. In my environment, we've got
16 (yes, *sixteen*) loadable
> modules that need to get "mod -s MODNAME /path/to/modname.ko" -ed.
> So not being a big fan of typing, my preference would be to:
>
> mod | script-to-look-for-modules> mod-s-commands
> source mod-s-commands
There are 3 possibilities...
Put the mod commands in a .crashrc file in the current directory,
If it were static, I could. This is for analyzing crash dumps that
have been created on other systems.
Or do it during a crash session by putting the commands in a file,
and run the command's contents by redirecting:
crash> < input
crash> mod -s< input
I gather that both of these are really the same in that the first case
simply appends each input line to an empty string. This is exactly what
I was asking for, plus a little bit. Since I wasn't expecting the
"mod -s < input" formulation, I likely just didn't stumble over it.
Anyway, since I won't know in advance which modules are loaded;
and once I do know which ones they are, I won't know where they are;
I will need to use a feedback loop. crash must tell a hunt-it-down
script which modules are needed, then that script tells crash where
to load up the .ko files. Perfect. Thank you so much!!
Regards, Bruce
4701
days inactive
4704
days old
devel@lists.crash-utility.osci.io
4 comments
2 participants
participants (2)
-
Bruce Korb -
Dave Anderson