----- 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 -- Crash-utility mailing list Crash-utility@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/crash-utility
