Takao Indoh | 26 Jan 08:12 2016

Extensions: ptdump update v1.0.1

Hi Dave,

The attached file is updated extension module ptdump v1.0.1. Please
replace old one in extension site[1] with this tarball.

Changelog:
- Add COPYING file in tarball
- Bug fix on cpu hot-removing
- Clean up codes

md5sum:
dea92b22142d59e73340a8af35e15c92

[1] http://people.redhat.com/anderson/extensions.html#PTDUMP

Thanks,
Takao Indoh
Attachment (ptdump-1.0.1.tar.gz): application/gzip, 18 KiB
Hi Dave,

The attached file is updated extension module ptdump v1.0.1. Please
replace old one in extension site[1] with this tarball.

Changelog:
- Add COPYING file in tarball
- Bug fix on cpu hot-removing
- Clean up codes

(Continue reading)

Dave Anderson | 21 Jan 22:34 2016
Picon
Gravatar

Re: [PATCH] xen: Add support for dom0 with Linux kernel 3.19 and newer


----- Original Message -----
>
> Linux kernel commit 054954eb051f35e74b75a566a96fe756015352c8
> (xen: switch to linear virtual mapped sparse p2m list), which
> appeared in 3.19, introduced linear virtual mapped sparse p2m
> list. If readmem() reads p2m then it access this list using
> physical addresses. Sadly, VMA to physical address translation
> in crash requires access to p2m list. This means that we have
> a chicken and egg problem. In general this issue must be solved
> by introducing some changes in libxl, Linux kernel and crash
> (I have added this task to my long TODO list). However, in dom0
> case we can use crash_xen_info_t.dom0_pfn_to_mfn_frame_list_list
> which is available out of the box. So, let's use it and make
> at least some users happy.
> 
> Signed-off-by: Daniel Kiper <daniel.kiper <at> oracle.com>

Hi Daniel,

Can you help me out with a consise changelog entry?  As I understand
it, the crash utility has not supported Xen dom0 and domU dumpfiles
since the referenced 3.19 commit, and this patch resurrects support
for dom0 dumpfiles only.  Are there issues with live system analysis
as well?  And without the patch, what is the final, fatal error message?  

Thanks,
  Dave

(Continue reading)

Sebastian Ott | 19 Jan 14:26 2016
Picon

crash: invalid structure member offset with current kernels

Hi,

Crash fails to start with current (4.4+) kernels. The following patch
fixes this.

Regards,
Sebastian
----->8

>From ddd809812705ba36796c6750d12a12838b4106ec Mon Sep 17 00:00:00 2001
From: Sebastian Ott <sebott <at> linux.vnet.ibm.com>
Date: Tue, 19 Jan 2016 14:14:13 +0100
Subject: [PATCH] Fix invalid structure member offset.

Struct module was changed by kernel commit
7523e4dc50 "module: use a structure to encapsulate layout."

Fix the offsets to handle the following crash error:

crash: invalid structure member offset: module_init_text_size
       FILE: symbols.c  LINE: 1668  FUNCTION: store_module_symbols_v2()

[../crash/crash] error trace: 10062e92 => 10109812 => 1014f16e => 101813ac

  101813ac: OFFSET_verify+124
  1014f16e: store_module_symbols_v2+2182
  10109812: module_init+4386
  10062e92: main_loop+410

Signed-off-by: Sebastian Ott <sebott <at> linux.vnet.ibm.com>
(Continue reading)

Liu, Jianbo (James | 11 Jan 11:38 2016

failed to do crash analysis after insert custom module in the first kernel.

Hi Experts:

Here is crash tool failed to work issue:

0, it occur on pwoerpc p2041(e500mc) board, p2020(e500v2) will not have this issue.
kernel version: 2.6.34
crash tool version: 6.1.4

1, before trigger kdump, if insert a custom kernel module, the created vmcore will failed to be analysis.

2, before trigger kdump, if no custom kernel module was inserted, the crash can worked well on created vmcore file.

Do you have some comments on this scene?

The error log when run crash tool is here listed for reference:
/*********************************************************************/
/coredump> ./crash.p4 vmlinux.host.20160108nokgdbserial  vmcore-1970-01-01 

crash.p4 6.1.4
Copyright (C) 2002-2013  Red Hat, Inc.
Copyright (C) 2004, 2005, 2006, 2010  IBM Corporation
Copyright (C) 1999-2006  Hewlett-Packard Co
Copyright (C) 2005, 2006, 2011, 2012  Fujitsu Limited
Copyright (C) 2006, 2007  VA Linux Systems Japan K.K.
Copyright (C) 2005, 2011  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 "powerpc-wrs-linux"...

please wait... (gathering module symbol data)   
crash.p4: invalid structure member offset: module_core_size
          FILE: kernel.c  LINE: 2976  FUNCTION: module_init()

[./crash.p4] error trace: 1006b48c => 100deff8 => 1011ac7c => 10067740

  10067740: OFFSET_verify.part.27+76
  1011ac7c: OFFSET_verify+76
  100deff8: module_init+1576
  1006b48c: main_loop+236

root <at> RCU-1:/mnt/userdir/coredump>

/*********************************************************************/




Best Regards,
James


<div>
<div>Hi Experts:<br><br>
Here is crash tool failed to work issue:<br><br>
0, it occur on pwoerpc p2041(e500mc) board, p2020(e500v2) will not have this issue.<br>
kernel version: 2.6.34<br>
crash tool version: 6.1.4<br><br>
1, before trigger kdump, if insert a custom kernel module, the created vmcore will failed to be analysis.<br><br>
2, before trigger kdump, if no custom kernel module was inserted, the crash can worked well on created vmcore file.<br><br>
Do you have some comments on this scene?<br><br>
The error log when run crash tool is here listed for reference:<br>
/*********************************************************************/<br><span>/coredump&gt;&nbsp;./crash.p4&nbsp;vmlinux.host.20160108nokgdbserial&nbsp;&nbsp;vmcore-1970-01-01&nbsp;<br><br>
crash.p4&nbsp;6.1.4<br>
Copyright&nbsp;(C)&nbsp;2002-2013&nbsp;&nbsp;Red&nbsp;Hat,&nbsp;Inc.<br>
Copyright&nbsp;(C)&nbsp;2004,&nbsp;2005,&nbsp;2006,&nbsp;2010&nbsp;&nbsp;IBM&nbsp;Corporation<br>
Copyright&nbsp;(C)&nbsp;1999-2006&nbsp;&nbsp;Hewlett-Packard&nbsp;Co<br>
Copyright&nbsp;(C)&nbsp;2005,&nbsp;2006,&nbsp;2011,&nbsp;2012&nbsp;&nbsp;Fujitsu&nbsp;Limited<br>
Copyright&nbsp;(C)&nbsp;2006,&nbsp;2007&nbsp;&nbsp;VA&nbsp;Linux&nbsp;Systems&nbsp;Japan&nbsp;K.K.<br>
Copyright&nbsp;(C)&nbsp;2005,&nbsp;2011&nbsp;&nbsp;NEC&nbsp;Corporation<br>
Copyright&nbsp;(C)&nbsp;1999,&nbsp;2002,&nbsp;2007&nbsp;&nbsp;Silicon&nbsp;Graphics,&nbsp;Inc.<br>
Copyright&nbsp;(C)&nbsp;1999,&nbsp;2000,&nbsp;2001,&nbsp;2002&nbsp;&nbsp;Mission&nbsp;Critical&nbsp;Linux,&nbsp;Inc.<br>
This&nbsp;program&nbsp;is&nbsp;free&nbsp;software,&nbsp;covered&nbsp;by&nbsp;the&nbsp;GNU&nbsp;General&nbsp;Public&nbsp;License,<br>
and&nbsp;you&nbsp;are&nbsp;welcome&nbsp;to&nbsp;change&nbsp;it&nbsp;and/or&nbsp;distribute&nbsp;copies&nbsp;of&nbsp;it&nbsp;under<br>
certain&nbsp;conditions.&nbsp;&nbsp;Enter&nbsp;"help&nbsp;copying"&nbsp;to&nbsp;see&nbsp;the&nbsp;conditions.<br>
This&nbsp;program&nbsp;has&nbsp;absolutely&nbsp;no&nbsp;warranty.&nbsp;&nbsp;Enter&nbsp;"help&nbsp;warranty"&nbsp;for&nbsp;details.<br>
&nbsp;<br>
GNU&nbsp;gdb&nbsp;(GDB)&nbsp;7.3.1<br>
Copyright&nbsp;(C)&nbsp;2011&nbsp;Free&nbsp;Software&nbsp;Foundation,&nbsp;Inc.<br>
License&nbsp;GPLv3+:&nbsp;GNU&nbsp;GPL&nbsp;version&nbsp;3&nbsp;or&nbsp;later&nbsp;&lt;http://gnu.org/licenses/gpl.html&gt;<br>
This&nbsp;is&nbsp;free&nbsp;software:&nbsp;you&nbsp;are&nbsp;free&nbsp;to&nbsp;change&nbsp;and&nbsp;redistribute&nbsp;it.<br>
There&nbsp;is&nbsp;NO&nbsp;WARRANTY,&nbsp;to&nbsp;the&nbsp;extent&nbsp;permitted&nbsp;by&nbsp;law.&nbsp;&nbsp;Type&nbsp;"show&nbsp;copying"<br>
and&nbsp;"show&nbsp;warranty"&nbsp;for&nbsp;details.<br>
This&nbsp;GDB&nbsp;was&nbsp;configured&nbsp;as&nbsp;"powerpc-wrs-linux"...<br><br>
please&nbsp;wait...&nbsp;(gathering&nbsp;module&nbsp;symbol&nbsp;data)&nbsp;&nbsp;&nbsp;<br>
crash.p4:&nbsp;invalid&nbsp;structure&nbsp;member&nbsp;offset:&nbsp;module_core_size<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;FILE:&nbsp;kernel.c&nbsp;&nbsp;LINE:&nbsp;2976&nbsp;&nbsp;FUNCTION:&nbsp;module_init()<br><br>[./crash.p4]&nbsp;error&nbsp;trace:&nbsp;1006b48c&nbsp;=&gt;&nbsp;100deff8&nbsp;=&gt;&nbsp;1011ac7c&nbsp;=&gt;&nbsp;10067740<br><br>
&nbsp;&nbsp;10067740:&nbsp;OFFSET_verify.part.27+76<br>
&nbsp;&nbsp;1011ac7c:&nbsp;OFFSET_verify+76<br>
&nbsp;&nbsp;100deff8:&nbsp;module_init+1576<br>
&nbsp;&nbsp;1006b48c:&nbsp;main_loop+236<br><br>
root <at> RCU-1:/mnt/userdir/coredump&gt;</span><br>
/*********************************************************************/<br><br><div>
<br><div>
<br><br>Best Regards,<br>
James<br><br><br>
</div>
</div>
</div>
</div>
Liu, Jianbo (James | 11 Jan 10:07 2016

答复: if it's normal to get into kdb shell when run crash

Hi Kumar:

Thanks for your detailed updates.

Very sorry for did not state clearly and bring confusing.

After look into more under your suggestion, this issue has no relation with crash tool.

Thanks very much for your times.


Best Regards,
James

Liu Jianbo | WIND RIVER | Senior Engineer - Technical Support
Tel 86 28 65318098 | Cell 86 13558641588 | Fax 86 28 65319983 

Manage your support account:
https://support.windriver.com

Ask a Technical Question
https://ask.windriver.com

Submit a Service Request
https://windriver.force.com/support

发件人: crash-utility-bounces <at> redhat.com [crash-utility-bounces <at> redhat.com] 代表 Buland Kumar Singh [6b65726e656c <at> gmail.com]
发送时间: 2015年12月30日 22:13
收件人: Discussion list for crash utility usage, maintenance and development
主题: Re: [Crash-utility] if it's normal to get into kdb shell when run crash


On 30 December 2015 at 16:34, Liu, Jianbo (James) <James.Liu <at> windriver.com> wrote:
Hi Experts:

Sorry for disturbing you again.

When I run crash to debug vmcore, if kernel enable kgdb, it will get into kdb shell directly not crash shell, althrough I can get into crash via execute two go command in kdb shell, not sure if it's normal, do you have some comments on it?


When I disnable kgdb in kernel, there will not be this kind of issue, if there is some compatibility problem between kgdb and crash tool?

Thanks for your time and happen new year!!

/****************************************/
root <at> localhost:~/coredump>sh testcoredump.sh; sh startcoredump.sh 
segment[0].mem:0x2000000 memsz:9183232
segment[1].mem:0x28c2000 memsz:65536
segment[2].mem:0x28d2000 memsz:4096
segment[3].mem:0x28d3000 memsz:28672
segment[4].mem:0x2ff5000 memsz:45056
SysRq : Trigger a crash

Entering kdb (current=0xdb17f900, pid 822) on processor 1 Oops: (null)
due to oops  <at>  0xc0348f64
NIP: c0348f64 LR: c034974c CTR: c0348f50
REGS: db18ddc0 TRAP: 0300   Not tainted  (2.6.34.15-grsec-WR4.3.0.0_cgl)
MSR: 00021202 <ME,CE,DE>  CR: 20242444  XER: 00000000
DEAR: 00000000, ESR: 00800000
TASK = db17f900[822] 'sh' THREAD: db18c000 CPU: 1
GPR00: 00000001 db18de70 db17f900 00000063 00000000 ffffffff c035e930 00000000 
GPR08: 00008000 00000000 00000054 118c6000 20242444 100b84b8 100b0828 100b0904 
GPR16: 00000000 00000000 00000000 1006d2d0 00000000 100cc220 1006b530 00000000 
GPR24: 00000001 c0780d24 00029202 c0780e08 c0770000 00000000 c08578a4 00000063 
NIP [c0348f64] sysrq_handle_crash+0x14/0x20
LR [c034974c] __handle_sysrq+0xcc/0x1d0
Call Trace:
[db18de70] [c0349734] __handle_sysrq+0xb4/0x1d0 (unreliable)
[db18dea0] [c03498ac] write_sysrq_trigger+0x5c/0x70
[db18deb0] [c01662f0] proc_reg_write+0x80/0xc0
[db18dee0] [c010ec50] vfs_write+0xc0/0x170
[db18df00] [c010ee80] sys_write+0x50/0x110
[db18df40] [c0011d58] ret_from_syscall+0x0/0x4
--- Exception: c01 at 0xff16ba4
    LR = 0xfebad5c
Instruction dump:
[1]more> 
39600003 7d605f9e 556b103a 7c005b78 98090003 4e800020 60000000 38000001 
3d20c07a 90092170 7c0004ac 39200000 <98090000> 4e800020 60000000 3803ffd0 

[1]kdb>    

[1]kdb> go 
Catastrophic error detected
kdb_continue_catastrophic=0, type go a second time if you really want to continue
[1]kdb> go
Catastrophic error detected
kdb_continue_catastrophic=0, attempting to continue
Oops: Kernel access of bad area, sig: 11 [#1]
PREEMPT SMP NR_CPUS=4 LTT NESTING LEVEL : 0 
P2041 RDB
last sysfs file: /sys/devices/system/cpu/cpu3/crash_notes
Modules linked in:
NIP: c0348f64 LR: c034974c CTR: c0348f50
REGS: db18ddc0 TRAP: 0300   Not tainted  (2.6.34.15-grsec-WR4.3.0.0_cgl)
MSR: 00021202 <ME,CE,DE>  CR: 20242444  XER: 00000000
DEAR: 00000000, ESR: 00800000
TASK = db17f900[822] 'sh' THREAD: db18c000 CPU: 1
GPR00: 00000001 db18de70 db17f900 00000063 00000000 ffffffff c035e930 00000000 
GPR08: 00008000 00000000 00000054 118c6000 20242444 100b84b8 100b0828 100b0904 
GPR16: 00000000 00000000 00000000 1006d2d0 00000000 100cc220 1006b530 00000000 
GPR24: 00000001 c0780d24 00029202 c0780e08 c0770000 00000000 c08578a4 00000063 
NIP [c0348f64] sysrq_handle_crash+0x14/0x20
LR [c034974c] __handle_sysrq+0xcc/0x1d0
Call Trace:
[db18de70] [c0349734] __handle_sysrq+0xb4/0x1d0 (unreliable)
[db18dea0] [c03498ac] write_sysrq_trigger+0x5c/0x70
[db18deb0] [c01662f0] proc_reg_write+0x80/0xc0
[db18dee0] [c010ec50] vfs_write+0xc0/0x170
[db18df00] [c010ee80] sys_write+0x50/0x110
[db18df40] [c0011d58] ret_from_syscall+0x0/0x4
--- Exception: c01 at 0xff16ba4
    LR = 0xfebad5c
Instruction dump:
39600003 7d605f9e 556b103a 7c005b78 98090003 4e800020 60000000 38000001 
3d20c07a 90092170 7c0004ac 39200000 <98090000> 4e800020 60000000 3803ffd0 
Sending IPI to other cpus...
Bye!
Using P2041 RDB machine description

......
/**********************/


Best Regards,
James

Liu Jianbo | WIND RIVER | Senior Engineer - Technical Support
Tel 86 28 65318098 | Cell 86 13558641588 | Fax 86 28 65319983 

Manage your support account:
https://support.windriver.com

Ask a Technical Question
https://ask.windriver.com

Submit a Service Request
https://windriver.force.com/support


--
Crash-utility mailing list
Crash-utility <at> redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility


Hello James,

crash and kgdb are two completely different debuggers to diagnose the kernel
panic issues. You can not access or start the crash from the context of kgdb.

[**crash utility:**]

There are two ways to invoke crash utility[[1]];

1) Typical postmortem debugging: (after panic)

# crash /path/to/vmcore /path/to/vmlinux

o Kernel object file and memory image are supplied, respectively.

2) Live memory debugging:

# crash

o Pre-defined directories are searched for proper vmlinux
o Version string matched to the running kernel (/proc/version)

**OR**

# crash /path/to/vmlinux

[**kdb/kgdb:**][[2]]

1) You can put the target system in debug mode using SysRq event (g).

# echo g > /proc/sysrq-trigger

Eg:
# echo g > /proc/sysrq-trigger
[  181.300854] SysRq : DEBUG

Entering kdb (current=0xffff8800766ebc60, pid 2347) on processor 1 due to Keyboard Entry

[1]kdb> summary
sysname    Linux
release    3.10.84
version    #1 SMP Tue Jul 28 19:53:37 IST 2015
machine    x86_64
nodename   localhost.localdomain
domainname (none)
ccversion  CCVERSION
date       2015-12-30 13:51:06 tz_minuteswest 0
uptime     00:03
load avg   0.11 0.11 0.04

MemTotal:        2050340 kB
MemFree:         1707332 kB
Buffers:             764 kB

1]kdb> dmesg | grep DMI:
<7>[    0.000000] DMI: Red Hat KVM, BIOS 0.5.1 01/01/2007

[1]kdb> bt
Stack traceback for pid 2347
0xffff8800766ebc60     2347      624  1    1   R  0xffff8800766ec240 *bash
 ffff88007bd61e70 0000000000000018
Call Trace:
 <#DB>  <<EOE>>  [<ffffffff810dd84c>] ? sysrq_handle_dbg+0x2c/0x50
 [<ffffffff8134b312>] ? __handle_sysrq+0xa2/0x170
 [<ffffffff8134b80a>] ? write_sysrq_trigger+0x4a/0x50
 [<ffffffff811fb61d>] ? proc_reg_write+0x3d/0x80
 [<ffffffff811993bd>] ? vfs_write+0xbd/0x1e0
 [<ffffffff81199d89>] ? SyS_write+0x49/0xa0
 [<ffffffff815a27c7>] ? tracesys+0xdd/0xe2

[1]kdb> rd
ax: 0000000000000001  bx: ffffffff818a4560  cx: ffff88007fd0eec0
dx: 0000000000000000  si: 0000000000000000  di: 0000000000000067
bp: ffff88007bd61e70  sp: ffff88007bd61e70  r8: ffffffff81b9069c
r9: 0000000000000248  r10: 0000000000000247  r11: 0000000000000003
r12: 0000000000000067  r13: 0000000000000246  r14: 0000000000000007
r15: 0000000000000000  ip: ffffffff810dd7f4  flags: 00000002  cs: 00000010
ss: 00000018  ds: 00000018  es: 00000018  fs: 00000018  gs: 00000018

[1]kdb> go
[  251.553055] systemd-journald[2372]: File /run/log/journal/71b46828837d4b1cb7f04385c86e7626/system.journal corrupted or uncleanly shut down, renaming and replacing.

#  <<<---{ root user }

[Note:] kdb command "go" is used to continue kernel execution. In above case
it will take you back to bash shell.

2) You can crash the target system using SysRq event (c):

# echo c > /proc/sysrq-trigger

Eg:
# echo c > /proc/sysrq-trigger
[   28.963227] SysRq : Trigger a crash
[   28.964025] BUG: unable to handle kernel NULL pointer dereference at           (null)
[   28.964025] IP: [<ffffffff8134abb6>] sysrq_handle_crash+0x16/0x20
[   28.964025] Oops: 0002 [#1] SMP

Entering kdb (current=0xffff880077275a90, pid 2352) on processor 1 Oops: (null)
due to oops <at> 0xffffffff8134abb6
?dCPU: 1 PID: 2352 Comm: bash Not tainted 3.10.84 #1
?dHardware name: Red Hat KVM, BIOS 0.5.1 01/01/2007
?dtask: ffff880077275a90 ti: ffff880076494000 task.ti: ffff880076494000
?dRIP: 0010:[<ffffffff8134abb6>]  [<ffffffff8134abb6>] sysrq_handle_crash+0x16/0x20
?dRSP: 0018:ffff880076495e80  EFLAGS: 00010096
?dRAX: 000000000000000f RBX: ffffffff8190dbc0 RCX: ffff88007fd0eec0
?dRDX: 0000000000000000 RSI: ffff88007fd0d368 RDI: 0000000000000063
?dRBP: ffff880076495e80 R08: ffffffff81b9069c R09: 0000000000000245
?dR10: 0000000000000244 R11: 0000000000000003 R12: 0000000000000063
?dR13: 0000000000000246 R14: 0000000000000007 R15: 0000000000000000
?dFS:  00007f53aec0c740(0000) GS:ffff88007fd00000(0000) knlGS:0000000000000000
?dCS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
?dCR2: 0000000000000000 CR3: 00000000764bd000 CR4: 00000000000006e0
?dDR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
?dDR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
?dStack:
 ffff880076495eb8 ffffffff8134b312 0000000000000002 00007f53aec0a000
 ffff880076495f50 0000000000000002 0000000000000000 ffff880076495ed8
 ffffffff8134b80a 00007f53aec0a000 ffff88007661c000 ffff880076495ef8
?dCall Trace:
more>
Only 'q' or 'Q' are processed at more prompt, input ignored
?d [<ffffffff8134b312>] __handle_sysrq+0xa2/0x170
?d [<ffffffff8134b80a>] write_sysrq_trigger+0x4a/0x50
?d [<ffffffff811fb61d>] proc_reg_write+0x3d/0x80
?d [<ffffffff811993bd>] vfs_write+0xbd/0x1e0
?d [<ffffffff81199d89>] SyS_write+0x49/0xa0
?d [<ffffffff815a27c7>] tracesys+0xdd/0xe2
?dCode: eb 9b 45 01 f4 45 39 65 34 75 e5 4c 89 ef e8 02 f8 ff ff eb db 0f 1f 44 00 00 55 c7 05 20 17 54 00 01 00 00 00 48 89 e5 0f ae f8 <c6> 04 25 00 00 00 00 01 5d c3 0f 1f 44 00 00 55 31 c0 c7 05 7e


[1]kdb> summary
sysname    Linux
release    3.10.84
version    #1 SMP Tue Jul 28 19:53:37 IST 2015
machine    x86_64
nodename   localhost.localdomain
domainname (none)
ccversion  CCVERSION
date       2015-12-30 14:07:49 tz_minuteswest 0
uptime     00:01
load avg   0.95 0.21 0.06

MemTotal:        2050340 kB
MemFree:         1775224 kB
Buffers:             764 kB

[1]kdb> bt
Stack traceback for pid 2352
0xffff880077275a90     2352      629  1    1   R  0xffff880077276070 *bash
 ffff880076495e80 0000000000000018 ffff880076495eb8 ffffffff8134b312
 0000000000000002 00007f53aec0a000 ffff880076495f50 0000000000000002
 0000000000000000 ffff880076495ed8 ffffffff8134b80a 00007f53aec0a000
Call Trace:
 [<ffffffff8134b312>] ? __handle_sysrq+0xa2/0x170
 [<ffffffff8134b80a>] ? write_sysrq_trigger+0x4a/0x50
 [<ffffffff811fb61d>] ? proc_reg_write+0x3d/0x80
 [<ffffffff811993bd>] ? vfs_write+0xbd/0x1e0
 [<ffffffff81199d89>] ? SyS_write+0x49/0xa0
 [<ffffffff815a27c7>] ? tracesys+0xdd/0xe2

[1]kdb> rd
ax: 000000000000000f  bx: ffffffff8190dbc0  cx: ffff88007fd0eec0
dx: 0000000000000000  si: 0000000000000000  di: 0000000000000063
bp: ffff880076495e80  sp: ffff880076495e80  r8: ffffffff81b9069c
r9: 0000000000000245  r10: 0000000000000244  r11: 0000000000000003
r12: 0000000000000063  r13: 0000000000000246  r14: 0000000000000007
r15: 0000000000000000  ip: ffffffff8134abb6  flags: 00010096  cs: 00000010
ss: 00000018  ds: 00000018  es: 00000018  fs: 00000018  gs: 00000018

[1]kdb> go
Catastrophic error detected
kdb_continue_catastrophic=0, type go a second time if you really want to continue

[1]kdb> go
Catastrophic error detected
kdb_continue_catastrophic=0, attempting to continue
[   28.964025] Modules linked in: ip6t_rpfilter ip6t_REJECT ipt_REJECT xt_conntrack ebtable_nat ebtable_broute bridge stp llc ebtable_filter ebtables ip6table_nat nf_conntrack_ipv6 nf_defrag_ipv6 nf_nat_ipv6 ip6table_mangle ip6table_security ip6table_raw ip6table_filter ip6_tables iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack iptable_mangle iptable_security iptable_raw iptable_filter snd_hda_intel snd_hda_codec snd_hwdep snd_seq snd_seq_device snd_pcm snd_page_alloc snd_timer snd serio_raw pcspkr i2c_piix4 virtio_balloon soundcore nfsd auth_rpcgss nfs_acl lockd sunrpc ip_tables xfs libcrc32c ata_generic pata_acpi ata_piix cirrus syscopyarea sysfillrect sysimgblt drm_kms_helper ttm virtio_net virtio_blk drm libata virtio_pci virtio_ring virtio i2c_core floppy dm_mirror dm_region_hash dm_log dm_mod
[  112.090263] Hardware name: Red Hat KVM, BIOS 0.5.1 01/01/2007
[  112.090263] task: ffff880077275a90 ti: ffff880076494000 task.ti: ffff880076494000
[  112.090263] RIP: 0010:[<ffffffff8134abb6>]  [<ffffffff8134abb6>] sysrq_handle_crash+0x16/0x20
[  112.090263] RSP: 0018:ffff880076495e80  EFLAGS: 00010096
[  112.090263] RAX: 000000000000000f RBX: ffffffff8190dbc0 RCX: ffff88007fd0eec0
[  112.090263] RDX: 0000000000000000 RSI: ffff88007fd0d368 RDI: 0000000000000063
[  112.090263] RBP: ffff880076495e80 R08: ffffffff81b9069c R09: 0000000000000245
[  112.090263] R10: 0000000000000244 R11: 0000000000000003 R12: 0000000000000063
[  112.090263] R13: 0000000000000246 R14: 0000000000000007 R15: 0000000000000000
[  112.090263] FS:  00007f53aec0c740(0000) GS:ffff88007fd00000(0000) knlGS:0000000000000000
[  112.090263] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[  112.090263] CR2: 0000000000000000 CR3: 00000000764bd000 CR4: 00000000000006e0
[  112.090263] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[  112.104034] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
[  112.104034] Stack:
[  112.104034]  ffff880076495eb8 ffffffff8134b312 0000000000000002 00007f53aec0a000
[  112.104034]  ffff880076495f50 0000000000000002 0000000000000000 ffff880076495ed8
[  112.104034]  ffffffff8134b80a 00007f53aec0a000 ffff88007661c000 ffff880076495ef8
[  112.104034] Call Trace:
[  112.104034]  [<ffffffff8134b312>] __handle_sysrq+0xa2/0x170
[  112.104034]  [<ffffffff8134b80a>] write_sysrq_trigger+0x4a/0x50
[  112.104034]  [<ffffffff811fb61d>] proc_reg_write+0x3d/0x80
[  112.104034]  [<ffffffff811993bd>] vfs_write+0xbd/0x1e0
[  112.104034]  [<ffffffff81199d89>] SyS_write+0x49/0xa0
[  112.104034]  [<ffffffff815a27c7>] tracesys+0xdd/0xe2
[  112.104034] Code: eb 9b 45 01 f4 45 39 65 34 75 e5 4c 89 ef e8 02 f8 ff ff eb db 0f 1f 44 00 00 55 c7 05 20 17 54 00 01 00 00 00 48 89 e5 0f ae f8 <c6> 04 25 00 00 00 00 01 5d c3 0f 1f 44 00 00 55 31 c0 c7 05 7e
[  112.104034] RIP  [<ffffffff8134abb6>] sysrq_handle_crash+0x16/0x20
[  112.104034]  RSP <ffff880076495e80>
[  112.104034] CR2: 0000000000000000
[  112.104034] ---[ end trace 4484e44d0167e21c ]---
[  112.104034] Kernel panic - not syncing: Fatal exception
PANIC: Fatal exception

Entering kdb (current=0xffff880077275a90, pid 2352) on processor 1 due to Keyboard Entry

[Note:] kdb command "go" is used to continue kernel execution. In above case
it will not take you back to bash shell. :)

Few questions for you;

[Q:1] What exactly you are trying to achieve ?
[Q:2] What is the exact issue ?

Regards,
BKS

[[1]] http://people.redhat.com/anderson/crash_whitepaper/#INVOCATION
[[2]] https://www.kernel.org/pub/linux/kernel/people/jwessel/kdb/

<div>
<div>Hi Kumar:<br><br>
Thanks for your detailed updates.<br><br>
Very sorry for did not state clearly and bring confusing.<br><span dir="ltr"><br>
After look into more under your suggestion, this issue has no relation with crash tool.<br><br>
Thanks very much for your times.<br></span>
<div>
<div>
<br><br>Best Regards,<br>
James<br><br>
Liu Jianbo | WIND RIVER | Senior Engineer - Technical Support<br>
Tel 86 28 65318098 | Cell 86 13558641588 | Fax 86 28 65319983&nbsp; <br><br>Manage your support account:<br>https://support.windriver.com <br><br>
Ask a Technical Question<br>https://ask.windriver.com <br><br>
Submit a Service Request<br>https://windriver.force.com/support<br><br>
</div>
</div>
<div>
<div>&#21457;&#20214;&#20154;: crash-utility-bounces <at> redhat.com [crash-utility-bounces <at> redhat.com] &#20195;&#34920; Buland Kumar Singh [6b65726e656c <at> gmail.com]<br>&#21457;&#36865;&#26102;&#38388;: 2015&#24180;12&#26376;30&#26085; 22:13<br>&#25910;&#20214;&#20154;: Discussion list for crash utility usage, maintenance and development<br>&#20027;&#39064;: Re: [Crash-utility] if it's normal to get into kdb shell when run crash<br><br>
</div>
<div></div>
<div>
<div dir="ltr">
<br><div class="gmail_extra">
<div class="gmail_quote">On 30 December 2015 at 16:34, Liu, Jianbo (James) <span dir="ltr">
&lt;<a href="mailto:James.Liu <at> windriver.com" target="_blank">James.Liu <at> windriver.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote">
<div>
<div>Hi Experts:
<div><br></div>
<div>Sorry for disturbing you again.</div>
<div><br></div>
<div>When I run crash to debug vmcore, if kernel enable kgdb, it will get into kdb shell directly not crash shell, althrough I can get into crash via execute two go command in kdb shell, not sure if it's normal, do you have some comments on it?<br><div><br></div>
<div><br></div>
<div>When I disnable kgdb in kernel, there will not be this kind of issue, if there is some compatibility problem between kgdb and crash tool?</div>
<div><br></div>
<div>Thanks for your time and happen new year!!</div>
<div><br></div>
<div>/****************************************/</div>
<div>
<span>root <at> localhost:~/coredump&gt;sh&nbsp;testcoredump.sh;&nbsp;sh&nbsp;startcoredump.sh&nbsp;</span><br><span>segment[0].mem:0x2000000&nbsp;memsz:9183232</span><br><span>segment[1].mem:0x28c2000&nbsp;memsz:65536</span><br><span>segment[2].mem:0x28d2000&nbsp;memsz:4096</span><br><span>segment[3].mem:0x28d3000&nbsp;memsz:28672</span><br><span>segment[4].mem:0x2ff5000&nbsp;memsz:45056</span><br><span>SysRq&nbsp;:&nbsp;Trigger&nbsp;a&nbsp;crash</span><br><br><span>Entering&nbsp;kdb&nbsp;(current=0xdb17f900,&nbsp;pid&nbsp;822)&nbsp;on&nbsp;processor&nbsp;1&nbsp;Oops:&nbsp;(null)</span><br><span>due&nbsp;to&nbsp;oops&nbsp; <at> &nbsp;0xc0348f64</span><br><span>NIP:&nbsp;c0348f64&nbsp;LR:&nbsp;c034974c&nbsp;CTR:&nbsp;c0348f50</span><br><span>REGS:&nbsp;db18ddc0&nbsp;TRAP:&nbsp;0300&nbsp;&nbsp;&nbsp;Not&nbsp;tainted&nbsp;&nbsp;(2.6.34.15-grsec-WR4.3.0.0_cgl)</span><br><span>MSR:&nbsp;00021202&nbsp;&lt;ME,CE,DE&gt;&nbsp;&nbsp;CR:&nbsp;20242444&nbsp;&nbsp;XER:&nbsp;00000000</span><br><span>DEAR:&nbsp;00000000,&nbsp;ESR:&nbsp;00800000</span><br><span>TASK&nbsp;=&nbsp;db17f900[822]&nbsp;'sh'&nbsp;THREAD:&nbsp;db18c000&nbsp;CPU:&nbsp;1</span><br><span>GPR00:&nbsp;00000001&nbsp;db18de70&nbsp;db17f900&nbsp;00000063&nbsp;00000000&nbsp;ffffffff&nbsp;c035e930&nbsp;00000000&nbsp;</span><br><span>GPR08:&nbsp;00008000&nbsp;00000000&nbsp;00000054&nbsp;118c6000&nbsp;20242444&nbsp;100b84b8&nbsp;100b0828&nbsp;100b0904&nbsp;</span><br><span>GPR16:&nbsp;00000000&nbsp;00000000&nbsp;00000000&nbsp;1006d2d0&nbsp;00000000&nbsp;100cc220&nbsp;1006b530&nbsp;00000000&nbsp;</span><br><span>GPR24:&nbsp;00000001&nbsp;c0780d24&nbsp;00029202&nbsp;c0780e08&nbsp;c0770000&nbsp;00000000&nbsp;c08578a4&nbsp;00000063&nbsp;</span><br><span>NIP&nbsp;[c0348f64]&nbsp;sysrq_handle_crash+0x14/0x20</span><br><span>LR&nbsp;[c034974c]&nbsp;__handle_sysrq+0xcc/0x1d0</span><br><span>Call&nbsp;Trace:</span><br><span>[db18de70]&nbsp;[c0349734]&nbsp;__handle_sysrq+0xb4/0x1d0&nbsp;(unreliable)</span><br><span>[db18dea0]&nbsp;[c03498ac]&nbsp;write_sysrq_trigger+0x5c/0x70</span><br><span>[db18deb0]&nbsp;[c01662f0]&nbsp;proc_reg_write+0x80/0xc0</span><br><span>[db18dee0]&nbsp;[c010ec50]&nbsp;vfs_write+0xc0/0x170</span><br><span>[db18df00]&nbsp;[c010ee80]&nbsp;sys_write+0x50/0x110</span><br><span>[db18df40]&nbsp;[c0011d58]&nbsp;ret_from_syscall+0x0/0x4</span><br><span>---&nbsp;Exception:&nbsp;c01&nbsp;at&nbsp;0xff16ba4</span><br><span>&nbsp;&nbsp;&nbsp;&nbsp;LR&nbsp;=&nbsp;0xfebad5c</span><br><span>Instruction&nbsp;dump:</span><br><span>[1]more&gt;&nbsp;</span><br><span>39600003&nbsp;7d605f9e&nbsp;556b103a&nbsp;7c005b78&nbsp;98090003&nbsp;4e800020&nbsp;60000000&nbsp;38000001&nbsp;</span><br><span>3d20c07a&nbsp;90092170&nbsp;7c0004ac&nbsp;39200000&nbsp;&lt;98090000&gt;&nbsp;4e800020&nbsp;60000000&nbsp;3803ffd0&nbsp;</span><br><br><span>[1]kdb&gt;&nbsp;&nbsp;&nbsp;&nbsp;</span><br><br><span>[1]kdb&gt;</span>&nbsp;go&nbsp;<br><span>Catastrophic&nbsp;error&nbsp;detected</span><br><span>kdb_continue_catastrophic=0,&nbsp;type&nbsp;go&nbsp;a&nbsp;second&nbsp;time&nbsp;if&nbsp;you&nbsp;really&nbsp;want&nbsp;to&nbsp;continue</span><br><span>[1]kdb&gt;&nbsp;</span>go<br><span>Catastrophic&nbsp;error&nbsp;detected</span><br><span>kdb_continue_catastrophic=0,&nbsp;attempting&nbsp;to&nbsp;continue</span><br><span>Oops:&nbsp;Kernel&nbsp;access&nbsp;of&nbsp;bad&nbsp;area,&nbsp;sig:&nbsp;11&nbsp;[#1]</span><br><span>PREEMPT&nbsp;SMP&nbsp;NR_CPUS=4&nbsp;LTT&nbsp;NESTING&nbsp;LEVEL&nbsp;:&nbsp;0&nbsp;</span><br><span>P2041&nbsp;RDB</span><br><span>last&nbsp;sysfs&nbsp;file:&nbsp;/sys/devices/system/cpu/cpu3/crash_notes</span><br><span>Modules&nbsp;linked&nbsp;in:</span><br><span>NIP:&nbsp;c0348f64&nbsp;LR:&nbsp;c034974c&nbsp;CTR:&nbsp;c0348f50</span><br><span>REGS:&nbsp;db18ddc0&nbsp;TRAP:&nbsp;0300&nbsp;&nbsp;&nbsp;Not&nbsp;tainted&nbsp;&nbsp;(2.6.34.15-grsec-WR4.3.0.0_cgl)</span><br><span>MSR:&nbsp;00021202&nbsp;&lt;ME,CE,DE&gt;&nbsp;&nbsp;CR:&nbsp;20242444&nbsp;&nbsp;XER:&nbsp;00000000</span><br><span>DEAR:&nbsp;00000000,&nbsp;ESR:&nbsp;00800000</span><br><span>TASK&nbsp;=&nbsp;db17f900[822]&nbsp;'sh'&nbsp;THREAD:&nbsp;db18c000&nbsp;CPU:&nbsp;1</span><br><span>GPR00:&nbsp;00000001&nbsp;db18de70&nbsp;db17f900&nbsp;00000063&nbsp;00000000&nbsp;ffffffff&nbsp;c035e930&nbsp;00000000&nbsp;</span><br><span>GPR08:&nbsp;00008000&nbsp;00000000&nbsp;00000054&nbsp;118c6000&nbsp;20242444&nbsp;100b84b8&nbsp;100b0828&nbsp;100b0904&nbsp;</span><br><span>GPR16:&nbsp;00000000&nbsp;00000000&nbsp;00000000&nbsp;1006d2d0&nbsp;00000000&nbsp;100cc220&nbsp;1006b530&nbsp;00000000&nbsp;</span><br><span>GPR24:&nbsp;00000001&nbsp;c0780d24&nbsp;00029202&nbsp;c0780e08&nbsp;c0770000&nbsp;00000000&nbsp;c08578a4&nbsp;00000063&nbsp;</span><br><span>NIP&nbsp;[c0348f64]&nbsp;sysrq_handle_crash+0x14/0x20</span><br><span>LR&nbsp;[c034974c]&nbsp;__handle_sysrq+0xcc/0x1d0</span><br><span>Call&nbsp;Trace:</span><br><span>[db18de70]&nbsp;[c0349734]&nbsp;__handle_sysrq+0xb4/0x1d0&nbsp;(unreliable)</span><br><span>[db18dea0]&nbsp;[c03498ac]&nbsp;write_sysrq_trigger+0x5c/0x70</span><br><span>[db18deb0]&nbsp;[c01662f0]&nbsp;proc_reg_write+0x80/0xc0</span><br><span>[db18dee0]&nbsp;[c010ec50]&nbsp;vfs_write+0xc0/0x170</span><br><span>[db18df00]&nbsp;[c010ee80]&nbsp;sys_write+0x50/0x110</span><br><span>[db18df40]&nbsp;[c0011d58]&nbsp;ret_from_syscall+0x0/0x4</span><br><span>---&nbsp;Exception:&nbsp;c01&nbsp;at&nbsp;0xff16ba4</span><br><span>&nbsp;&nbsp;&nbsp;&nbsp;LR&nbsp;=&nbsp;0xfebad5c</span><br><span>Instruction&nbsp;dump:</span><br><span>39600003&nbsp;7d605f9e&nbsp;556b103a&nbsp;7c005b78&nbsp;98090003&nbsp;4e800020&nbsp;60000000&nbsp;38000001&nbsp;</span><br><span>3d20c07a&nbsp;90092170&nbsp;7c0004ac&nbsp;39200000&nbsp;&lt;98090000&gt;&nbsp;4e800020&nbsp;60000000&nbsp;3803ffd0&nbsp;</span><br><span>Sending&nbsp;IPI&nbsp;to&nbsp;other&nbsp;cpus...</span><br><span>Bye!</span><br><span>Using&nbsp;P2041&nbsp;RDB&nbsp;machine&nbsp;description</span>
</div>
<div><span><br></span></div>
<div><span>......</span></div>
<div>
<span>/**********************/<br></span>
<div>
<br><br>Best Regards,<br>
James<br><br>
Liu Jianbo | WIND RIVER | Senior Engineer - Technical Support<br>
Tel 86 28 65318098 | Cell 86 13558641588 | Fax 86 28 65319983&nbsp; <br><br>Manage your support account:<br><a href="https://support.windriver.com" target="_blank">https://support.windriver.com</a>
<br><br>
Ask a Technical Question<br><a href="https://ask.windriver.com" target="_blank">https://ask.windriver.com</a>
<br><br>
Submit a Service Request<br><a href="https://windriver.force.com/support" target="_blank">https://windriver.force.com/support</a><br><br>
</div>
</div>
</div>
<div></div>
<div></div>
</div>
</div>
<br>
--<br>
Crash-utility mailing list<br><a href="mailto:Crash-utility <at> redhat.com" target="_blank">Crash-utility <at> redhat.com</a><br><a href="https://www.redhat.com/mailman/listinfo/crash-utility" rel="noreferrer" target="_blank">https://www.redhat.com/mailman/listinfo/crash-utility</a><br>
</blockquote>
</div>
<br><br clear="all">
Hello James,<br><br>
crash and kgdb are two completely different debuggers to diagnose the kernel <br>
panic issues. You can not access or start the crash from the context of kgdb.<br><br>
[**crash utility:**]<br><br>
There are two ways to invoke crash utility[[1]];<br><br>
1) Typical postmortem debugging: (after panic)<br><br>
# crash /path/to/vmcore /path/to/vmlinux<br><br>
o Kernel object file and memory image are supplied, respectively.<br><br>
2) Live memory debugging:<br><br>
# crash <br><br>
o Pre-defined directories are searched for proper vmlinux<br>
o Version string matched to the running kernel (/proc/version)<br><br>
**OR**<br><br>
# crash /path/to/vmlinux<br><br>
[**kdb/kgdb:**][[2]]<br><br>
1) You can put the target system in debug mode using SysRq event (g).<br><br>
# echo g &gt; /proc/sysrq-trigger <br><br>
Eg:<br>
# echo g &gt; /proc/sysrq-trigger <br>
[&nbsp; 181.300854] SysRq : DEBUG<br><br>
Entering kdb (current=0xffff8800766ebc60, pid 2347) on processor 1 due to Keyboard Entry<br><br>
[1]kdb&gt; summary <br>
sysname&nbsp;&nbsp;&nbsp; Linux<br>
release&nbsp;&nbsp;&nbsp; 3.10.84<br>
version&nbsp;&nbsp;&nbsp; #1 SMP Tue Jul 28 19:53:37 IST 2015<br>
machine&nbsp;&nbsp;&nbsp; x86_64<br>
nodename&nbsp;&nbsp; localhost.localdomain<br>
domainname (none)<br>
ccversion&nbsp; CCVERSION<br>
date&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 2015-12-30 13:51:06 tz_minuteswest 0<br>
uptime&nbsp;&nbsp;&nbsp;&nbsp; 00:03<br>
load avg&nbsp;&nbsp; 0.11 0.11 0.04<br><br>
MemTotal:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 2050340 kB<br>
MemFree:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 1707332 kB<br>
Buffers:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 764 kB<br><br>
1]kdb&gt; dmesg | grep DMI:<br>
&lt;7&gt;[&nbsp;&nbsp;&nbsp; 0.000000] DMI: Red Hat KVM, BIOS 0.5.1 01/01/2007<br><br>
[1]kdb&gt; bt<br>
Stack traceback for pid 2347<br>
0xffff8800766ebc60&nbsp;&nbsp;&nbsp;&nbsp; 2347&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 624&nbsp; 1&nbsp;&nbsp;&nbsp; 1&nbsp;&nbsp; R&nbsp; 0xffff8800766ec240 *bash<br>
&nbsp;ffff88007bd61e70 0000000000000018<br>
Call Trace:<br>
&nbsp;&lt;#DB&gt;&nbsp; &lt;&lt;EOE&gt;&gt;&nbsp; [&lt;ffffffff810dd84c&gt;] ? sysrq_handle_dbg+0x2c/0x50<br>
&nbsp;[&lt;ffffffff8134b312&gt;] ? __handle_sysrq+0xa2/0x170<br>
&nbsp;[&lt;ffffffff8134b80a&gt;] ? write_sysrq_trigger+0x4a/0x50<br>
&nbsp;[&lt;ffffffff811fb61d&gt;] ? proc_reg_write+0x3d/0x80<br>
&nbsp;[&lt;ffffffff811993bd&gt;] ? vfs_write+0xbd/0x1e0<br>
&nbsp;[&lt;ffffffff81199d89&gt;] ? SyS_write+0x49/0xa0<br>
&nbsp;[&lt;ffffffff815a27c7&gt;] ? tracesys+0xdd/0xe2<br><br>
[1]kdb&gt; rd<br>
ax: 0000000000000001&nbsp; bx: ffffffff818a4560&nbsp; cx: ffff88007fd0eec0<br>
dx: 0000000000000000&nbsp; si: 0000000000000000&nbsp; di: 0000000000000067<br>
bp: ffff88007bd61e70&nbsp; sp: ffff88007bd61e70&nbsp; r8: ffffffff81b9069c<br>
r9: 0000000000000248&nbsp; r10: 0000000000000247&nbsp; r11: 0000000000000003<br>
r12: 0000000000000067&nbsp; r13: 0000000000000246&nbsp; r14: 0000000000000007<br>
r15: 0000000000000000&nbsp; ip: ffffffff810dd7f4&nbsp; flags: 00000002&nbsp; cs: 00000010<br>
ss: 00000018&nbsp; ds: 00000018&nbsp; es: 00000018&nbsp; fs: 00000018&nbsp; gs: 00000018<br><br>
[1]kdb&gt; go<br>
[&nbsp; 251.553055] systemd-journald[2372]: File /run/log/journal/71b46828837d4b1cb7f04385c86e7626/system.journal corrupted or uncleanly shut down, renaming and replacing.<br><br>
#&nbsp; &lt;&lt;&lt;---{ root user }<br><br>
[Note:] kdb command "go" is used to continue kernel execution. In above case <br>
it will take you back to bash shell.<br><br>
2) You can crash the target system using SysRq event (c):<br><br>
# echo c &gt; /proc/sysrq-trigger <br><br>
Eg:<br>
# echo c &gt; /proc/sysrq-trigger <br>
[&nbsp;&nbsp; 28.963227] SysRq : Trigger a crash<br>
[&nbsp;&nbsp; 28.964025] BUG: unable to handle kernel NULL pointer dereference at&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; (null)<br>
[&nbsp;&nbsp; 28.964025] IP: [&lt;ffffffff8134abb6&gt;] sysrq_handle_crash+0x16/0x20<br>
[&nbsp;&nbsp; 28.964025] Oops: 0002 [#1] SMP <br><br>
Entering kdb (current=0xffff880077275a90, pid 2352) on processor 1 Oops: (null)<br>
due to oops  <at>  0xffffffff8134abb6<br>
?dCPU: 1 PID: 2352 Comm: bash Not tainted 3.10.84 #1<br>
?dHardware name: Red Hat KVM, BIOS 0.5.1 01/01/2007<br>
?dtask: ffff880077275a90 ti: ffff880076494000 task.ti: ffff880076494000<br>
?dRIP: 0010:[&lt;ffffffff8134abb6&gt;]&nbsp; [&lt;ffffffff8134abb6&gt;] sysrq_handle_crash+0x16/0x20<br>
?dRSP: 0018:ffff880076495e80&nbsp; EFLAGS: 00010096<br>
?dRAX: 000000000000000f RBX: ffffffff8190dbc0 RCX: ffff88007fd0eec0<br>
?dRDX: 0000000000000000 RSI: ffff88007fd0d368 RDI: 0000000000000063<br>
?dRBP: ffff880076495e80 R08: ffffffff81b9069c R09: 0000000000000245<br>
?dR10: 0000000000000244 R11: 0000000000000003 R12: 0000000000000063<br>
?dR13: 0000000000000246 R14: 0000000000000007 R15: 0000000000000000<br>
?dFS:&nbsp; 00007f53aec0c740(0000) GS:ffff88007fd00000(0000) knlGS:0000000000000000<br>
?dCS:&nbsp; 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br>
?dCR2: 0000000000000000 CR3: 00000000764bd000 CR4: 00000000000006e0<br>
?dDR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br>
?dDR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400<br>
?dStack:<br>
&nbsp;ffff880076495eb8 ffffffff8134b312 0000000000000002 00007f53aec0a000<br>
&nbsp;ffff880076495f50 0000000000000002 0000000000000000 ffff880076495ed8<br>
&nbsp;ffffffff8134b80a 00007f53aec0a000 ffff88007661c000 ffff880076495ef8<br>
?dCall Trace:<br>
more&gt; <br>
Only 'q' or 'Q' are processed at more prompt, input ignored<br>
?d [&lt;ffffffff8134b312&gt;] __handle_sysrq+0xa2/0x170<br>
?d [&lt;ffffffff8134b80a&gt;] write_sysrq_trigger+0x4a/0x50<br>
?d [&lt;ffffffff811fb61d&gt;] proc_reg_write+0x3d/0x80<br>
?d [&lt;ffffffff811993bd&gt;] vfs_write+0xbd/0x1e0<br>
?d [&lt;ffffffff81199d89&gt;] SyS_write+0x49/0xa0<br>
?d [&lt;ffffffff815a27c7&gt;] tracesys+0xdd/0xe2<br>
?dCode: eb 9b 45 01 f4 45 39 65 34 75 e5 4c 89 ef e8 02 f8 ff ff eb db 0f 1f 44 00 00 55 c7 05 20 17 54 00 01 00 00 00 48 89 e5 0f ae f8 &lt;c6&gt; 04 25 00 00 00 00 01 5d c3 0f 1f 44 00 00 55 31 c0 c7 05 7e
<br><br><br>
[1]kdb&gt; summary<br>
sysname&nbsp;&nbsp;&nbsp; Linux<br>
release&nbsp;&nbsp;&nbsp; 3.10.84<br>
version&nbsp;&nbsp;&nbsp; #1 SMP Tue Jul 28 19:53:37 IST 2015<br>
machine&nbsp;&nbsp;&nbsp; x86_64<br>
nodename&nbsp;&nbsp; localhost.localdomain<br>
domainname (none)<br>
ccversion&nbsp; CCVERSION<br>
date&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 2015-12-30 14:07:49 tz_minuteswest 0<br>
uptime&nbsp;&nbsp;&nbsp;&nbsp; 00:01<br>
load avg&nbsp;&nbsp; 0.95 0.21 0.06<br><br>
MemTotal:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 2050340 kB<br>
MemFree:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 1775224 kB<br>
Buffers:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 764 kB<br><br>
[1]kdb&gt; bt<br>
Stack traceback for pid 2352<br>
0xffff880077275a90&nbsp;&nbsp;&nbsp;&nbsp; 2352&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 629&nbsp; 1&nbsp;&nbsp;&nbsp; 1&nbsp;&nbsp; R&nbsp; 0xffff880077276070 *bash<br>
&nbsp;ffff880076495e80 0000000000000018 ffff880076495eb8 ffffffff8134b312<br>
&nbsp;0000000000000002 00007f53aec0a000 ffff880076495f50 0000000000000002<br>
&nbsp;0000000000000000 ffff880076495ed8 ffffffff8134b80a 00007f53aec0a000<br>
Call Trace:<br>
&nbsp;[&lt;ffffffff8134b312&gt;] ? __handle_sysrq+0xa2/0x170<br>
&nbsp;[&lt;ffffffff8134b80a&gt;] ? write_sysrq_trigger+0x4a/0x50<br>
&nbsp;[&lt;ffffffff811fb61d&gt;] ? proc_reg_write+0x3d/0x80<br>
&nbsp;[&lt;ffffffff811993bd&gt;] ? vfs_write+0xbd/0x1e0<br>
&nbsp;[&lt;ffffffff81199d89&gt;] ? SyS_write+0x49/0xa0<br>
&nbsp;[&lt;ffffffff815a27c7&gt;] ? tracesys+0xdd/0xe2<br><br>
[1]kdb&gt; rd<br>
ax: 000000000000000f&nbsp; bx: ffffffff8190dbc0&nbsp; cx: ffff88007fd0eec0<br>
dx: 0000000000000000&nbsp; si: 0000000000000000&nbsp; di: 0000000000000063<br>
bp: ffff880076495e80&nbsp; sp: ffff880076495e80&nbsp; r8: ffffffff81b9069c<br>
r9: 0000000000000245&nbsp; r10: 0000000000000244&nbsp; r11: 0000000000000003<br>
r12: 0000000000000063&nbsp; r13: 0000000000000246&nbsp; r14: 0000000000000007<br>
r15: 0000000000000000&nbsp; ip: ffffffff8134abb6&nbsp; flags: 00010096&nbsp; cs: 00000010<br>
ss: 00000018&nbsp; ds: 00000018&nbsp; es: 00000018&nbsp; fs: 00000018&nbsp; gs: 00000018<br><br>
[1]kdb&gt; go<br>
Catastrophic error detected<br>
kdb_continue_catastrophic=0, type go a second time if you really want to continue<br><br>
[1]kdb&gt; go<br>
Catastrophic error detected<br>
kdb_continue_catastrophic=0, attempting to continue<br>
[&nbsp;&nbsp; 28.964025] Modules linked in: ip6t_rpfilter ip6t_REJECT ipt_REJECT xt_conntrack ebtable_nat ebtable_broute bridge stp llc ebtable_filter ebtables ip6table_nat nf_conntrack_ipv6 nf_defrag_ipv6 nf_nat_ipv6 ip6table_mangle ip6table_security ip6table_raw ip6table_filter
 ip6_tables iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack iptable_mangle iptable_security iptable_raw iptable_filter snd_hda_intel snd_hda_codec snd_hwdep snd_seq snd_seq_device snd_pcm snd_page_alloc snd_timer snd serio_raw pcspkr
 i2c_piix4 virtio_balloon soundcore nfsd auth_rpcgss nfs_acl lockd sunrpc ip_tables xfs libcrc32c ata_generic pata_acpi ata_piix cirrus syscopyarea sysfillrect sysimgblt drm_kms_helper ttm virtio_net virtio_blk drm libata virtio_pci virtio_ring virtio i2c_core
 floppy dm_mirror dm_region_hash dm_log dm_mod<br>
[&nbsp; 112.090263] Hardware name: Red Hat KVM, BIOS 0.5.1 01/01/2007<br>
[&nbsp; 112.090263] task: ffff880077275a90 ti: ffff880076494000 task.ti: ffff880076494000<br>
[&nbsp; 112.090263] RIP: 0010:[&lt;ffffffff8134abb6&gt;]&nbsp; [&lt;ffffffff8134abb6&gt;] sysrq_handle_crash+0x16/0x20<br>
[&nbsp; 112.090263] RSP: 0018:ffff880076495e80&nbsp; EFLAGS: 00010096<br>
[&nbsp; 112.090263] RAX: 000000000000000f RBX: ffffffff8190dbc0 RCX: ffff88007fd0eec0<br>
[&nbsp; 112.090263] RDX: 0000000000000000 RSI: ffff88007fd0d368 RDI: 0000000000000063<br>
[&nbsp; 112.090263] RBP: ffff880076495e80 R08: ffffffff81b9069c R09: 0000000000000245<br>
[&nbsp; 112.090263] R10: 0000000000000244 R11: 0000000000000003 R12: 0000000000000063<br>
[&nbsp; 112.090263] R13: 0000000000000246 R14: 0000000000000007 R15: 0000000000000000<br>
[&nbsp; 112.090263] FS:&nbsp; 00007f53aec0c740(0000) GS:ffff88007fd00000(0000) knlGS:0000000000000000<br>
[&nbsp; 112.090263] CS:&nbsp; 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br>
[&nbsp; 112.090263] CR2: 0000000000000000 CR3: 00000000764bd000 CR4: 00000000000006e0<br>
[&nbsp; 112.090263] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br>
[&nbsp; 112.104034] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400<br>
[&nbsp; 112.104034] Stack:<br>
[&nbsp; 112.104034]&nbsp; ffff880076495eb8 ffffffff8134b312 0000000000000002 00007f53aec0a000<br>
[&nbsp; 112.104034]&nbsp; ffff880076495f50 0000000000000002 0000000000000000 ffff880076495ed8<br>
[&nbsp; 112.104034]&nbsp; ffffffff8134b80a 00007f53aec0a000 ffff88007661c000 ffff880076495ef8<br>
[&nbsp; 112.104034] Call Trace:<br>
[&nbsp; 112.104034]&nbsp; [&lt;ffffffff8134b312&gt;] __handle_sysrq+0xa2/0x170<br>
[&nbsp; 112.104034]&nbsp; [&lt;ffffffff8134b80a&gt;] write_sysrq_trigger+0x4a/0x50<br>
[&nbsp; 112.104034]&nbsp; [&lt;ffffffff811fb61d&gt;] proc_reg_write+0x3d/0x80<br>
[&nbsp; 112.104034]&nbsp; [&lt;ffffffff811993bd&gt;] vfs_write+0xbd/0x1e0<br>
[&nbsp; 112.104034]&nbsp; [&lt;ffffffff81199d89&gt;] SyS_write+0x49/0xa0<br>
[&nbsp; 112.104034]&nbsp; [&lt;ffffffff815a27c7&gt;] tracesys+0xdd/0xe2<br>
[&nbsp; 112.104034] Code: eb 9b 45 01 f4 45 39 65 34 75 e5 4c 89 ef e8 02 f8 ff ff eb db 0f 1f 44 00 00 55 c7 05 20 17 54 00 01 00 00 00 48 89 e5 0f ae f8 &lt;c6&gt; 04 25 00 00 00 00 01 5d c3 0f 1f 44 00 00 55 31 c0 c7 05 7e
<br>
[&nbsp; 112.104034] RIP&nbsp; [&lt;ffffffff8134abb6&gt;] sysrq_handle_crash+0x16/0x20<br>
[&nbsp; 112.104034]&nbsp; RSP &lt;ffff880076495e80&gt;<br>
[&nbsp; 112.104034] CR2: 0000000000000000<br>
[&nbsp; 112.104034] ---[ end trace 4484e44d0167e21c ]---<br>
[&nbsp; 112.104034] Kernel panic - not syncing: Fatal exception<br>
PANIC: Fatal exception<br><br>
Entering kdb (current=0xffff880077275a90, pid 2352) on processor 1 due to Keyboard Entry<br><br>
[Note:] kdb command "go" is used to continue kernel execution. In above case <br>
it will not take you back to bash shell. :) <br><br>
Few questions for you;<br><br>
[Q:1] What exactly you are trying to achieve ?<br>
[Q:2] What is the exact issue ?<br><br>
Regards,<br>
BKS<br><br>
[[1]] <a href="http://people.redhat.com/anderson/crash_whitepaper/#INVOCATION" target="_blank">
http://people.redhat.com/anderson/crash_whitepaper/#INVOCATION</a><br>
[[2]] <a href="https://www.kernel.org/pub/linux/kernel/people/jwessel/kdb/" target="_blank">
https://www.kernel.org/pub/linux/kernel/people/jwessel/kdb/</a><br><br>
</div>
</div>
</div>
</div>
</div>
</div>
John Blackwood | 7 Jan 23:09 2016

[BUG] ps -t pid

Hi Dave,

I just wanted to report a minor issue.

The -t option on the 'ps' command will return invalid values for newer
kernels.

I believe that this has to do with newer kernels around the 3.17
timeframe having the 'start_time' field in the task_struct structure
changed from being a 'struct timespec' to being a 'u64' value.

I'm using a 4.1 based kernel. (The 3.16 based kernel that I also tried
it on does not exhibit this issue.)

For example:

crash> ps -t 1
PID: 1      TASK: ffff88046d688000  CPU: 8   COMMAND: "systemd"
     RUN TIME: 213503982286 days, 08:28:04
   START TIME: 126000000
        UTIME: 486536482
        STIME: 8484707060

I'm afraid that I do not possess the skill to suggest a fix,
but I thought that I would mention it.

Thanks for reading this.

Azriel Samson | 6 Jan 01:28 2016

Crash tool support for 3level-64k and 4level-4K page tables on ARM64

Hi David,

I recently tested makedumpfile on ARM64 with 3level-4K, 3level-64K and 
4level-4K page tables.

I tried to analyze the dumpfile with the crash tool.
I noticed that with 3level-64K and 4level-4K I got the following error
when I tried to run "kmem -f" :

kmem: invalid kernel virtual address: ffff************  type: "first
list entry"

I did not see the above error with 3level-4K. Also, on all three
combinations, other commands (bt,dmesg etc) ran fine.

Are there any plans to add support to the crash tool for these 
additional kernel configurations?

--

-- 
Thanks,
Azriel Samson
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

Takao Indoh | 5 Jan 09:31 2016

Extensions: Dump log buffer of Intel Processor Trace

Hi Dave,

The attached files are extension module to dump log buffer of Intel
Processor Trace from vmcore. Please consider placing this in the
extensions page.

[Overview of PT]
PT(Processor Trace) is a new feature of Intel CPU "Broadwell", it
captures information about program execution flow.[1]

Once Intel PT is enabled, the events which change program flow, like
branch instructions, exceptions, interruptions, traps and so on are
logged in the memory. This is very useful for debugging because we can
know the detailed behavior of software.

[About extension]
This extension retrieves log buff of PT from vmcore and saves it as a
file. 'ptdump' command can be used once this extension is loaded.

crash> extend extensions/ptdump.so
./extensions/ptdump.so: shared object loaded
crash> ptdump output_dir
[0] buffer dump: dump.0
[0] packet decode: decode.0
[1] buffer dump: dump.1
[1] packet decode: decode.1
(snipped)

In this case, output_dir directory is created, and then dump.N and
decode.N files are created in the directory for each cpus(N is cpu
number).

dump.N:   raw data of PT
decode.N: result of PT packet decoder

dump.N is binary data and it is not human readable. decode.N is
generated by fastdecode[2], which is PT packet dumper created by Andi
Kleen. It's useful for checking what kinds of packets are included in
dump.N. I'll update extension using PT library(libipt[3]) to generate
more useful file for investigation.

[Build extension]
To build the module from the top-level crash-<version> directory, enter:

$ tar xvf ptdump-1.0.0.tar.gz
$ mv ptdump-1.0.0/* extensions
$ make extensions

[1] https://software.intel.com/en-us/blogs/2013/09/18/processor-tracing
[2] https://github.com/andikleen/simple-pt
[3] https://github.com/01org/processor-trace

Thanks,
Takao Indoh
Attachment (ptdump-1.0.0.tar.gz): application/gzip, 9 KiB
Hi Dave,

The attached files are extension module to dump log buffer of Intel
Processor Trace from vmcore. Please consider placing this in the
extensions page.

[Overview of PT]
PT(Processor Trace) is a new feature of Intel CPU "Broadwell", it
captures information about program execution flow.[1]

Once Intel PT is enabled, the events which change program flow, like
branch instructions, exceptions, interruptions, traps and so on are
logged in the memory. This is very useful for debugging because we can
know the detailed behavior of software.

[About extension]
This extension retrieves log buff of PT from vmcore and saves it as a
file. 'ptdump' command can be used once this extension is loaded.

crash> extend extensions/ptdump.so
./extensions/ptdump.so: shared object loaded
crash> ptdump output_dir
[0] buffer dump: dump.0
[0] packet decode: decode.0
[1] buffer dump: dump.1
[1] packet decode: decode.1
(snipped)

In this case, output_dir directory is created, and then dump.N and
decode.N files are created in the directory for each cpus(N is cpu
number).

dump.N:   raw data of PT
decode.N: result of PT packet decoder

dump.N is binary data and it is not human readable. decode.N is
generated by fastdecode[2], which is PT packet dumper created by Andi
Kleen. It's useful for checking what kinds of packets are included in
dump.N. I'll update extension using PT library(libipt[3]) to generate
more useful file for investigation.

[Build extension]
To build the module from the top-level crash-<version> directory, enter:

$ tar xvf ptdump-1.0.0.tar.gz
$ mv ptdump-1.0.0/* extensions
$ make extensions

[1] https://software.intel.com/en-us/blogs/2013/09/18/processor-tracing
[2] https://github.com/andikleen/simple-pt
[3] https://github.com/01org/processor-trace

Thanks,
Takao Indoh
Nikolay Borisov | 4 Jan 12:59 2016

[BUG} gdb disassembly-flavor affecting display of call stack.

Hello,

I've observed the following rather peculiar behavior of crash 7.1.3 (gdb
7.6).

crash> set ffff88000376d280
    PID: 9615
COMMAND: "jbd2/dm-32-8"
   TASK: ffff88000376d280  [THREAD_INFO: ffff880002bdc000]
    CPU: 2
  STATE: TASK_UNINTERRUPTIBLE

crash> gdb set disassembly-flavor intel
crash> bt
PID: 9615   TASK: ffff88000376d280  CPU: 2   COMMAND: "jbd2/dm-32-8"
 #0 [ffff880002bdf9a8] __schedule at ffffffff81618404
 #1 [ffff880002bdf9e0] __clone_and_map_data_bio at ffffffff8150af42
 #2 [ffff880002bdfa40] schedule at ffffffff81618a8e
crash> gdb set disassembly-flavor att
crash> bt
PID: 9615   TASK: ffff88000376d280  CPU: 2   COMMAND: "jbd2/dm-32-8"
 #0 [ffff880002bdf9a8] __schedule at ffffffff81618404
 #1 [ffff880002bdfa40] schedule at ffffffff81618a8e
 #2 [ffff880002bdfa60] schedule_timeout at ffffffff8161b3e6
 #3 [ffff880002bdfb20] io_schedule_timeout at ffffffff81618054
 #4 [ffff880002bdfb50] bit_wait_io at ffffffff81619196
 #5 [ffff880002bdfb60] __wait_on_bit at ffffffff81618f7d
 #6 [ffff880002bdfbb0] out_of_line_wait_on_bit at ffffffff816190d8
 #7 [ffff880002bdfc20] __wait_on_buffer at ffffffff811d13d8
 #8 [ffff880002bdfc30] jbd2_journal_commit_transaction at ffffffff81270a45
 #9 [ffff880002bdfe30] kjournald2 at ffffffff81275073
#10 [ffff880002bdfec0] kthread at ffffffff810738fc
#11 [ffff880002bdff50] ret_from_fork at ffffffff8161c75f

How come setting the disassembly flavor (which should be just a
presentation aid) affects the displaying of the callstack? It took me a
while to correlate this behavior. It's also strange that this doesn't
happen on all processes on a vmcore file but only on some, so far I
haven't been able to find any clues as to which processes this applies to.

Regards,
Nikolay

Liu, Jianbo (James | 30 Dec 12:04 2015

if it's normal to get into kdb shell when run crash

Hi Experts:

Sorry for disturbing you again.

When I run crash to debug vmcore, if kernel enable kgdb, it will get into kdb shell directly not crash shell, althrough I can get into crash via execute two go command in kdb shell, not sure if it's normal, do you have some comments on it?


When I disnable kgdb in kernel, there will not be this kind of issue, if there is some compatibility problem between kgdb and crash tool?

Thanks for your time and happen new year!!

/****************************************/
root <at> localhost:~/coredump>sh testcoredump.sh; sh startcoredump.sh 
segment[0].mem:0x2000000 memsz:9183232
segment[1].mem:0x28c2000 memsz:65536
segment[2].mem:0x28d2000 memsz:4096
segment[3].mem:0x28d3000 memsz:28672
segment[4].mem:0x2ff5000 memsz:45056
SysRq : Trigger a crash

Entering kdb (current=0xdb17f900, pid 822) on processor 1 Oops: (null)
due to oops  <at>  0xc0348f64
NIP: c0348f64 LR: c034974c CTR: c0348f50
REGS: db18ddc0 TRAP: 0300   Not tainted  (2.6.34.15-grsec-WR4.3.0.0_cgl)
MSR: 00021202 <ME,CE,DE>  CR: 20242444  XER: 00000000
DEAR: 00000000, ESR: 00800000
TASK = db17f900[822] 'sh' THREAD: db18c000 CPU: 1
GPR00: 00000001 db18de70 db17f900 00000063 00000000 ffffffff c035e930 00000000 
GPR08: 00008000 00000000 00000054 118c6000 20242444 100b84b8 100b0828 100b0904 
GPR16: 00000000 00000000 00000000 1006d2d0 00000000 100cc220 1006b530 00000000 
GPR24: 00000001 c0780d24 00029202 c0780e08 c0770000 00000000 c08578a4 00000063 
NIP [c0348f64] sysrq_handle_crash+0x14/0x20
LR [c034974c] __handle_sysrq+0xcc/0x1d0
Call Trace:
[db18de70] [c0349734] __handle_sysrq+0xb4/0x1d0 (unreliable)
[db18dea0] [c03498ac] write_sysrq_trigger+0x5c/0x70
[db18deb0] [c01662f0] proc_reg_write+0x80/0xc0
[db18dee0] [c010ec50] vfs_write+0xc0/0x170
[db18df00] [c010ee80] sys_write+0x50/0x110
[db18df40] [c0011d58] ret_from_syscall+0x0/0x4
--- Exception: c01 at 0xff16ba4
    LR = 0xfebad5c
Instruction dump:
[1]more> 
39600003 7d605f9e 556b103a 7c005b78 98090003 4e800020 60000000 38000001 
3d20c07a 90092170 7c0004ac 39200000 <98090000> 4e800020 60000000 3803ffd0 

[1]kdb>    

[1]kdb> go 
Catastrophic error detected
kdb_continue_catastrophic=0, type go a second time if you really want to continue
[1]kdb> go
Catastrophic error detected
kdb_continue_catastrophic=0, attempting to continue
Oops: Kernel access of bad area, sig: 11 [#1]
PREEMPT SMP NR_CPUS=4 LTT NESTING LEVEL : 0 
P2041 RDB
last sysfs file: /sys/devices/system/cpu/cpu3/crash_notes
Modules linked in:
NIP: c0348f64 LR: c034974c CTR: c0348f50
REGS: db18ddc0 TRAP: 0300   Not tainted  (2.6.34.15-grsec-WR4.3.0.0_cgl)
MSR: 00021202 <ME,CE,DE>  CR: 20242444  XER: 00000000
DEAR: 00000000, ESR: 00800000
TASK = db17f900[822] 'sh' THREAD: db18c000 CPU: 1
GPR00: 00000001 db18de70 db17f900 00000063 00000000 ffffffff c035e930 00000000 
GPR08: 00008000 00000000 00000054 118c6000 20242444 100b84b8 100b0828 100b0904 
GPR16: 00000000 00000000 00000000 1006d2d0 00000000 100cc220 1006b530 00000000 
GPR24: 00000001 c0780d24 00029202 c0780e08 c0770000 00000000 c08578a4 00000063 
NIP [c0348f64] sysrq_handle_crash+0x14/0x20
LR [c034974c] __handle_sysrq+0xcc/0x1d0
Call Trace:
[db18de70] [c0349734] __handle_sysrq+0xb4/0x1d0 (unreliable)
[db18dea0] [c03498ac] write_sysrq_trigger+0x5c/0x70
[db18deb0] [c01662f0] proc_reg_write+0x80/0xc0
[db18dee0] [c010ec50] vfs_write+0xc0/0x170
[db18df00] [c010ee80] sys_write+0x50/0x110
[db18df40] [c0011d58] ret_from_syscall+0x0/0x4
--- Exception: c01 at 0xff16ba4
    LR = 0xfebad5c
Instruction dump:
39600003 7d605f9e 556b103a 7c005b78 98090003 4e800020 60000000 38000001 
3d20c07a 90092170 7c0004ac 39200000 <98090000> 4e800020 60000000 3803ffd0 
Sending IPI to other cpus...
Bye!
Using P2041 RDB machine description

......
/**********************/


Best Regards,
James

Liu Jianbo | WIND RIVER | Senior Engineer - Technical Support
Tel 86 28 65318098 | Cell 86 13558641588 | Fax 86 28 65319983 

Manage your support account:
https://support.windriver.com

Ask a Technical Question
https://ask.windriver.com

Submit a Service Request
https://windriver.force.com/support

<div>
<div>Hi Experts:
<div><br></div>
<div>Sorry for disturbing you again.</div>
<div><br></div>
<div>When I run crash to debug vmcore, if kernel enable kgdb, it will get into kdb shell directly not crash shell, althrough I can get into crash via execute two go command in kdb shell, not sure if it's normal, do you have some comments on it?<br><div><br></div>
<div><br></div>
<div>When I disnable kgdb in kernel, there will not be this kind of issue, if there is some compatibility problem between kgdb and crash tool?</div>
<div><br></div>
<div>Thanks for your time and happen new year!!</div>
<div><br></div>
<div>/****************************************/</div>
<div>
<span>root <at> localhost:~/coredump&gt;sh&nbsp;testcoredump.sh;&nbsp;sh&nbsp;startcoredump.sh&nbsp;</span><br><span>segment[0].mem:0x2000000&nbsp;memsz:9183232</span><br><span>segment[1].mem:0x28c2000&nbsp;memsz:65536</span><br><span>segment[2].mem:0x28d2000&nbsp;memsz:4096</span><br><span>segment[3].mem:0x28d3000&nbsp;memsz:28672</span><br><span>segment[4].mem:0x2ff5000&nbsp;memsz:45056</span><br><span>SysRq&nbsp;:&nbsp;Trigger&nbsp;a&nbsp;crash</span><br><br><span>Entering&nbsp;kdb&nbsp;(current=0xdb17f900,&nbsp;pid&nbsp;822)&nbsp;on&nbsp;processor&nbsp;1&nbsp;Oops:&nbsp;(null)</span><br><span>due&nbsp;to&nbsp;oops&nbsp; <at> &nbsp;0xc0348f64</span><br><span>NIP:&nbsp;c0348f64&nbsp;LR:&nbsp;c034974c&nbsp;CTR:&nbsp;c0348f50</span><br><span>REGS:&nbsp;db18ddc0&nbsp;TRAP:&nbsp;0300&nbsp;&nbsp;&nbsp;Not&nbsp;tainted&nbsp;&nbsp;(2.6.34.15-grsec-WR4.3.0.0_cgl)</span><br><span>MSR:&nbsp;00021202&nbsp;&lt;ME,CE,DE&gt;&nbsp;&nbsp;CR:&nbsp;20242444&nbsp;&nbsp;XER:&nbsp;00000000</span><br><span>DEAR:&nbsp;00000000,&nbsp;ESR:&nbsp;00800000</span><br><span>TASK&nbsp;=&nbsp;db17f900[822]&nbsp;'sh'&nbsp;THREAD:&nbsp;db18c000&nbsp;CPU:&nbsp;1</span><br><span>GPR00:&nbsp;00000001&nbsp;db18de70&nbsp;db17f900&nbsp;00000063&nbsp;00000000&nbsp;ffffffff&nbsp;c035e930&nbsp;00000000&nbsp;</span><br><span>GPR08:&nbsp;00008000&nbsp;00000000&nbsp;00000054&nbsp;118c6000&nbsp;20242444&nbsp;100b84b8&nbsp;100b0828&nbsp;100b0904&nbsp;</span><br><span>GPR16:&nbsp;00000000&nbsp;00000000&nbsp;00000000&nbsp;1006d2d0&nbsp;00000000&nbsp;100cc220&nbsp;1006b530&nbsp;00000000&nbsp;</span><br><span>GPR24:&nbsp;00000001&nbsp;c0780d24&nbsp;00029202&nbsp;c0780e08&nbsp;c0770000&nbsp;00000000&nbsp;c08578a4&nbsp;00000063&nbsp;</span><br><span>NIP&nbsp;[c0348f64]&nbsp;sysrq_handle_crash+0x14/0x20</span><br><span>LR&nbsp;[c034974c]&nbsp;__handle_sysrq+0xcc/0x1d0</span><br><span>Call&nbsp;Trace:</span><br><span>[db18de70]&nbsp;[c0349734]&nbsp;__handle_sysrq+0xb4/0x1d0&nbsp;(unreliable)</span><br><span>[db18dea0]&nbsp;[c03498ac]&nbsp;write_sysrq_trigger+0x5c/0x70</span><br><span>[db18deb0]&nbsp;[c01662f0]&nbsp;proc_reg_write+0x80/0xc0</span><br><span>[db18dee0]&nbsp;[c010ec50]&nbsp;vfs_write+0xc0/0x170</span><br><span>[db18df00]&nbsp;[c010ee80]&nbsp;sys_write+0x50/0x110</span><br><span>[db18df40]&nbsp;[c0011d58]&nbsp;ret_from_syscall+0x0/0x4</span><br><span>---&nbsp;Exception:&nbsp;c01&nbsp;at&nbsp;0xff16ba4</span><br><span>&nbsp;&nbsp;&nbsp;&nbsp;LR&nbsp;=&nbsp;0xfebad5c</span><br><span>Instruction&nbsp;dump:</span><br><span>[1]more&gt;&nbsp;</span><br><span>39600003&nbsp;7d605f9e&nbsp;556b103a&nbsp;7c005b78&nbsp;98090003&nbsp;4e800020&nbsp;60000000&nbsp;38000001&nbsp;</span><br><span>3d20c07a&nbsp;90092170&nbsp;7c0004ac&nbsp;39200000&nbsp;&lt;98090000&gt;&nbsp;4e800020&nbsp;60000000&nbsp;3803ffd0&nbsp;</span><br><br><span>[1]kdb&gt;&nbsp;&nbsp;&nbsp;&nbsp;</span><br><br><span>[1]kdb&gt;</span>&nbsp;go&nbsp;<br><span>Catastrophic&nbsp;error&nbsp;detected</span><br><span>kdb_continue_catastrophic=0,&nbsp;type&nbsp;go&nbsp;a&nbsp;second&nbsp;time&nbsp;if&nbsp;you&nbsp;really&nbsp;want&nbsp;to&nbsp;continue</span><br><span>[1]kdb&gt;&nbsp;</span>go<br><span>Catastrophic&nbsp;error&nbsp;detected</span><br><span>kdb_continue_catastrophic=0,&nbsp;attempting&nbsp;to&nbsp;continue</span><br><span>Oops:&nbsp;Kernel&nbsp;access&nbsp;of&nbsp;bad&nbsp;area,&nbsp;sig:&nbsp;11&nbsp;[#1]</span><br><span>PREEMPT&nbsp;SMP&nbsp;NR_CPUS=4&nbsp;LTT&nbsp;NESTING&nbsp;LEVEL&nbsp;:&nbsp;0&nbsp;</span><br><span>P2041&nbsp;RDB</span><br><span>last&nbsp;sysfs&nbsp;file:&nbsp;/sys/devices/system/cpu/cpu3/crash_notes</span><br><span>Modules&nbsp;linked&nbsp;in:</span><br><span>NIP:&nbsp;c0348f64&nbsp;LR:&nbsp;c034974c&nbsp;CTR:&nbsp;c0348f50</span><br><span>REGS:&nbsp;db18ddc0&nbsp;TRAP:&nbsp;0300&nbsp;&nbsp;&nbsp;Not&nbsp;tainted&nbsp;&nbsp;(2.6.34.15-grsec-WR4.3.0.0_cgl)</span><br><span>MSR:&nbsp;00021202&nbsp;&lt;ME,CE,DE&gt;&nbsp;&nbsp;CR:&nbsp;20242444&nbsp;&nbsp;XER:&nbsp;00000000</span><br><span>DEAR:&nbsp;00000000,&nbsp;ESR:&nbsp;00800000</span><br><span>TASK&nbsp;=&nbsp;db17f900[822]&nbsp;'sh'&nbsp;THREAD:&nbsp;db18c000&nbsp;CPU:&nbsp;1</span><br><span>GPR00:&nbsp;00000001&nbsp;db18de70&nbsp;db17f900&nbsp;00000063&nbsp;00000000&nbsp;ffffffff&nbsp;c035e930&nbsp;00000000&nbsp;</span><br><span>GPR08:&nbsp;00008000&nbsp;00000000&nbsp;00000054&nbsp;118c6000&nbsp;20242444&nbsp;100b84b8&nbsp;100b0828&nbsp;100b0904&nbsp;</span><br><span>GPR16:&nbsp;00000000&nbsp;00000000&nbsp;00000000&nbsp;1006d2d0&nbsp;00000000&nbsp;100cc220&nbsp;1006b530&nbsp;00000000&nbsp;</span><br><span>GPR24:&nbsp;00000001&nbsp;c0780d24&nbsp;00029202&nbsp;c0780e08&nbsp;c0770000&nbsp;00000000&nbsp;c08578a4&nbsp;00000063&nbsp;</span><br><span>NIP&nbsp;[c0348f64]&nbsp;sysrq_handle_crash+0x14/0x20</span><br><span>LR&nbsp;[c034974c]&nbsp;__handle_sysrq+0xcc/0x1d0</span><br><span>Call&nbsp;Trace:</span><br><span>[db18de70]&nbsp;[c0349734]&nbsp;__handle_sysrq+0xb4/0x1d0&nbsp;(unreliable)</span><br><span>[db18dea0]&nbsp;[c03498ac]&nbsp;write_sysrq_trigger+0x5c/0x70</span><br><span>[db18deb0]&nbsp;[c01662f0]&nbsp;proc_reg_write+0x80/0xc0</span><br><span>[db18dee0]&nbsp;[c010ec50]&nbsp;vfs_write+0xc0/0x170</span><br><span>[db18df00]&nbsp;[c010ee80]&nbsp;sys_write+0x50/0x110</span><br><span>[db18df40]&nbsp;[c0011d58]&nbsp;ret_from_syscall+0x0/0x4</span><br><span>---&nbsp;Exception:&nbsp;c01&nbsp;at&nbsp;0xff16ba4</span><br><span>&nbsp;&nbsp;&nbsp;&nbsp;LR&nbsp;=&nbsp;0xfebad5c</span><br><span>Instruction&nbsp;dump:</span><br><span>39600003&nbsp;7d605f9e&nbsp;556b103a&nbsp;7c005b78&nbsp;98090003&nbsp;4e800020&nbsp;60000000&nbsp;38000001&nbsp;</span><br><span>3d20c07a&nbsp;90092170&nbsp;7c0004ac&nbsp;39200000&nbsp;&lt;98090000&gt;&nbsp;4e800020&nbsp;60000000&nbsp;3803ffd0&nbsp;</span><br><span>Sending&nbsp;IPI&nbsp;to&nbsp;other&nbsp;cpus...</span><br><span>Bye!</span><br><span>Using&nbsp;P2041&nbsp;RDB&nbsp;machine&nbsp;description</span>
</div>
<div><span><br></span></div>
<div><span>......</span></div>
<div>
<span>/**********************/<br></span>
<div>
<br><br>Best Regards,<br>
James<br><br>
Liu Jianbo | WIND RIVER | Senior Engineer - Technical Support<br>
Tel 86 28 65318098 | Cell 86 13558641588 | Fax 86 28 65319983&nbsp; <br><br>Manage your support account:<br>https://support.windriver.com <br><br>
Ask a Technical Question<br>https://ask.windriver.com <br><br>
Submit a Service Request<br>https://windriver.force.com/support<br><br>
</div>
</div>
</div>
<div class="vimiumReset vimiumHUD">
</div>
<div class="vimiumReset vimiumHUD">
</div>
</div>
</div>
Nakajima Akira | 22 Dec 08:36 2015
Picon

[PATCH] x86_64: Fix that Particular kvaddr is converted to wrong paddr (RHEL6 x86_64)

I didn't check XEN HYPER MODE, I don't have XEN.
If we need similar statement "if (kvaddr < MODULES_END)"
 please add inside in "if (XEN_HYPER_MODE())" (1859 <at> x86_64_kvtop)

>From ed300b74998e0923313e4fd14b9a41e305942b44 Mon Sep 17 00:00:00 2001
From: Nakajima Akira <nakajima.akira <at> nttcom.co.jp>
Date: Tue, 22 Dec 2015 15:46:42 +0900
Subject: [PATCH] Fix that particular kvaddr is converted to wrong paddr

BUG INFO
Particular kvaddr is converted to wrong paddr.
You can see this bug on RHEL6_x86_64. (at present only RHEL6)
 (I checked RHEL5, RHEL7, Fedora21, Fedora23)

from /proc/kallsyms
ffffffffff6008c0 D __jiffies

/////////// wrong ///////////
crash> vtop ffffffffff6008c0
VIRTUAL           PHYSICAL        
ffffffffff6008c0  7f6008c0        

      PAGE        PHYSICAL      MAPPING       INDEX CNT FLAGS
ffffea00000623b8   1c11000                0        0  1 20000000000400 reserved

crash> rd ffffffffff6008c0
ffffffffff6008c0:  0000000000000000                    ........

/////////// correct ///////////
crash> vtop ffffffffff6008c0
VIRTUAL           PHYSICAL        
ffffffffff6008c0  1c118c0         

      PAGE        PHYSICAL      MAPPING       INDEX CNT FLAGS
ffffea00000623b8   1c11000                0        0  1 20000000000400 reserved

crash> rd ffffffffff6008c0
ffffffffff6008c0:  00000000ffffe43a                    :.......

Reported-by: Nakajima Akira <nakajima.akira <at> nttcom.co.jp>
Signed-off-by: Nakajima Akira <nakajima.akira <at> nttcom.co.jp>

---
 x86_64.c |   28 +++++++++++++++-------------
 1 files changed, 15 insertions(+), 13 deletions(-)

diff --git a/x86_64.c b/x86_64.c
index ff6fdd5..dab4d43 100644
--- a/x86_64.c
+++ b/x86_64.c
 <at>  <at>  -1872,19 +1872,21  <at>  <at>  x86_64_kvtop(struct task_context *tc, ulong kvaddr, physaddr_t *paddr, int verbo
                		fprintf(fp, "PAGE DIRECTORY: %lx\n", *pml4);
 		}
 	} else {
-        	if (!vt->vmalloc_start) {
-                	*paddr = x86_64_VTOP(kvaddr);
-                	return TRUE;
-        	}
-
-        	if (!IS_VMALLOC_ADDR(kvaddr)) {
-                	*paddr = x86_64_VTOP(kvaddr);
-                	if (!verbose)
-                        	return TRUE;
-        	}
-
-		if (XEN() && (kt->xen_flags & WRITABLE_PAGE_TABLES))
-			return (x86_64_kvtop_xen_wpt(tc, kvaddr, paddr, verbose));
+		if (kvaddr < MODULES_END) {
+	        	if (!vt->vmalloc_start) {
+	                	*paddr = x86_64_VTOP(kvaddr);
+	                	return TRUE;
+	        	}
+	
+	        	if (!IS_VMALLOC_ADDR(kvaddr)) {
+	                	*paddr = x86_64_VTOP(kvaddr);
+	                	if (!verbose)
+	                        	return TRUE;
+	        	}
+	
+			if (XEN() && (kt->xen_flags & WRITABLE_PAGE_TABLES))
+				return (x86_64_kvtop_xen_wpt(tc, kvaddr, paddr, verbose));
+		}

  		/*	
 		 *  pgd = pgd_offset_k(addr);
-- 
1.7.1

From ed300b74998e0923313e4fd14b9a41e305942b44 Mon Sep 17 00:00:00 2001
From: Nakajima Akira <nakajima.akira <at> nttcom.co.jp>
Date: Tue, 22 Dec 2015 15:46:42 +0900
Subject: [PATCH] Fix that particular kvaddr is converted to wrong paddr

BUG INFO
Particular kvaddr is converted to wrong paddr.
You can see this bug on RHEL6_x86_64. (at present only RHEL6)
 (I checked RHEL5, RHEL7, Fedora21, Fedora23)

from /proc/kallsyms
ffffffffff6008c0 D __jiffies

/////////// wrong ///////////
crash> vtop ffffffffff6008c0
VIRTUAL           PHYSICAL        
ffffffffff6008c0  7f6008c0        

      PAGE        PHYSICAL      MAPPING       INDEX CNT FLAGS
ffffea00000623b8   1c11000                0        0  1 20000000000400 reserved

crash> rd ffffffffff6008c0
ffffffffff6008c0:  0000000000000000                    ........

/////////// correct ///////////
crash> vtop ffffffffff6008c0
VIRTUAL           PHYSICAL        
ffffffffff6008c0  1c118c0         

      PAGE        PHYSICAL      MAPPING       INDEX CNT FLAGS
ffffea00000623b8   1c11000                0        0  1 20000000000400 reserved

crash> rd ffffffffff6008c0
ffffffffff6008c0:  00000000ffffe43a                    :.......

Reported-by: Nakajima Akira <nakajima.akira <at> nttcom.co.jp>
Signed-off-by: Nakajima Akira <nakajima.akira <at> nttcom.co.jp>

---
 x86_64.c |   28 +++++++++++++++-------------
 1 files changed, 15 insertions(+), 13 deletions(-)

diff --git a/x86_64.c b/x86_64.c
index ff6fdd5..dab4d43 100644
--- a/x86_64.c
+++ b/x86_64.c
 <at>  <at>  -1872,19 +1872,21  <at>  <at>  x86_64_kvtop(struct task_context *tc, ulong kvaddr, physaddr_t *paddr, int verbo
                		fprintf(fp, "PAGE DIRECTORY: %lx¥n", *pml4);
 		}
 	} else {
-        	if (!vt->vmalloc_start) {
-                	*paddr = x86_64_VTOP(kvaddr);
-                	return TRUE;
-        	}
-
-        	if (!IS_VMALLOC_ADDR(kvaddr)) {
-                	*paddr = x86_64_VTOP(kvaddr);
-                	if (!verbose)
-                        	return TRUE;
-        	}
-
-		if (XEN() && (kt->xen_flags & WRITABLE_PAGE_TABLES))
-			return (x86_64_kvtop_xen_wpt(tc, kvaddr, paddr, verbose));
+		if (kvaddr < MODULES_END) {
+	        	if (!vt->vmalloc_start) {
+	                	*paddr = x86_64_VTOP(kvaddr);
+	                	return TRUE;
+	        	}
+	
+	        	if (!IS_VMALLOC_ADDR(kvaddr)) {
+	                	*paddr = x86_64_VTOP(kvaddr);
+	                	if (!verbose)
+	                        	return TRUE;
+	        	}
+	
+			if (XEN() && (kt->xen_flags & WRITABLE_PAGE_TABLES))
+				return (x86_64_kvtop_xen_wpt(tc, kvaddr, paddr, verbose));
+		}

  		/*	
 		 *  pgd = pgd_offset_k(addr);
-- 
1.7.1

From ed300b74998e0923313e4fd14b9a41e305942b44 Mon Sep 17 00:00:00 2001
From: Nakajima Akira <nakajima.akira <at> nttcom.co.jp>
Date: Tue, 22 Dec 2015 15:46:42 +0900
Subject: [PATCH] Fix that particular kvaddr is converted to wrong paddr

BUG INFO
Particular kvaddr is converted to wrong paddr.
You can see this bug on RHEL6_x86_64. (at present only RHEL6)
 (I checked RHEL5, RHEL7, Fedora21, Fedora23)

from /proc/kallsyms
ffffffffff6008c0 D __jiffies

/////////// wrong ///////////
crash> vtop ffffffffff6008c0
VIRTUAL           PHYSICAL        
ffffffffff6008c0  7f6008c0        

      PAGE        PHYSICAL      MAPPING       INDEX CNT FLAGS
ffffea00000623b8   1c11000                0        0  1 20000000000400 reserved

crash> rd ffffffffff6008c0
ffffffffff6008c0:  0000000000000000                    ........

/////////// correct ///////////
crash> vtop ffffffffff6008c0
VIRTUAL           PHYSICAL        
ffffffffff6008c0  1c118c0         

      PAGE        PHYSICAL      MAPPING       INDEX CNT FLAGS
ffffea00000623b8   1c11000                0        0  1 20000000000400 reserved

crash> rd ffffffffff6008c0
ffffffffff6008c0:  00000000ffffe43a                    :.......

Reported-by: Nakajima Akira <nakajima.akira <at> nttcom.co.jp>
Signed-off-by: Nakajima Akira <nakajima.akira <at> nttcom.co.jp>

---
 x86_64.c |   28 +++++++++++++++-------------
 1 files changed, 15 insertions(+), 13 deletions(-)

diff --git a/x86_64.c b/x86_64.c
index ff6fdd5..dab4d43 100644
--- a/x86_64.c
+++ b/x86_64.c
 <at>  <at>  -1872,19 +1872,21  <at>  <at>  x86_64_kvtop(struct task_context *tc, ulong kvaddr, physaddr_t *paddr, int verbo
                		fprintf(fp, "PAGE DIRECTORY: %lx¥n", *pml4);
 		}
 	} else {
-        	if (!vt->vmalloc_start) {
-                	*paddr = x86_64_VTOP(kvaddr);
-                	return TRUE;
-        	}
-
-        	if (!IS_VMALLOC_ADDR(kvaddr)) {
-                	*paddr = x86_64_VTOP(kvaddr);
-                	if (!verbose)
-                        	return TRUE;
-        	}
-
-		if (XEN() && (kt->xen_flags & WRITABLE_PAGE_TABLES))
-			return (x86_64_kvtop_xen_wpt(tc, kvaddr, paddr, verbose));
+		if (kvaddr < MODULES_END) {
+	        	if (!vt->vmalloc_start) {
+	                	*paddr = x86_64_VTOP(kvaddr);
+	                	return TRUE;
+	        	}
+	
+	        	if (!IS_VMALLOC_ADDR(kvaddr)) {
+	                	*paddr = x86_64_VTOP(kvaddr);
+	                	if (!verbose)
+	                        	return TRUE;
+	        	}
+	
+			if (XEN() && (kt->xen_flags & WRITABLE_PAGE_TABLES))
+				return (x86_64_kvtop_xen_wpt(tc, kvaddr, paddr, verbose));
+		}

  		/*	
 		 *  pgd = pgd_offset_k(addr);
--

-- 
1.7.1


Gmane