e to show local variables:
https://github.com/jeffmahoney/crash-python
However, this project is still in very early stages (and requires a
patch to gdb, which hasn't been accepted by upstream yet). Unless you
plan to hack on it, it's probably not what you want...
Regards,
Petr Tesar
On Thu, 25 Jan 2018 16:37:01 +0800
Cao jin wrote:
> On 01/24/2018 11:23 PM, Dave Anderson wrote:
> >
> >
> > - Original Message -
> >>
> >>
> >> On 01/23/2018 11:19 PM, Dave Anderson wrote:
> >>>
> >>>
> >>> - Original Message -
> Hi Dave,
>
> Recently I
On Fri, 26 Jan 2018 11:47:20 +0800
Cao jin wrote:
> FYI: I just files a bug to gcc:
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84052
Well, I also asked my GCC colleague yesterday, and he believes it is not
a bug in the compiler itself, but rather in the randstruct GCC plugin.
In other wor
Xen commit 615588563e99a23aaf37037c3fee0c413b051f4d (Xen 4.0.0.)
extended the direct mapping to 5 TB. This area was previously
reserved for future use, so it is OK to simply change the upper
bound unconditionally.
Signed-off-by: Petr Tesarik
---
xen_hyper_defs.h | 2 +-
1 file changed, 1
On Mon, 20 May 2019 10:49:01 +0200
Petr Tesarik wrote:
> On Mon, 20 May 2019 11:28:30 +0300
> Nikolay Borisov wrote:
>
> > On 20.05.19 г. 11:24 ч., Honglei Wang wrote:
> > > Hi Nikolay,
> > >
> > > I don't think we can do the s390 analysis j
On Mon, 20 May 2019 11:28:30 +0300
Nikolay Borisov wrote:
> On 20.05.19 г. 11:24 ч., Honglei Wang wrote:
> > Hi Nikolay,
> >
> > I don't think we can do the s390 analysis just use the x86_64 crash
> > utility directly. I'm not familiar with cross build, but seems this
> > linkage might help:
> >
t.com
> Bhupesh Sharma bhsha...@redhat.com
Good luck to you.
Just curious, is there some sort of hierarchy, or is this a virtual
team of people with equal rights and duties?
Petr Tesarik
SUSE HW Enablement Team
pgpnH1plABbPe.pgp
Description: Digitální podpis OpenPGP
--
Crash-utility mailing
ash_read':
kbuild/default/crash.c:225:13: error: implicit declaration of function
'probe_kernel_read'; did you mean 'kernel_read'?
[-Werror=implicit-function-declaration]
225 | if (probe_kernel_read(buffer, vaddr, count)) {
| ^~~~~
On Fri, 11 Sep 2020 02:05:21 +0530
Bhupesh Sharma wrote:
> Hi Petr,
>
> Thanks for the patch. I have some nitpicks, please see inline:
>
> On Fri, Sep 4, 2020 at 7:24 PM Petr Tesarik wrote:
> >
> > Kernel commit fe557319aa06c23cffc9346000f119547e0f289a renamed
>
On Thu, 1 Oct 2020 00:38:23 +
HAGIO KAZUHITO(萩尾 一仁) wrote:
> Hi Alex,
>
> sorry for the delayed response.
>
> I misunderstood at first glance and have waited for the kernel patch
> adding the vmcoreinfo entry you posted, but I just found no need to
> wait for it with respect to crash.
>
>
Hi Jiri,
I'm not an expert on Xen internals, but there's quite likely no better
person to answer. So, here we go...
On Thu, 21 Jan 2021 17:18:29 +0100
Jiri Bohac wrote:
> Hi,
>
> I've just come across a situation where crash failed to open a
> dump generated by a 4.12 XEN PV dom0 kernel, termi
On Fri, 22 Jan 2021 18:23:28 +0100
Jiri Bohac wrote:
> On Fri, Jan 22, 2021 at 08:48:55AM +0100, Petr Tesarik wrote:
> > IIUC the only reason for having a physical mask at all is that all page
> > table bits beyond the current architectural limit are marked as
> > reser
kely
require a few more lines in VMCOREINFO, because debug symbols may not be
available at dump time, and I can't see any alternative method to locate the
remapped regions.
Regards,
Petr Tesarik
SUSE Linux
From: Petr Tesarik
Subject: [x86] Add correct handling of regions allocated with
Dne Út 10. ledna 2012 19:14:32 Petr Tesarik napsal(a):
> Hi folks,
>
> I've just discovered that the crash utility fails to initialize the vm
> subsystem properly on our latest SLES 32-bit kernels. It turns out that our
> kernels are compiled with CONFIG_DISCONTIGMEM=y, which
determine the number of nodes, I couldn't initialize before
vm_init. Then again, the remap mapping is accessed before vm_init() finishes.
I can see now that this is unnecessarily complicated, because the node_remap_*
variables are static arrays of MAX_NUMNODES elements, so I can get their size
Dne St 11. ledna 2012 00:37:50 Petr Tesarik napsal(a):
> [...]
> I can see now that this is unnecessarily complicated, because the
> node_remap_* variables are static arrays of MAX_NUMNODES elements, so I
> can get their size from the debuginfo at POST_GDB init and initialize a
> m
Dne Út 10. ledna 2012 19:23:24 Petr Tesarik napsal(a):
> Dne Út 10. ledna 2012 19:14:32 Petr Tesarik napsal(a):
> > Hi folks,
> >
> > I've just discovered that the crash utility fails to initialize the vm
> > subsystem properly on our latest SLES 32-bit kernels. I
Dne St 11. ledna 2012 15:37:50 Dave Anderson napsal(a):
> - Original Message -
>
> > Dne St 11. ledna 2012 00:37:50 Petr Tesarik napsal(a):
> > > [...]
> > > I can see now that this is unnecessarily complicated, because the
> > > node_remap_* vari
25774
3 Movable 0 000
And indeed, "help -v" shows:
[...]
dump_free_pages: dump_free_pages_zones_v2()
[...]
ZONE_HIGHMEM: 3
I don't know yet how to fix this, but maybe somebody can push me in the right
direction.
Petr Tesarik
SUSE
Dne Čt 12. ledna 2012 22:38:38 Petr Tesarik napsal(a):
> Hi all,
>
> it seems crash shows incorrect HighMem stats with recent kernels. E.g.:
>
> crash> kmem -i
> [...]
> TOTAL HIGH 1821682 6.9 GB 93% of TOTAL MEM
> FREE HIGH000%
t;ZONE_HIGHMEM initialization, at least w/respect to the
> FREE HIGH of "0". On the other hand, I'm looking at a recent
> x86 kernel with the Movable zone, and it has normal
> looking statistics w/respect to total-low/free-low.
Interesting. What does "kmem -n" show? How is your ZONE_HIGHMEM reported by
"help -v"?
Petr Tesarik
SUSE Linux
--
Crash-utility mailing list
Crash-utility@redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility
bt->flags |= BT_USE_GDB;
+else
+ bt->flags |= BT_THREAD_GROUP;
#endif
break;
Note that the hash sign is missing, so the pre-processor only leaves the
"break" statement... The following patch seems to help.
Signed-off-by: Petr Tesarik
Hi Michael,
I'm not a z/Series guru, but it seems to me that the address should not be
returned directly, but rather assigned to the phys_addr output parameter.
Petr Tesarik
SUSE Linux
Subject: [PATCH] s390x: fix vtop for 1M pages
It seems to me that the address should not be returned dir
r that purpose, but before doing
that, I'd like to ask if this is merely missing documentation and a bug in the
implemenatation of the existing "-h" option.
Thanks for your patience,
Petr Tesarik
--
Crash-utility mailing list
Crash-utility@redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility
ext = 0xd79d6f20,
prev = 0xd55e6220
}
d79d6d70
tasks = {
next = 0xc32c5320,
prev = 0xeede06a0
}
...
Note that the first element in the list (the one which contains the starting
list_head) is included.
Based on the above, I'm afraid don't quite get the intended goal of your
patch.
Petr Tesarik
--
Crash-utility mailing list
Crash-utility@redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility
Dne Čt 7. června 2012 03:58:16 qiaonuohan napsal(a):
> At 2012-6-6 21:44, Petr Tesarik wrote:
> > crash> list task_struct.tasks -s task_struct.tasks -h 0xeede04f0+432
> > eede04f0
> >
> >tasks = {
> >
> > nex
Dne Čt 7. června 2012 14:07:59 Petr Tesarik napsal(a):
> Dne Čt 7. června 2012 03:58:16 qiaonuohan napsal(a):
> > At 2012-6-6 21:44, Petr Tesarik wrote:
> > > crash> list task_struct.tasks -s task_struct.tasks -h 0xeede04f0+432
> > > eede04f0
> > >
>
:
- struct namespace
- struct namespace namespace (in struct symbol_table_data)
- char *typename (in struct gnu_request)
Can I rename them? But you said earlier that the existing API must never
change... Any other suggestions to make this include file parseable by a C++
compiler?
TIA,
Petr Tesarik
Dne Čt 26. července 2012 14:02:56 Adrien Kunysz napsal(a):
> On Thu, Jul 26, 2012 at 10:57 AM, Petr Tesarik wrote:
> > Hi all,
> >
> > as part of SUSE HackWeek8, David started work on a GUI extension using
> > Qt4, which is a C++ project. One of the early annoyanc
Hi Luc,
please consider the attached patch for inclusion in eppic.
The actual name should match the name from eppic_api.h.
The crash extension worked previously only because the it relied on
implicit declaration of the wrong name, which is ugly.
Regards,
Petr Tesarik
commit
V Fri, 7 Dec 2012 08:54:34 -0500 (EST)
Dave Anderson napsáno:
>
>
> Hi Luc,
>
> While you're in the clean-up mode, is there a quick fix
> you can make for these bison warnings?:
Like with the attached patch?
Petr Tesarik
diff --git a/libeppic/eppic.y b/libeppi
libeppic right now. Please, can you advise?
Thanks in advance,
Petr Tesarik
--
Crash-utility mailing list
Crash-utility@redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility
se, I can add all this
later if I convert libeppic to a dynamic library.
Thanks,
Petr
> On Tuesday, April 2, 2013, Petr Tesarik wrote:
>
> > Hi Luc (and all crash developers on Cc),
> >
> > since libeppic is now used at least by two projects (crash and
> > makedumpfi
I'm taking this thread to the crash-utility mailing list.
I don't know why it didn't get there...
Begin forwarded message:
Date: Wed, 19 Jun 2013 15:33:29 +0200
From: Petr Tesarik
To: ke...@lists.infradead.org
Subject: Re: Cross architecture analysis for Crash
On Fri, 14 Ju
Add standard options to override the default decimal/hexadecimal output
format.
Signed-off-by: Petr Tesarik
---
help.c|5 -
symbols.c | 22 +-
2 files changed, 25 insertions(+), 2 deletions(-)
Allow hex/dec override for "percpu"
Add standard
This piece allows to dump a percpu struct or union at a given address
on a given CPU.
Signed-off-by: Petr Tesarik
---
defs.h|2
global_data.c |1
help.c| 65
symbols.c | 156 ++
4
This patch extends the "percpu" command so that it can be used on static
variable directly (a bit like the "p" command).
Signed-off-by: Petr Tesarik
---
help.c|4 ++--
symbols.c | 57 ++---
2 files changed,
rsion-dependent (instead I used the existing infrastructure).
Comments welcome!
Petr Tesarik
--
Crash-utility mailing list
Crash-utility@redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility
ly allocated. I implemented a new command which should make
> > these people happy.
> >
> > Tested on kernel 3.11, but I didn't really add anything
> > version-dependent (instead I used the existing infrastructure).
> >
> > Comments welcome!
> >
&g
On Sat, 12 Oct 2013 21:41:49 +0200
Petr Tesarik wrote:
>[...]
> In general, I think it's a matter of taste, and if you dislike new
> commands, it all boils down to finding a suitable syntax to extend the
> existing commands. Unfortunately, "-c" (as CPU) is already take
On Tue, 15 Oct 2013 14:20:08 -0400 (EDT)
Dave Anderson wrote:
> - Original Message -
> > On Sat, 12 Oct 2013 21:41:49 +0200
> > Petr Tesarik wrote:
> >
> > >[...]
> > > In general, I think it's a matter of taste, and if you dislike new
&g
On Tue, 15 Oct 2013 12:02:51 -0400
Don Slutz wrote:
> I have some code that allows this. See the following mail thread:
>
> http://permalink.gmane.org/gmane.comp.emulators.xen.devel/174807
>
> The questions are:
>
> 1. Does remote access have a specification?
> 2. Is it supported?
I have n
Extend the argument syntax of struct/union/* commands to recognize
percpu specifiers. Note that percpu addresses are not valid kernel
virtual addresses, so they must be parsed separately.
Signed-off-by: Petr Tesarik
[PATCH 11/11] Add percpu handling to struct/union/* commands
Extend the
oe_percpu, 0) = $1 = (void *) 0x88011e214900
Signed-off-by: Petr Tesarik
[PATCH 4/11] Fix percpu handling for symbols without debuginfo
When trying to show a percpu symbol without debuginfo, crash fails like
this:
crash> p fcoe_percpu:0
p: gdb request failed: p *(*) 0x88011e2d4900
This is because gd
Previously, the array count was ignored with the "-o" option.
While I admit that repeating code is not "good style", the goto from
the middle of a loop was not nice either, and this variant removes
a dependency of the main loop on the "aflag" variable.
Signed-off
rformed early, that is before
entering the main printing loop.
Signed-off-by: Petr Tesarik
[PATCH 7/11] Cleanup handling of flags in cmd_datatype_common()
This patch improves handling of struct/union flags:
1. You can now specify a typedef with "*". Previously it fail
Make a convenience function for allocating a cpumask buffer and
put it into tools.c. Since any caller of make_cpumask() needs
such a buffer, it is better to isolate the code in a function
rather than copy it all over the place.
Signed-off-by: Petr Tesarik
[PATCH 2/11] New convenience function
Hi Dave et al.
thanks to the feedback, I have reworked my patch set. It is now much
larger than the first version, but I'm also much more happy with it.
I'm pretty sure that there are still some issues here and there, so
as always, your comments are most welcome.
Petr Tesarik
--
Cra
Convert flag variables in cmd_datatype_common() to flag values, so that
fewer values have to be passed when the main printing loop is converted
to a standalone function.
Signed-off-by: Petr Tesarik
[PATCH 6/11] Convert cmd_datatype_common variables to flags
Convert flag variables in
Move gdb output filtering to its own function so that it can be reused
from other places.
Signed-off-by: Petr Tesarik
[PATCH 1/11] Move cmd_p() main processing into its own function
Move gdb output filtering to its own function so that it can be reused
from other places.
Signed-off-by: Petr
This change allows to reuse the main loop in a different context.
Signed-off-by: Petr Tesarik
[PATCH 10/11] Move the main loop of cmd_datatype_common() to its own function
This change allows to reuse the main loop in a different context.
Signed-off-by: Petr Tesarik
---
symbols.c | 41
Extend the syntax parsed by make_cpuset() so that "a" or "all" is
an alias for all CPUs in the system.
Signed-off-by: Petr Tesarik
[PATCH 5/11] Recognize "a" and "all" as CPU specifiers
Extend the syntax parsed by make_cpuset() so that "a&quo
estored. Fortunately, a symbol name followed
by a colon cannot start a valid C expression, so there is never any
ambiguity.
Signed-off-by: Petr Tesarik
[PATCH 3/11] Implement percpu variables for "p"
Add per-cpu specifications to the "p" command. This allows to specify
CPUs f
Instead of parsing the complete type on each iteration, move the code
to a helper function. This might be slightly faster, but most
importantly the main loop doesn't need the "structname" and "separator"
variables after this change.
Signed-off-by: Petr Tesarik
[PATCH 8/1
oe_percpu, 0) = $1 = (void *) 0x88011e214900
Signed-off-by: Petr Tesarik
---
symbols.c |3 +++
1 file changed, 3 insertions(+)
[PATCH 4/11] Fix percpu handling for symbols without debuginfo
When trying to show a percpu symbol without debuginfo, crash fails like
this:
crash> p fcoe_perc
early, that is before
entering the main printing loop.
Signed-off-by: Petr Tesarik
---
symbols.c | 20 +---
1 file changed, 9 insertions(+), 11 deletions(-)
[PATCH 7/11] Cleanup handling of flags in cmd_datatype_common()
This patch improves handling of struct/union flags:
1.
Move gdb output filtering to its own function so that it can be reused
from other places.
Signed-off-by: Petr Tesarik
---
symbols.c | 33 +
1 file changed, 21 insertions(+), 12 deletions(-)
[PATCH 1/11] Move cmd_p() main processing into its own function
Move
Instead of parsing the complete type on each iteration, move the code
to a helper function. This might be slightly faster, but most importantly
the main loop doesn't need the "structname" and "separator" variables
after this change.
Signed-off-by: Petr Tesari
Extend the syntax parsed by make_cpuset() so that "a" or "all" is
an alias for all CPUs in the system.
Signed-off-by: Petr Tesarik
---
help.c |3 ++-
tools.c | 20 +---
2 files changed, 15 insertions(+), 8 deletions(-)
[PATCH 5/11] Recognize
This change allows to reuse the main loop in a different context.
Signed-off-by: Petr Tesarik
---
symbols.c | 41 ++---
1 file changed, 22 insertions(+), 19 deletions(-)
[PATCH 10/11] Move the main loop of cmd_datatype_common() to its own function
This
Make a convenience function for allocating a cpumask buffer and
put it into tools.c. Since any caller of make_cpumask() needs
such a buffer, it is better to isolate the code in a function
rather than copy it all over the place.
Signed-off-by: Petr Tesarik
---
defs.h |1 +
kernel.c |5
Previously, the array count was ignored with the "-o" option.
While I admit that repeating code is not "good style", the goto from
the middle of a loop was not nice either, and this variant removes
a dependency of the main loop on the "aflag" variable
Extend the argument syntax of struct/union/* commands to recognize
percpu specifiers. Note that percpu addresses are not valid kernel
virtual addresses, so they must be parsed separately.
Signed-off-by: Petr Tesarik
---
help.c| 18 ++
symbols.c | 47
Hi Dave,
I'm sorry for the last submission. It seems I forgot to refresh the
patches, so it was completely bogus. Should be fixed now. I'm also
attaching my changes as one big patch to this message.
Petr Tesarik
--- a/symbols.c
+++ b/symbols.c
@@ -72,7 +72,10 @@ struct elf_common;
s
Convert flag variables in cmd_datatype_common() to flag values, so that
fewer values have to be passed when the main printing loop is converted
to a standalone function.
Signed-off-by: Petr Tesarik
---
symbols.c | 25 ++---
1 file changed, 14 insertions(+), 11 deletions
estored. Fortunately, a symbol name followed by a colon
cannot start a valid C expression, so there is never any ambiguity.
Signed-off-by: Petr Tesarik
---
help.c| 13 ++-
symbols.c | 113 +++---
2 files changed, 113 inserti
> attaching my changes as one big patch to this message.
> >
> > Petr Tesarik
>
> Hi Petr,
Hi Dave,
> I've reviewed the code changes, and have been beating on the
> patch, and I can't get it break. Really nice work...
>
>[...]
>
> I'd
> > > > I'm sorry for the last submission. It seems I forgot to refresh the
> > > > patches, so it was completely bogus. Should be fixed now. I'm also
> > > > attaching my changes as one big patch to this message.
> > > >
> > >
.4.
> The master branch will contain all patches that are queued for the
> next release:
>
> $ git clone git://github.com/crash-utility/crash.git
Hi Dave,
I have missed something like this for years...
BIG THANK YOU for setting up this repository!
Regards,
Petr Tesarik
--
Crash-util
The parameter is spelled "phys_base", not "physbase". Having the wrong
spelling in all documentation is not very helpful.
Signed-off-by: Petr Tesarik
---
crash.8 | 4 ++--
help.c | 4 ++--
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/crash.8 b/crash.8
in
V Thu, 24 Apr 2014 11:10:45 -0400 (EDT)
Dave Anderson napsáno:
>
>
> - Original Message -
> > Hello,
> >
> > I need to download an old crash source tarball, e.g. 7.0.1, but I am just
> > able to find 7.0.6 (from http://people.redhat.com/anderson/ ) and 7.0.5 and
> > 7.0.4 (from https:/
Hi all,
as discovered by my colleagues, the backtrace code has been broken for
NMI stacks since kernel commit 3f3c8b8c4b2a34776c3470142a7c8baafcda6eb0
(Linux 3.3).
I am working on a fix, but it's tricky to get all cases right. For
example, the copied and saved register locations were swapped with
On Fri, 25 Apr 2014 10:11:28 -0400 (EDT)
Dave Anderson wrote:
> - Original Message -
> > Hi all,
> >
> > as discovered by my colleagues, the backtrace code has been broken for
> > NMI stacks since kernel commit 3f3c8b8c4b2a34776c3470142a7c8baafcda6eb0
> > (Linux 3.3).
> >
> > I am worki
because the "copied" registers
contain either a copy of the "saved" registers, or point to repeat_nmi. So,
if restart_nmi is found as the return address, assume that this is the old
layout and adjust the stack pointer again.
Without the patch, wrong register values are shown in the NMI
On Sat, 24 May 2014 20:24:30 +0800
oliver yang wrote:
> 2014-04-29 19:27 GMT+08:00 Petr Tesarik :
>
> >
> > It will show an incorrect register dump, but the backtrace continues.
> > For example:
> >
>
> Hi Petr,
>
> The back trace looks good.
e latest sources available on
a public site.
Petr Tesarik
> I'm currently working on adding ppc64le support for the next upstream
> crash release. I'm working from a Fedora bugzilla filed by Michel Normand,
> where he that applied the "crash-gdb-7.6.series"
;
> FWIW the upcoming SUSE Linux Enterprise Server 12 release will ship a
> crash utility that works on ppc64le, and I think IBM has already tested
> it successfully. I'll see how I can make the latest sources available on
> a public site.
>
> Petr Tesarik
>
> > I&#
ddresses (described above)
2. Support for multiple virtual address spaces (for different process
contexts)
3. Ability to read compressed kdump files
4. Ability to use 64-bit files on 32-bit platforms (to handle PAE)
HTH,
Petr Tesarik
--
Crash-utility mailing list
Crash-utility@redhat.com
ht
ibrary, so if a new file format appears, or a new feature is added to
one of the files, it can be immediately used by all kdump-related tools.
Please let me know what you think.
Oh, and if you're developing such a tool, let me know which features
should be added.
Regards,
Petr Tesarik
--
Crash-
know which features
should be added.
Regards,
Petr Tesarik
--
Crash-utility mailing list
Crash-utility@redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility
On Tue, 11 Nov 2014 12:27:44 -0500
Christopher Covington wrote:
> On 11/11/2014 06:22 AM, Laszlo Ersek wrote:
> > (Note: I'm not subscribed to either qemu-devel or the kexec list; please
> > keep me CC'd.)
> >
> > QEMU is able to dump the guest's memory in KDUMP format (kdump-zlib,
> > kdump-lzo
On Wed, 12 Nov 2014 08:18:04 -0500
Christopher Covington wrote:
> On 11/12/2014 03:05 AM, Petr Tesarik wrote:
> > On Tue, 11 Nov 2014 12:27:44 -0500
> > Christopher Covington wrote:
> >
> >> On 11/11/2014 06:22 AM, Laszlo Ersek wrote:
> >>> (Note: I&#x
V Wed, 12 Nov 2014 08:28:54 -0500
Christopher Covington napsáno:
> On 11/12/2014 08:26 AM, Petr Tesarik wrote:
> > On Wed, 12 Nov 2014 08:18:04 -0500
> > Christopher Covington wrote:
> >
> >> On 11/12/2014 03:05 AM, Petr Tesarik wrote:
> >>> On Tue, 11
gt; you have the time.
> >>
> >> On 11/12/2014 09:10 AM, Laszlo Ersek wrote:
> >>> On 11/12/14 14:26, Petr Tesarik wrote:
> >>>> On Wed, 12 Nov 2014 08:18:04 -0500
> >>>> Christopher Covington wrote:
> >>>>
> >>>
On Wed, 12 Nov 2014 21:30:20 +0100
Laszlo Ersek wrote:
> adding back a few CC's because this discussion is useful
>
> On 11/12/14 19:43, Petr Tesarik wrote:
> > V Wed, 12 Nov 2014 15:50:32 +0100
> > Laszlo Ersek napsáno:
> >
> >> On 11/12/14 09:04,
f output formats without additional effort.
> >Ideally, I would like to replace all current implementations with
> >this library, so if a new file format appears, or a new feature is
> >added to one of the files, it can be immediately used by all
> >kdump-related tools.
&
For many years, Xen dumps could only be saved in ELF format. Since
makedumpfile commit 349a0ed1, it is also possible to save Xen dumps
in KDUMP format, but it cannot be opened by the crash utility. This
patch series adds support for these files.
Petr Tesarik (5):
Move Xen Dom0 handling into
, because these
functions are not called if XEN_MACHINE_ADDR is set in pc->curcmd_flags.
Signed-off-by: Petr Tesarik
---
ia64.c | 22 ++
x86.c | 15 +++
x86_64.c | 15 +++
xen_dom0.c | 12 ++--
4 files changed, 34 insertions(+),
Unify the initialization of struct xen_kdump_data.
Signed-off-by: Petr Tesarik
---
netdump.c | 82 ++
xen_dom0.c | 36 +++
xen_dom0.h | 1 +
3 files changed, 45 insertions(+), 74 deletions(-)
diff --git a
There is currently only one caller of xen_kdump_p2m() and it must
ensure that the p2m map is created before calling this function.
If there are multiple callers, this code would have to be repeated,
so it's better to put it directly into xen_kdump_p2m.
Signed-off-by: Petr Tesarik
---
netd
for both netdump.c and diskdump.c.
Signed-off-by: Petr Tesarik
---
Makefile | 9 ++-
ia64.c | 1 +
netdump.c | 248 -
netdump.h | 53 -
x86.c | 1 +
x86_64.c | 1 +
xen_dom0.c | 215
crash: vmlinux-3.0.34-0.7-xen.debug and vmcore-xen.d31 do not match!
Signed-off-by: Petr Tesarik
---
diskdump.c | 27 +++
1 file changed, 27 insertions(+)
diff --git a/diskdump.c b/diskdump.c
index 72df26f..2dbe472 100644
--- a/diskdump.c
+++ b/diskdump.c
@@ -25,6 +25,7
On Thu, 24 Sep 2015 15:29:11 -0400 (EDT)
Dave Anderson wrote:
> - Original Message -
> > For many years, Xen dumps could only be saved in ELF format. Since
> > makedumpfile commit 349a0ed1, it is also possible to save Xen dumps
> > in KDUMP format, but it cannot be opened by the crash uti
On Tue, 24 Nov 2015 10:09:01 +
David Vrabel wrote:
> On 24/11/15 09:55, Malcolm Crossley wrote:
> > On 24/11/15 08:59, Jan Beulich wrote:
> > On 24.11.15 at 07:55, wrote:
> >>> What about:
> >>>
> >>> 4) Instead of relying on the kernel maintained p2m list for m2p
> >>>conversion use
V Tue, 24 Nov 2015 10:35:03 +
Andrew Cooper napsáno:
> On 24/11/15 10:17, Petr Tesarik wrote:
> > On Tue, 24 Nov 2015 10:09:01 +
> > David Vrabel wrote:
> >
> >> On 24/11/15 09:55, Malcolm Crossley wrote:
> >>> On 24/11/15 08:59, Jan Beulich wro
s://www.sourceware.org/ml/gdb/2015-09/msg00014.html
Support for powerpc is currently missing, but it could be added with
relatively low effort, and there is a so-called HackWeek¹ at SUSE in the
week of Dec 7, so I could help with that. There are a few other SUSE
people interested in this project.
n
invalid CR3 value, which could not be used to translate kvaddr to maddr.
Without the patch, session initialization fails with these messages:
crash: cannot find mfn 0 (0x0) in page index
crash: cannot read/find pud page
Signed-off-by: Petr Tesarik
Do not create arch-specific p2m mapping for
invalid CR3 value, which could not be used to translate kvaddr to maddr.
> > Without the patch, session initialization fails with these messages:
> >
> > crash: cannot find mfn 0 (0x0) in page index
> >
> > crash: cannot read/find pud page
> >
> > Signed-of
. Without the patch, early initialization
fails with the error message: "crash: cannot resolve "end_pfn".
Signed-off-by: Petr Tesarik
---
x86_64.c | 22 --
1 file changed, 20 insertions(+), 2 deletions(-)
--- a/x86_64.c
+++ b/x86_64.c
@@
ause quite some headache to
Louis Bouchard. ;)
Just my $0.02,
Petr Tesarik
> > -Original Message-
> > From: crash-utility-boun...@redhat.com
> > [mailto:crash-utility-boun...@redhat.com] On Behalf Of Dave Anderson
> > Sent: Monday, June 28, 2010 2:15 PM
> > T
1 - 100 of 132 matches
Mail list logo
