12:52 a.m.
Hello Dave,
The subcommand irq can dump the most of the irq information. Here I add
some options to make some improvements for irq.
1. option '-s': display the cpu affinity for in-use IRQs.
2. option '-S' and '-c': display the percpu irq stats. -c is used to
specify the cpu for which irq stats should be displayed. Without option
-c, 'irq -S' displays the irq stats for all cpus. The output of this
option is just like 'cat /proc/interrupts' shows.
Two patches attched:
-s: 0001-Add-s-option-for-irq-to-dump-the-cpu-affinity-of-in-.patch
-S and -c: 0002-Add-S-and-c-option-for-irq-to-dump-the-kernel-irq-st.patch
And the second patch is made at the base of the first patch.
Thanks,
Zhang Yanfei
--
Regards
Zhang Yanfei
--------------------------------------------------
Development Dept.I
Nanjing Fujitsu Nanda Software Tech. Co., Ltd.(FNST)
No. 6 Zhushan Road, Nanjing, 210012, China
TEL: +86+25-86630566-8529
FUJITSU INTERNAL: 7998-8529
EMail: zhangyanfei(a)cn.fujitsu.com
--------------------------------------------------
4:25 p.m.
----- Original Message -----
Hello Dave,
The subcommand irq can dump the most of the irq information. Here I add
some options to make some improvements for irq.
1. option '-s': display the cpu affinity for in-use IRQs.
2. option '-S' and '-c': display the percpu irq stats. -c is used to
specify the cpu for which irq stats should be displayed. Without option
-c, 'irq -S' displays the irq stats for all cpus. The output of this
option is just like 'cat /proc/interrupts' shows.
Two patches attched:
-s: 0001-Add-s-option-for-irq-to-dump-the-cpu-affinity-of-in-.patch
-S and -c: 0002-Add-S-and-c-option-for-irq-to-dump-the-kernel-irq-st.patch
And the second patch is made at the base of the first patch.
Thanks,
Zhang Yanfei
Hello Zhang,
While it seems to work with RHEL5 and RHEL6 kernels, when I tried this
with a relatively recent (3.1.1-2.fc16) Fedora kernel, both options fail:
$ crash vmlinux.gz vmcore
crash 6.0.3rc8
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: vmlinux.gz
DUMPFILE: vmcore
CPUS: 12
DATE: Tue Nov 15 16:33:21 2011
UPTIME: 00:03:33
LOAD AVERAGE: 0.26, 0.26, 0.12
TASKS: 185
NODENAME: amd-pence-01.lab.bos.redhat.com
RELEASE: 3.1.1-2.fc16.x86_64
VERSION: #1 SMP Mon Nov 14 15:46:10 UTC 2011
MACHINE: x86_64 (1895 Mhz)
MEMORY: 1 GB
PANIC: ""
PID: 3917
COMMAND: "crash"
TASK: ffff88003c1a5cc0 [THREAD_INFO: ffff88003cc3e000]
CPU: 6
STATE: TASK_RUNNING (PANIC)
crash> irq -S
CPU0 CPU1 CPU2 CPU3 CPU4 CPU5 CPU6
CPU7 CPU8 CPU9 CPU10
CPU11
irq: invalid kernel virtual address: 16134 type: "kstat_irqs"
crash> irq -s
IRQ NAME AFFINITY
Segmentation fault
$
I don't know what the "kstat_irqs" problem is with "irq -S", but
here's
a trace of the "irq -s" attempt:
$ gdb ./crash
... [ cut ] ...
(gdb) run vmlinux vmcore
... [cut ] ...
crash> irq -s
[Detaching after fork from child process 10843.]
IRQ NAME AFFINITY
Program received signal SIGSEGV, Segmentation fault.
0x00000000004b437a in generic_get_irq_affinity (irq=<value optimized out>) at
kernel.c:4961
4961 if (NUM_IN_BITMAP(mask, cpu)) {
(gdb) bt
#0 0x00000000004b437a in generic_get_irq_affinity (irq=<value optimized out>) at
kernel.c:4961
#1 0x00000000004b63e5 in cmd_irq () at kernel.c:4803
#2 0x0000000000459e30 in exec_command () at main.c:751
#3 0x000000000045a0de in main_loop () at main.c:699
#4 0x0000000000552029 in captured_command_loop (data=0xe) at ./main.c:228
#5 0x00000000005511fb in catch_errors (func=0x552020 <captured_command_loop>,
func_args=0x0, errstring=0x8485b7 "",
mask=<value optimized out>) at exceptions.c:531
#6 0x0000000000552786 in captured_main (data=<value optimized out>) at
./main.c:958
#7 0x00000000005511fb in catch_errors (func=0x552060 <captured_main>,
func_args=0x7fffdda9dc70, errstring=0x8485b7 "",
mask=<value optimized out>) at exceptions.c:531
#8 0x0000000000551dc4 in gdb_main (args=0x0) at ./main.c:973
#9 0x0000000000551e06 in gdb_main_entry (argc=<value optimized out>, argv=0x0) at
./main.c:993
#10 0x000000000045dd3f in main (argc=3, argv=0x7fffdda9ef68) at main.c:603
(gdb)
Also, the output of "irq -S" gets really unmanageable if the system has
a lot of cpus. I'm not sure what to suggest there.
Dave
4703
days inactive
4703
days old
devel@lists.crash-utility.osci.io
1 comments
2 participants
participants (2)
-
Dave Anderson -
zhangyanfei