12:39 a.m.
Hello Dave,
I was recommended to add the display of ST when using ps -l. Because it
is simple, so I made the patch at first and then talk about the merit of
patch with you.
The display is like below:
crash> ps -l
[100126284069406] PID: 2389 TASK: ffff88047416aa80 ST:IN CPU: 12
COMMAND: "kondemand/12"
[100126285814043] PID: 795 TASK: ffff880470cb3540 ST:UN CPU: 0
COMMAND: "jbd2/sda2-8"
[100126284061076] PID: 2377 TASK: ffff88047426c100 ST:IN CPU: 0
COMMAND: "kondemand/0"
[100126284058337] PID: 70050 TASK: ffff88045beaeac0 ST:RU CPU: 3
COMMAND: "crash"
[100126285834369] PID: 70781 TASK: ffff88046929e100 ST:RU CPU: 0
COMMAND: "dd"
...
I think "ps -l", which displays task sorted by last_run/timestamp, is
concerning about the state of the task. Taking it into consideration, on
a live system with original code, we use "ps -l" to show the sorted
tasks at first, then use "ps" to display the state. The two pieces of
information in such situation are not consonant. This is the reason why
ST is needed.
--
--
Regards
Qiao Nuohan
9:36 a.m.
----- Original Message -----
Hello Dave,
I was recommended to add the display of ST when using ps -l. Because it
is simple, so I made the patch at first and then talk about the merit of
patch with you.
The display is like below:
crash> ps -l
[100126284069406] PID: 2389 TASK: ffff88047416aa80 ST:IN CPU: 12 COMMAND:
"kondemand/12"
[100126285814043] PID: 795 TASK: ffff880470cb3540 ST:UN CPU: 0 COMMAND:
"jbd2/sda2-8"
[100126284061076] PID: 2377 TASK: ffff88047426c100 ST:IN CPU: 0 COMMAND:
"kondemand/0"
[100126284058337] PID: 70050 TASK: ffff88045beaeac0 ST:RU CPU: 3 COMMAND:
"crash"
[100126285834369] PID: 70781 TASK: ffff88046929e100 ST:RU CPU: 0 COMMAND:
"dd"
...
I think "ps -l", which displays task sorted by last_run/timestamp, is
concerning about the state of the task. Taking it into consideration, on
a live system with original code, we use "ps -l" to show the sorted
tasks at first, then use "ps" to display the state. The two pieces of
information in such situation are not consonant. This is the reason why
ST is needed.
Your patch is unacceptable as-is because it changes the task header display
for *all* context-specific commands, like "bt", "vm",
"files", "task", etc.
But it does make sense that the task's timestamp and its state could
be correlated by "ps -l" output. Maybe something like this, with an
explanation in the ps help page?:
crash> ps -l
[100126284069406] [IN] PID: 2389 TASK: ffff88047416aa80 CPU: 12 COMMAND:
"kondemand/12"
[100126285814043] [UN] PID: 795 TASK: ffff880470cb3540 CPU: 0 COMMAND:
"jbd2/sda2-8"
[100126284061076] [IN] PID: 2377 TASK: ffff88047426c100 CPU: 0 COMMAND:
"kondemand/0"
[100126284058337] [RU] PID: 70050 TASK: ffff88045beaeac0 CPU: 3 COMMAND:
"crash"
[100126285834369] [RU] PID: 70781 TASK: ffff88046929e100 CPU: 0 COMMAND:
"dd"
...
Dave
9:57 a.m.
New subject: How to use scripts in crash?
Hi Dave,
Do you have some guide doc that describe how to use the scripts in crash?
Like the example, I want to print out current filesystems registered.
I then need do following
1. using "p" to get "file_systems" symbol value
2. using "list" with command as "list -o file_system_type.next -s
file_system_type.name,fs_flags <the file_systems symbol value>"
So if the previous file_systems symbol value could be stored, and then I don't need to
copy the "p" result to "list" command by hand, but could let script do
such kind of thing.
I also notice there is "sial" script support in crash, but that is too complex
for me... I don't know how to start a basic usage with that... Is there any detailed
doc that could help me from a start?
Thanks,
Lei
10:08 a.m.
New subject: How to use scripts in crash?
----- Original Message -----
Hi Dave,
Do you have some guide doc that describe how to use the scripts in
crash?
Like the example, I want to print out current filesystems registered.
I then need do following
1. using "p" to get "file_systems" symbol value
2. using "list" with command as "list -o file_system_type.next -s
file_system_type.name,fs_flags <the file_systems symbol value>"
So if the previous file_systems symbol value could be stored, and
then I don't need to copy the "p" result to "list" command by
hand,
but could let script do such kind of thing.
I also notice there is "sial" script support in crash, but that is
too complex for me... I don't know how to start a basic usage with
that... Is there any detailed doc that could help me from a start?
Thanks,
Lei
I can't help you with sial usage, but there is a ~1000-page README
file in crash-6.0.4/extensions/libsial. And perhaps the sample
ps.c and files.c sial scripts from the crash extensions page could
be used as templates for your requirements.
Dave
10:25 a.m.
New subject: How to use scripts in crash?
On Wed, Mar 7, 2012 at 8:08 AM, Dave Anderson <anderson(a)redhat.com> wrote:
> I also notice there is "sial" script support in crash,
but that is
> too complex for me... I don't know how to start a basic usage with
> that... Is there any detailed doc that could help me from a start?
>
> Thanks,
> Lei
I can't help you with sial usage, but there is a ~1000-page README
file in crash-6.0.4/extensions/libsial. And perhaps the sample
ps.c and files.c sial scripts from the crash extensions page could
be used as templates for your requirements.
There's also pykdump, if you don't mind python. It is rigged up to be
able to call back into crash, which sial is not. It also has better facilities
for coping with compile time structure variations. So if you need to learn
a new language anyway (sial being a new language as it is not C),
it may as well be python.
Alternatively, you can also write shell scripts that emit crash commands
into a file that, when sourced, does a bunch of crash commands before
re-invoking itself. I finally did that since there is no provision for scripts
to feed commands back to crash directly. It works. It's tricky. Attached
is an example that will do approximate "bt"s on threads that were caught
"on proc" at the time of a crash. It's my template.
Cheers - Bruce
9:11 a.m.
New subject: How to use scripts in crash?
Hi Bruce,
On Thu, Mar 8, 2012 at 12:25 AM, Bruce Korb <bruce.korb(a)gmail.com> wrote:
On Wed, Mar 7, 2012 at 8:08 AM, Dave Anderson
<anderson(a)redhat.com> wrote:
>> I also notice there is "sial" script support in crash, but that is
>> too complex for me... I don't know how to start a basic usage with
>> that... Is there any detailed doc that could help me from a start?
>>
>> Thanks,
>> Lei
>
> I can't help you with sial usage, but there is a ~1000-page README
> file in crash-6.0.4/extensions/libsial. And perhaps the sample
> ps.c and files.c sial scripts from the crash extensions page could
> be used as templates for your requirements.
There's also pykdump, if you don't mind python. It is rigged up to be
able to call back into crash, which sial is not. It also has better facilities
for coping with compile time structure variations. So if you need to learn
a new language anyway (sial being a new language as it is not C),
it may as well be python.
Alternatively, you can also write shell scripts that emit crash commands
into a file that, when sourced, does a bunch of crash commands before
re-invoking itself. I finally did that since there is no provision for scripts
to feed commands back to crash directly. It works. It's tricky. Attached
is an example that will do approximate "bt"s on threads that were caught
"on proc" at the time of a crash. It's my template.
Seem I get no luck to build out the pykdump...
I git clone its tree from:
git://pykdump.git.sourceforge.net/gitroot/pykdump/pykdump
After this, I do the ./configure -c <crash build place>
and then make, the following error shows up:
Makefile:24: slocal.mk: No such file or directory
make: *** No rule to make target `slocal.mk'. Stop.
Any idea?
Cheers - Bruce
Thanks,
Lei
9:34 a.m.
New subject: How to use scripts in crash?
On March 8, 2012 11:11:36 PM Lei Wen wrote:
Seem I get no luck to build out the pykdump...
I git clone its tree from:
git://pykdump.git.sourceforge.net/gitroot/pykdump/pykdump
After this, I do the ./configure -c <crash build place>
and then make, the following error shows up:
Makefile:24: slocal.mk: No such file or directory
make: *** No rule to make target `slocal.mk'. Stop.
Hi Bruce,
some time ago it was possible to build PyKdump with distribution-provided
Python, but then I have realized it does not make much sense as it would be
difficult to redistribute it.
So the only supported approach at this moment is to to build Python from
sources first and then build PyKdump using Python libraries from this build.
http://sourceforge.net/apps/mediawiki/pykdump/index.php?title=BuildingGit
explains this in more details. In particular, you need to specify _both_
locations of crash sources and Python sources, e.g.
$ ./configure -p /src/Python/Python-2.7.2 -c /src/kerntools/crash-6.0.3
After this slocal.mk will be created.
Regards,
Alex
--
------------------------------------------------------------------
Alexandre Sidorenko email: asid(a)hp.com
WTEC Linux Hewlett-Packard (Canada)
------------------------------------------------------------------
9:35 a.m.
New subject: How to use scripts in crash?
Hi Lei,
On Thu, Mar 8, 2012 at 7:11 AM, Lei Wen <adrian.wenl(a)gmail.com> wrote:
Seem I get no luck to build out the pykdump...
....
Makefile:24: slocal.mk: No such file or directory
make: *** No rule to make target `slocal.mk'. Stop.
Any idea?
It's true the build mechanisms of pykdump leave a lot to be desired.
You have to tell the thing where to find the python build tree, too,
because the process involves rolling up a largish subset of python
into the .so file. After configuring there should be *three* .mk files.
I've attached a file showing how mine got set up for my platform
with my layout, meaning you won't be able to use it (directly), but
you'll see more-or-less what you need. You'll find the pykdump guy
helpful 'cuz he helped me through exactly the same problems. Weeks
ago now, so I've forgotten what exactly I had to do.... :)
Good luck. Cheers - Bruce
$ ls -l $(find * -name '*.so')
-rwxrwxrwx 1 bruce staff 6302242 Feb 8 15:54 Extension/mpykdump.so
-rwxrwxrwx 1 bruce staff 5896299 Feb 8 12:41 Extension/pykdump_c.so
6:34 p.m.
New subject: How to use scripts in crash?
On Wed, 7 Mar 2012 07:57:40 -0800, Lei Wen wrote:
lei> I then need do following
lei> 1. using "p" to get "file_systems" symbol value
lei> 2. using "list" with command as "list -o file_system_type.next -s
file_system_type.name,fs_flags <the file_systems symbol value>"
lei> So if the previous file_systems symbol value could be stored,
lei> and then I don't need to copy the "p" result to "list"
command
lei> by hand, but could let script do such kind of thing.
Others have mentioned pykdump and sial, there is also a granddaddy of
it all - good ol' gdb script. They're not as flexible as sial or
pykdump but they have an advantage of being "always on" - gdb is part
of crash.
Here is an example of printing list of 'rpc tasks' from sunrpc module
define rpc_tasks
set $e = ((struct list_head *)$arg0)
set $n = $e->next
set $of = &(((struct rpc_task *)0)->tk_task)
while $n != $e
set $i = (struct rpc_task *)((char *)$n - (char *)$of)
set $proc = $i->tk_msg->rpc_proc
if ($proc->p_name)
printf "%p\t%s", $i, $proc->p_name
else
printf "%p\tNULL", $i
end
printf "\t%p(%s, xprt %p)\t%p", $i->tk_client,
$i->tk_client->cl_protname, $i->tk_client->cl_xprt,
$i->tk_client->$i->tk_rqstp
if ($i->tk_rqstp)
printf "(%x)", $i->tk_rqstp->rq_xid
end
printf "\t%d\n", $i->tk_pid
set $n = $n->next
end
end
You can type this by hand or save it into a file and then use
'source your.file.name.here' command in crash. After sourcing is done
you have a command called rpc_tasks which can be used like this:
crash> rpc_tasks 0xabcd8000
where 0xabcd8000 is the list_head of a task list.
The example shows how to walk a list and how to access a list entry if
the linkage is not directly at the start of the structure.
max
8:12 p.m.
At 2012-3-7 23:36, Dave Anderson wrote:
----- Original Message -----
> Hello Dave,
>
> I was recommended to add the display of ST when using ps -l. Because it
> is simple, so I made the patch at first and then talk about the merit of
> patch with you.
>
> The display is like below:
>
> crash> ps -l
> [100126284069406] PID: 2389 TASK: ffff88047416aa80 ST:IN CPU: 12 COMMAND:
"kondemand/12"
> [100126285814043] PID: 795 TASK: ffff880470cb3540 ST:UN CPU: 0 COMMAND:
"jbd2/sda2-8"
> [100126284061076] PID: 2377 TASK: ffff88047426c100 ST:IN CPU: 0 COMMAND:
"kondemand/0"
> [100126284058337] PID: 70050 TASK: ffff88045beaeac0 ST:RU CPU: 3 COMMAND:
"crash"
> [100126285834369] PID: 70781 TASK: ffff88046929e100 ST:RU CPU: 0 COMMAND:
"dd"
> ...
>
> I think "ps -l", which displays task sorted by last_run/timestamp, is
> concerning about the state of the task. Taking it into consideration, on
> a live system with original code, we use "ps -l" to show the sorted
> tasks at first, then use "ps" to display the state. The two pieces of
> information in such situation are not consonant. This is the reason why
> ST is needed.
Your patch is unacceptable as-is because it changes the task header display
for *all* context-specific commands, like "bt", "vm",
"files", "task", etc.
But it does make sense that the task's timestamp and its state could
be correlated by "ps -l" output. Maybe something like this, with an
explanation in the ps help page?:
crash> ps -l
[100126284069406] [IN] PID: 2389 TASK: ffff88047416aa80 CPU: 12 COMMAND:
"kondemand/12"
[100126285814043] [UN] PID: 795 TASK: ffff880470cb3540 CPU: 0 COMMAND:
"jbd2/sda2-8"
[100126284061076] [IN] PID: 2377 TASK: ffff88047426c100 CPU: 0 COMMAND:
"kondemand/0"
[100126284058337] [RU] PID: 70050 TASK: ffff88045beaeac0 CPU: 3 COMMAND:
"crash"
[100126285834369] [RU] PID: 70781 TASK: ffff88046929e100 CPU: 0 COMMAND:
"dd"
...
String like "PID: 2389 TASK: ffff88047416aa80 CPU: 12 COMMAND:
"kondemand/12"" is printed by a function. The change of the function,
which I made in the last patch, causes the change of other commands. The
new patch will add "ST:.." out of the command, the output is like below:
[2567398667393] ST:IN PID: 154 TASK: ffff880475292b40 CPU: 0
COMMAND: "kblockd/0"
[2567399925204] ST:IN PID: 4380 TASK: ffff880464665500 CPU: 1
COMMAND: "qemu-system-x86"
[2567396569308] ST:IN PID: 4411 TASK: ffff880467227500 CPU: 1
COMMAND: "qemu-system-x86"
[2567395016839] ST:RU PID: 5338 TASK: ffff880464664ac0 CPU: 2
COMMAND: "crash"
Dave
--
Crash-utility mailing list
Crash-utility(a)redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility
--
--
Regards
Qiao Nuohan
--------------------------------------------------
Qiao Nuohan
Development Dept.I
Nanjing Fujitsu Nanda Software Tech. Co., Ltd.(FNST)
No. 6 Wenzhu Road, Nanjing, Nanjing, 210012, China
TEL: +86+25-86630566-8526 FUJITSU
INTERNAL: 7998-8526 FAX: +86+25-83317685
EMail: qiaonuohan(a)cn.fujitsu.com
--------------------------------------------------
This communication is for use by the intended
recipient(s) only and may contain information that
is privileged, confidential and exempt from
disclosure under applicable law. If you are not an
intended recipient of this communication, you are
hereby notified that any dissemination,
distribution or copying hereof is strictly
prohibited. If you have received this communication
in error, please notify me by reply e-mail,
permanently delete this communication from your
system, and destroy any hard copies you may have
printed
8:28 a.m.
----- Original Message -----
At 2012-3-7 23:36, Dave Anderson wrote:
>
>
> ----- Original Message -----
>> Hello Dave,
>>
>> I was recommended to add the display of ST when using ps -l. Because it
>> is simple, so I made the patch at first and then talk about the merit of
>> patch with you.
>>
>> The display is like below:
>>
>> crash> ps -l
>> [100126284069406] PID: 2389 TASK: ffff88047416aa80 ST:IN CPU: 12 COMMAND:
"kondemand/12"
>> [100126285814043] PID: 795 TASK: ffff880470cb3540 ST:UN CPU: 0 COMMAND:
"jbd2/sda2-8"
>> [100126284061076] PID: 2377 TASK: ffff88047426c100 ST:IN CPU: 0 COMMAND:
"kondemand/0"
>> [100126284058337] PID: 70050 TASK: ffff88045beaeac0 ST:RU CPU: 3 COMMAND:
"crash"
>> [100126285834369] PID: 70781 TASK: ffff88046929e100 ST:RU CPU: 0 COMMAND:
"dd"
>> ...
>>
>> I think "ps -l", which displays task sorted by last_run/timestamp, is
>> concerning about the state of the task. Taking it into consideration, on
>> a live system with original code, we use "ps -l" to show the sorted
>> tasks at first, then use "ps" to display the state. The two pieces of
>> information in such situation are not consonant. This is the reason why
>> ST is needed.
>
> Your patch is unacceptable as-is because it changes the task header display
> for *all* context-specific commands, like "bt", "vm",
"files", "task", etc.
>
> But it does make sense that the task's timestamp and its state could
> be correlated by "ps -l" output. Maybe something like this, with an
> explanation in the ps help page?:
>
> crash> ps -l
> [100126284069406] [IN] PID: 2389 TASK: ffff88047416aa80 CPU: 12 COMMAND:
"kondemand/12"
> [100126285814043] [UN] PID: 795 TASK: ffff880470cb3540 CPU: 0 COMMAND:
"jbd2/sda2-8"
> [100126284061076] [IN] PID: 2377 TASK: ffff88047426c100 CPU: 0 COMMAND:
"kondemand/0"
> [100126284058337] [RU] PID: 70050 TASK: ffff88045beaeac0 CPU: 3 COMMAND:
"crash"
> [100126285834369] [RU] PID: 70781 TASK: ffff88046929e100 CPU: 0 COMMAND:
"dd"
> ...
String like "PID: 2389 TASK: ffff88047416aa80 CPU: 12 COMMAND:
"kondemand/12""
is printed by a function. The change of the function, which I made in the last patch,
causes the change of other commands. The new patch will add "ST:.." out of the
command,
the output is like below:
[2567398667393] ST:IN PID: 154 TASK: ffff880475292b40 CPU: 0 COMMAND:
"kblockd/0"
[2567399925204] ST:IN PID: 4380 TASK: ffff880464665500 CPU: 1 COMMAND:
"qemu-system-x86"
[2567396569308] ST:IN PID: 4411 TASK: ffff880467227500 CPU: 1 COMMAND:
"qemu-system-x86"
[2567395016839] ST:RU PID: 5338 TASK: ffff880464664ac0 CPU: 2 COMMAND:
"crash"
This is OK, but aesthetically I prefer to bracket the status identifier
the same way as is done by the last_run/timestamp value. Queued for
crash-6.0.5.
Dave
4498
days inactive
4499
days old
devel@lists.crash-utility.osci.io
10 comments
7 participants
participants (7)
-
Alex Sidorenko -
Bruce Korb -
Dave Anderson -
Lei Wen -
Lei Wen -
Max Matveev -
qiaonuohan