Re: [Crash-utility] [PATCH] s390dbf: Use correct file descriptor for command output
by Dave Anderson
----- "Michael Holzheu" <holzheu(a)linux.vnet.ibm.com> wrote:
> Hi Dave,
>
> Currently for the s390dbf command we use stdout as file descriptor. This
> has the drawback that it is not possible to grep through the output of
> the command.
>
> To solve the problem with this patch we use "fp" instead of "stdout".
Queued for the next release.
Thanks,
Dave
>
> Michael
>
> PS: I am no longer able to download the crash tarball from your web site:
> http://people.redhat.com/anderson/crash-5.0.4.tar.gz
> ---
> s390dbf.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> --- a/s390dbf.c
> +++ b/s390dbf.c
> @@ -1325,7 +1325,7 @@ void cmd_s390dbf()
> int i,c;
>
> command_t cmd = {
> - .ofp = stdout,
> + .ofp = fp,
> .efp = stderr,
> .cmdstr = "s390dbf",
> .command = "s390dbf",
>
>
14 years
[PATCH] s390dbf: Use correct file descriptor for command output
by Michael Holzheu
Hi Dave,
Currently for the s390dbf command we use stdout as file descriptor. This
has the drawback that it is not possible to grep through the output of
the command.
To solve the problem with this patch we use "fp" instead of "stdout".
Michael
PS: I am no longer able to download the crash tarball from your web
site:
http://people.redhat.com/anderson/crash-5.0.4.tar.gz
---
s390dbf.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/s390dbf.c
+++ b/s390dbf.c
@@ -1325,7 +1325,7 @@ void cmd_s390dbf()
int i,c;
command_t cmd = {
- .ofp = stdout,
+ .ofp = fp,
.efp = stderr,
.cmdstr = "s390dbf",
.command = "s390dbf",
14 years
[PATCH] Fix reading x86_64 xendump cores on 2.6.27+
by Petr Tesarik
Hi,
the crash utility is unable to read xendump cores from kernel versions
2.6.27 or newer. Bernhard fixed this only for kdump Xen cores.
With 2.6.27 and newer kernels, the max_pfn symbol should be used
to get the highest PFN in the system. However, xendump code still
tries to use end_pfn. Without the patch, early initialization
fails with the error message: "crash: cannot resolve "end_pfn".
Signed-off-by: Petr Tesarik <ptesarik(a)suse.cz>
---
x86_64.c | 22 ++++++++++++++++++++--
1 file changed, 20 insertions(+), 2 deletions(-)
--- a/x86_64.c
+++ b/x86_64.c
@@ -4851,6 +4851,7 @@ x86_64_xen_kdump_p2m_create(struct xen_k
ulong frames;
ulong frame_mfn[MAX_X86_64_FRAMES] = { 0 };
int mfns[MAX_X86_64_FRAMES] = { 0 };
+ struct syment *sp;
/*
* Temporarily read physical (machine) addresses from vmcore by
@@ -4932,7 +4933,15 @@ use_cr3:
x86_64_debug_dump_page(fp, machdep->machspec->pml4,
"contents of PML4 page:");
- kvaddr = symbol_value("end_pfn");
+ /*
+ * kernel version < 2.6.27 => end_pfn
+ * kernel version >= 2.6.27 => max_pfn
+ */
+ if ((sp = symbol_search("end_pfn")))
+ kvaddr = sp->value;
+ else
+ kvaddr = symbol_value("max_pfn");
+
if (!x86_64_xen_kdump_load_page(kvaddr, xkd->page))
return FALSE;
up = (ulong *)(xkd->page + PAGEOFFSET(kvaddr));
@@ -5262,6 +5271,7 @@ x86_64_xendump_p2m_create(struct xendump
ulong mfn, kvaddr, ctrlreg[8], ctrlreg_offset;
ulong *up;
off_t offset;
+ struct syment *sp;
if (!symbol_exists("phys_to_machine_mapping")) {
xd->flags |= XC_CORE_NO_P2M;
@@ -5299,7 +5309,15 @@ x86_64_xendump_p2m_create(struct xendump
x86_64_debug_dump_page(xd->ofp, machdep->machspec->pml4,
"contents of PML4 page:");
- kvaddr = symbol_value("end_pfn");
+ /*
+ * kernel version < 2.6.27 => end_pfn
+ * kernel version >= 2.6.27 => max_pfn
+ */
+ if ((sp = symbol_search("end_pfn")))
+ kvaddr = sp->value;
+ else
+ kvaddr = symbol_value("max_pfn");
+
if (!x86_64_xendump_load_page(kvaddr, xd))
return FALSE;
14 years
[ANNOUNCE] crash version 5.0.5 is available
by Dave Anderson
- Implemented a new "bt -F" flag as an extension of the "bt -f" flag,
which dumps the contents of each stack frame in a backtrace; but
similar to the output of "rd -S", if a stack entry can be expressed
symbolically it will be displayed as "symbol+offset", or if a stack
entry comes from a slab cache, the slab cache name will be displayed
inside brackets.
(anderson(a)redhat.com)
- Fix for the %install stanza in the crash.spec file to check for the
existence of the sial.so extension module. Without the patch, when
building the src.rpm with rpmbuild on a system without the bison and
flex packages, the installation phase fails with the error messages
"cp: cannot stat `extensions/sial.so': No such file or directory" and
"error: Bad exit status from /var/tmp/rpm-tmp.ubJZfY (%install)".
(anderson(a)redhat.com)
- Minor correction to the error message displayed by the "crash -x"
command line option when the pre-loading of an extension module fails.
Without the patch, the error message may be preceded with "foreach:"
instead of "crash:" when running with dumpfiles in which no panic
task could be ascertained.
(anderson(a)redhat.com)
- Fix for the x86_64 "bt" and "bt -E" commands if the kdump-generated
NMI interrupts a task that has just entered kernel space but has
not changed the RSP stack pointer register from its user-space
location to the kernel stack. Without the patch, the "bt" command
follows the display of the exception frame on the NMI exception
stack with the message "WARNING: possibly bogus exception frame",
displays the error message "bt: cannot transition from exception
stack to current process stack", and does not display the user-space
exception frame; the "bt -E" command does not find and display the
kernel-space exception frame generated by the NMI.
(anderson(a)redhat.com)
- Fix for compiler warnings when building "net.c" with -O2. Without
the patch, there are 6 messages that indicate "warning: dereferencing
pointer '<arg>' does break strict-aliasing rules".
(anderson(a)redhat.com)
- Fix for a compiler warning when building "gdb_interface.c" with -O2.
Without the patch, there is 1 message that indicates "warning:
dereferencing type-punned pointer will break strict-aliasing rules".
(anderson(a)redhat.com)
- Fix for the x86 "bt" command if the crash occurs during the execution
of a kernel module's init_module() function. Without the patch, the
backtrace attempt would contain a stack frame with a "(null)" symbol
name, display "bt: cannot resolve stack trace", dump the text symbols
on the stack, and any possible exception frames.
(anderson(a)redhat.com)
- Fix to support newer KVM dumpfile format generated by "virsh dump"
that may contain "block" and "kvmclock" devices in the dumpfile
header. Without the patch, the session fails with the error message
"crash: <dumpfile>: initialization failed".
(pbonzini(a)redhat.com, anderson(a)redhat.com)
- Fix for "kmem -[sS]" command on 2.6.34 and later CONFIG_SLUB kernels,
which changed the kmem_cache.cpu_slab[NR_CPUS] array to be a per-cpu
offset value. Without the patch, the command fails with the message
"kmem: cannot determine location of kmem_cache.cpu_slab page".
(anderson(a)redhat.com)
- Modified the "kmem -p" output to show the "INDEX" column values with
a hexadecimal value because the "page.index" member is typically a
shared-use field that may also contain a pointer value. Without the
patch, pointer values would be displayed as large negative decimal
values.
(anderson(a)redhat.com)
- Addressed compiler warnings generated by net.c when built with -O2.
(anderson(a)redhat.com)
- Fix for the "kmem <address>" command if the kernel's free page
lists are corrupt, or in a state of flux, and cannot be followed.
Without the patch, the search for page usage in the various locations
is aborted if the free page lists cannot be traversed.
(anderson(a)redhat.com)
- Fix to read KVM dumpfiles generated by the "virsh dump" of a RHEL5
guest from a RHEL6 host, and to support dumpfile format changes that
contain "apic" and "__rhel5" devices. Without the patch, the session
may fail during initialization with a segmentation violation, or with
the error message "crash: <dumpfile>: initialization failed".
(pbonzini(a)redhat.com)
Download from: http://people.redhat.com/anderson
14 years
Re: [Crash-utility] crash can't handle virsh dump file
by Dave Anderson
Hi Gui,
This is the patch that is queued for the next release:
http://people.redhat.com/anderson/qemu_block_kvmclock_devices.patch
I've tested it against the dumpfile that you made available.
Thank you for your help, and to Paolo for the patch.
Dave
----- "Gui Jianfeng" <guijianfeng(a)cn.fujitsu.com> wrote:
> Gui Jianfeng wrote:
> > Dave Anderson wrote:
> >> ----- "Gui Jianfeng" <guijianfeng(a)cn.fujitsu.com> wrote:
> >>
> >>> Dave Anderson wrote:
> >>>> ----- "Dave Anderson" <anderson(a)redhat.com> wrote:
> >>>>
> >>>>> ----- "Paolo Bonzini" <pbonzini(a)redhat.com> wrote:
> >>>>>
> >>>>>>> According to coredump, seems crash crashed at get_idt_base().
> >>>>>>> device_find_instance() fails to find "cpu" instance.
> >>>>>> I think Dave already has a patch for this.
> >>>>>>
> >>>>>> Paolo
> >>>>> The patch for get_idt_base() was put in crash version 5.0.4.
> >>>>> Looking back at the mail archives, though, I don't see what
> >>>>> version Gui is/was using?
> >>>>>
> >>>>> Dave
> >>>> Now I see with the crash debug output that Gui is using version
> >>>> 5.0.3. Can you please retry Paolo's patch on top of version
> >>>> 5.0.4?
> >>>>
> >>> Hi Dave,
> >>>
> >>> I did apply Paolo's patch on top of version 5.0.4, the bug is
> still there.
> >>> I checked the 5.0.4 changelog and didn't see the fix for this.
> >> Sorry, the 5.0.4 fix I was referring to was in get_kernel_base(),
> which is
> >> called with the result from get_idt_base(). So, just to be clear,
> when it
> >> crashes in get_idt_base(), it's because device_find_instance() call
> returns
> >> a NULL?
> >
> > That's true.
> >
> >> static uint64_t
> >> get_idt_base(struct qemu_device_list *dl)
> >> {
> >> struct qemu_device_x86 *dx86 = (struct qemu_device_x86
> *)
> >> device_find_instance (dl, "cpu", 0);
> >>
> >> return dx86->idt.base;
> >> }
> >>
> >> So, it seems that with Paolo's patch, it can find the "block" device, but
> >> then can no longer find the "cpu" device?
> >
> > Yes.
> >
> >> Can you make a vmlinux/vmcore pair available for me to download?
> >
> > Ok, will do later.
>
> Hi Dave,
>
> Please use the following link to download the vmlinux/vmcore
>
> http://dl.dropbox.com/u/4918988/core.dump
> http://dl.dropbox.com/u/4918988/f12_vmlinux
>
14 years
Re: [Crash-utility] crash can't handle virsh dump file
by Dave Anderson
----- "Gui Jianfeng" <guijianfeng(a)cn.fujitsu.com> wrote:
> Dave Anderson wrote:
> > ----- "Dave Anderson" <anderson(a)redhat.com> wrote:
> >
> >> ----- "Paolo Bonzini" <pbonzini(a)redhat.com> wrote:
> >>
> >>>> According to coredump, seems crash crashed at get_idt_base().
> >>>> device_find_instance() fails to find "cpu" instance.
> >>> I think Dave already has a patch for this.
> >>>
> >>> Paolo
> >> The patch for get_idt_base() was put in crash version 5.0.4.
> >> Looking back at the mail archives, though, I don't see what
> >> version Gui is/was using?
> >>
> >> Dave
> >
> > Now I see with the crash debug output that Gui is using version
> > 5.0.3. Can you please retry Paolo's patch on top of version
> > 5.0.4?
> >
>
> Hi Dave,
>
> I did apply Paolo's patch on top of version 5.0.4, the bug is still there.
> I checked the 5.0.4 changelog and didn't see the fix for this.
Sorry, the 5.0.4 fix I was referring to was in get_kernel_base(), which is
called with the result from get_idt_base(). So, just to be clear, when it
crashes in get_idt_base(), it's because device_find_instance() call returns
a NULL?
static uint64_t
get_idt_base(struct qemu_device_list *dl)
{
struct qemu_device_x86 *dx86 = (struct qemu_device_x86 *)
device_find_instance (dl, "cpu", 0);
return dx86->idt.base;
}
So, it seems that with Paolo's patch, it can find the "block" device, but
then can no longer find the "cpu" device?
Can you make a vmlinux/vmcore pair available for me to download?
Thanks,
Dave
14 years, 1 month
Re: [Crash-utility] Query regarding "set listsize <num>" in crash tool
by Dave Anderson
----- "Munipradeep Beerakam" <mpradeep(a)linux.vnet.ibm.com> wrote:
> Hi,
>
> While I am trying to set the listsize in crash tool version 5.0.4, it is
> not happening properly, instead it is showing the task with pid of given
> parameter. Below is the sample output:
>
>
> crash> show listsize
> Number of source lines gdb will list by default is 10.
> crash> set listsize 4
> set: invalid task or pid value: listsize
> PID: 4
> COMMAND: "ksoftirqd/0"
> TASK: f7065a90 [THREAD_INFO: f7086000]
> CPU: 0
> STATE: TASK_INTERRUPTIBLE
>
>
> So, first of all is "set" command in crash tool supports changing the listsize?
> If yes, is this a bug in crash tool?
No it's not a bug -- the "set" command defaults to the crash utility's "set" command,
as is the case when entering any crash command seen when entering "help". To override
it, enter "gdb set listsize 4". See "help gdb".
Thanks,
Dave
14 years, 1 month
AUTO: Chandan12 K is out of the office (returning 06/05/2010)
by Chandan12 K
I am out of the office until 06/05/2010.
I am OOO. Please contact Santosh for any OAM issues.
Thanks
Note: This is an automated response to your message "[Crash-utility] Query
regarding "set listsize <num>" in crash tool" sent on 6/2/10 10:39:49.
This is the only notification you will receive while this person is away.
=====-----=====-----=====
Notice: The information contained in this e-mail
message and/or attachments to it may contain
confidential or privileged information. If you are
not the intended recipient, any dissemination, use,
review, distribution, printing or copying of the
information contained in this e-mail message
and/or attachments to it are strictly prohibited. If
you have received this communication in error,
please notify us by reply e-mail or telephone and
immediately and permanently delete the message
and any attachments. Thank you
14 years, 1 month
Query regarding "set listsize <num>" in crash tool
by Munipradeep Beerakam
Hi,
While I am trying to set the listsize in crash tool version 5.0.4, it is
not happening properly, instead it is showing the task with pid of given
parameter. Below is the sample output:
crash> show listsize
Number of source lines gdb will list by default is 10.
crash> set listsize 4
set: invalid task or pid value: listsize
PID: 4
COMMAND: "ksoftirqd/0"
TASK: f7065a90 [THREAD_INFO: f7086000]
CPU: 0
STATE: TASK_INTERRUPTIBLE
So, first of all is "set" command in crash tool supports changing the listsize?
If yes, is this a bug in crash tool?
Waiting for early reply.
Thanks
Muni
14 years, 1 month
Re: [Crash-utility] crash can't handle virsh dump file
by Dave Anderson
----- "Gui Jianfeng" <guijianfeng(a)cn.fujitsu.com> wrote:
> Paolo Bonzini wrote:
> > On 05/28/2010 11:19 AM, Gui Jianfeng wrote:
> >> Gui Jianfeng wrote:
> >>> Hi all,
> >>>
> >>> I made use of "virsh dump" to generate a dumpfile, but crash seems fails at initializing time.
> >>> I decode the dumpfile and found there's a "block" header section, but seems crash doesn't support
> >>> such section so it failed. Am i missing something?
> >>
> >> Any one can help? How can i make use of crash checking the dumpfile?
> >
> > Something like the attached should do it (untested because I don't know
> > where the crash upstream repo is, though I have likely asked this already).
>
> Thanks for sharing, i'll try it. :)
>
> Thanks,
> Gui
>
> >
> > Thanks,
> >
> > Paolo
> >
I missed all the excitement by taking today off. Can you let
us know how Paolo's patch worked for you?
Thanks,
Dave
14 years, 1 month
