[PATCH] netdump, diskdump: address the issue caused by no NT_PRSTATUS notes
by HATAYAMA Daisuke
Hello Dave,
I have three patches today.
The 1st and 2nd patches address the issue that vmcore has no NT_PRSTATUS
notes.
- The 1st patch makes crash consider the case where the number of
NT_PRSTATUS notes
is 0. Without this patch, crash leads to NULL pointer dereference when
using bt
command for active tasks.
- The 2nd patch makes crash pass boot-time sanity check to nr_cpus
memebr of diskdump
header on x86 and x86_64 if it is 0. On both architectures, we can get cpu
information from memory part. In fact, the value of nr_cpus member is
not used
except for the sanity check.
I saw the situation where vmcore with no NT_PRSTATUS notes is generated,
on Xen HVM,
where the version of kexec not supporting Xen HVM. It determins if
system is Xen Dom0
wrongly and uses interface for Dom0. As a result, vmcore doesn't contain any
NT_PRSTATUS note.
When converting this vmcore using makedumpfile, nr_cpus member of
diskdump header of
the resulted vmcore is 0. So the 2nd patch is needed.
The 3rd patch is differnet from the above two, fixing potencial bug in
panic task
detection code, which I found during investigation for the above two
patches.
But sorry, I didn't test this yet.
I made every patch on top of crash version 6.1.0.
Thanks.
HATAYAMA, Daisuke
11 years, 8 months
[PATCH] fix output bug of trace.c
by qiaonuohan
Hello Dave,
The patch is used to fix the output of trace.c.
When I was using trace command to display function tracer's data. The
following information is displayed.
<cut>
crash> trace show
version = 6
cpus=2
<idle>-0 [001] 20067.827943: function:
0xffffffff81089fa40xffffffff8109e423
<idle>-0 [001] 20067.827944: function:
0xffffffff811115a40xffffffff8109e4cd
<idle>-0 [001] 20067.827944: function:
0xffffffff81097a140xffffffff8109e44f
<idle>-0 [001] 20067.827945: function:
0xffffffff81089fa40xffffffff8109e479
<idle>-0 [001] 20067.827945: function:
0xffffffff81089fa40xffffffff8109e482
...
<cut>
In tmp_fprintf, function snprintf is used to output data. However, if
the following situation happends, the last character is omitted which
causes the above bug.
<cut>
snprintf(buf, 10, "123456789\n"); /* '\n' is omitted */
<cut>
With the patch, the output is like below.
<cut>
crash> trace show
version = 6
cpus=2
<idle>-0 [001] 20067.827943: function:
debug_lockdep_rcu_enabled <-- walk_tg_tree_from
<idle>-0 [001] 20067.827944: function:
rcu_is_cpu_idle <-- walk_tg_tree_from
<idle>-0 [001] 20067.827944: function: tg_nop
<-- walk_tg_tree_from
<idle>-0 [001] 20067.827945: function:
debug_lockdep_rcu_enabled <-- walk_tg_tree_from
<idle>-0 [001] 20067.827945: function:
debug_lockdep_rcu_enabled <-- walk_tg_tree_from
...
<cut>
--
--
Regards
Qiao Nuohan
11 years, 8 months
GCORE: add directly show backtrace function in crash
by Lei Wen
Hi Daisuke,
I create a new option "-tT" for gcore, so that it could display bt for user
space
directly inside crash itself, without needing to dump a separated core file
image,
and analyze it in a different gdb env.
The attached patch is directly based on below patch, and verify over ARM
platform.
http://osdir.com/ml/general/2012-10/msg32677.html
Before use the corresponding gcore command, we need set env in crash by:
crash>> gdb set solib-search-path [system lib path]
crash>> gdb file [user space program symbol file]
crash>> gcore -t [user space thread id]
Thanks,
Lei
11 years, 8 months
[PATCH] Print '\n' and '\t' in log command
by Michael Holzheu
Hi Dave,
Currently the log command does not print '\n' and '\t'. The reason
is that isprint() does not return true for those characters.
This patch adds the isspace() test in order to print these characters
properly.
Michael
---
kernel.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/kernel.c
+++ b/kernel.c
@@ -4164,7 +4164,7 @@ dump_log_entry(char *logptr, int msg_fla
}
for (i = 0, p = msg; i < text_len; i++, p++)
- fputc(isprint(*p) ? *p : '.', fp);
+ fputc(isprint(*p) || isspace(*p) ? *p : '.', fp);
if (dict_len & (msg_flags & SHOW_LOG_DICT)) {
fprintf(fp, "\n");
11 years, 8 months
[RFC] display function param and local value for backtrace
by Lei Wen
Hi Dave,
Current I am trying to make crash support display out function param and local value while backtracing.
The idea for this patch is to mimic core dump support in gdb, teaching the crash to supply the regset to the gdb, so that gdb could have full knowledge what is going on in the panic point.
A few progress has been made, the first two frames could display out correctly, but while it is going on to display out the third frame, it report fail as “Cannot access memory” to the stack address.
While I use the rd command to access this range, and could correct pc value there.
With further check, I find it failed at value_fetch_lazy at gdb code.
Do you have any idea why gdb side couldn’t read the stack content?
The generated log as:
crash> bt
PID: 886 TASK: c54991a0 CPU: 0 COMMAND: "sh"
#0 sysrq_handle_crash (key=99) at drivers/tty/sysrq.c:132
No locals.
#1 0xc02da6dc in __handle_sysrq (key=99, check_mask=false) at drivers/tty/sysrq.c:522
op_p = 0xc06dbeb8
orig_log_level = 7
i = -1066549576
flags = 1610612755
Cannot access memory at address 0xd29d5f34
bt: display local fail at c02da1c0
crash> rd 0xd29d5f34 1
d29d5f34: c02da7cc ..-.
crash> sym c02da7cc
c02da7cc (t) write_sysrq_trigger+40 /kernel/drivers/tty/sysrq.c: 873
Thanks,
Lei
11 years, 8 months
[PATCH] s390x: Add 2GB frame support for page table walker
by Michael Holzheu
Hi Dave,
On s390 the new zEC12 machines support 2GB frames. In order to walk page tables
correctly add support to the page table walker function so it detects
2GB frames.
Michael
Signed-off-by: Heiko Carstens <heiko.carstens(a)de.ibm.com>
Signed-off-by: Michael Holzheu <holzheu(a)linux.vnet.ibm.com>
---
s390x.c | 8 ++++++++
1 file changed, 8 insertions(+)
--- a/s390x.c
+++ b/s390x.c
@@ -643,6 +643,13 @@ int s390x_vtop(ulong table, ulong vaddr,
if (!entry)
return FALSE;
table = entry & ~0xfffULL;
+ /* Check if this a 2GB page */
+ if ((entry & 0x400ULL) && (level == 1)) {
+ /* Add the 2GB frame offset & return the final value. */
+ table &= ~0x7fffffffULL;
+ *phys_addr = table + (vaddr & 0x7fffffffULL);
+ return TRUE;
+ }
len = entry & 0x3ULL;
level--;
}
@@ -650,6 +657,7 @@ int s390x_vtop(ulong table, ulong vaddr,
/* Check if this is a large page. */
if (entry & 0x400ULL) {
/* Add the 1MB page offset and return the final value. */
+ table &= ~0xfffffULL;
*phys_addr = table + (vaddr & 0xfffffULL);
return TRUE;
}
11 years, 8 months
Re: [Crash-utility] Crash-utility Digest, Vol 85, Issue 16
by Rob Brown
remove
On Fri, Oct 19, 2012 at 12:00 PM, <crash-utility-request(a)redhat.com> wrote:
> Send Crash-utility mailing list submissions to
> crash-utility(a)redhat.com
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://www.redhat.com/mailman/listinfo/crash-utility
> or, via email, send a message with subject or body 'help' to
> crash-utility-request(a)redhat.com
>
> You can reach the person managing the list at
> crash-utility-owner(a)redhat.com
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Crash-utility digest..."
>
>
> Today's Topics:
>
> 1. Re: how to generate xen hypervisor core though kdump or other
> way? (Daniel Kiper)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Fri, 19 Oct 2012 00:36:40 -0700 (PDT)
> From: Daniel Kiper <daniel.kiper(a)oracle.com>
> To: <duanshuidao(a)hotmail.com>
> Cc: herbert.van.den.bergh(a)oracle.com, crash-utility(a)redhat.com
> Subject: Re: [Crash-utility] how to generate xen hypervisor core
> though kdump or other way?
> Message-ID: <fe710a9c-af6a-4856-a958-ffc6994d173c@default>
> Content-Type: text/plain; charset=UTF-8
>
> Hi,
>
> > how are you going , daniel?
>
> I am working on another crash issue
> which we discovered internally. I am
> going to work on your problem when
> I finish above mentioned task. Stay tuned.
>
> Daniel
>
>
>
> ------------------------------
>
> --
> Crash-utility mailing list
> Crash-utility(a)redhat.com
> https://www.redhat.com/mailman/listinfo/crash-utility
>
> End of Crash-utility Digest, Vol 85, Issue 16
> *********************************************
>
11 years, 8 months
Re: [Crash-utility] how to generate xen hypervisor core though kdump or other way?
by Daniel Kiper
Hi,
> My server is Suse Linux SLES11 sp2 verison ,
>
> HjCloud:~ # uname -a
> Linux HjCloud 3.0.38-0.5-xen #1 SMP Fri Aug 3 09:02:17 UTC 2012 (358029e) x86_64 x86_64 x86_64 > GNU/Linux
>
> I know to get dom0 kdump core by "echo c >/proc/sysrq-trigger ",
>
> but don't know how to get xen hypervisor core, then how to analysis
> the hypervisor core by Crash software.
>
> Can you help me?
Does it work? If yes then /proc/vmcore
contains proper memory image with
Xen dump. Just get copy of it,
get xen-syms (or something like that;
I do not know how it is called in SLES)
and pass them to crash tool. That is it.
Daniel
11 years, 8 months
