- Original Message -
> Hi Dave
>
> On Wed, Jul 26, 2017 at 10:21 AM, Michael S. Tsirkin wrote:
> > On Sat, Jul 15, 2017 at 01:47:50AM +0200, Marc-André Lureau wrote:
> >> >
> >> > There's more info scattered in other places.
> >> >
> >> > Why do you get to document it? Because you are t
ook OK to me.
> >
> > Reviewed-by: Laszlo Ersek
>
> Without it, crash doesn't read the vmcoreinfo PT_NOTE. And for some
> reason, the phys_base in the header wasn't enough (to be doubled
> checked).
>
> Any comment Dave about crash handling of vmcoreinfo in kdump f
- Original Message -
> Hi,
>
> Latest linux kernel enabled kaslr to randomize phys/virt memory
> addresses. There has been some effort to support kexec/kdump so that
> crash utility can still works in case crashed kernel has kaslr
> enabled.
>
> This series aims to provide enough inform
- Original Message -
>
>
> On 09/11/2016 16:28, Dave Anderson wrote:
> > I'm not sure whether this "guest userspace agent" is still in play here,
> > but if there were such a thing, it could theoretically do the same
> > thing that crash cu
works in case crashed kernel has kaslr enabled.
> >
> > But according to Dave Anderson virsh dump does not work, quoted messages
> > from Dave below:
> >
> > """
> > with virsh dump, there's no way of even knowing that KASLR
> &g
t; > >>
> > >> Latest linux kernel enabled kaslr to randomiz phys/virt memory
> > >> addresses, we had some effort to support kexec/kdump so that crash
> > >> utility can still works in case crashed kernel has kaslr enabled.
> > >
- Original Message -
> Hi,
>
> Latest linux kernel enabled kaslr to randomiz phys/virt memory
> addresses, we had some effort to support kexec/kdump so that crash
> utility can still works in case crashed kernel has kaslr enabled.
>
> But according to Dave Anderso
- Original Message -
> > Can you fetch that in "crash"? If you can, then there's nothing to do on
> > the qemu side (and I'll have to apologize for spamming a bunch of lists
> > :/).
Well, let's be clear -- I was the one who put you up to it...
But no apology is required -- and in fact
- Original Message -
> 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, Petr Tesarik wrote:
> >>> On Wed, 12 Nov 2014 12:08:38 +0900 (JST)
> >>
- Original Message -
> On Tue, 22 Apr 2014 09:19:48 -0400 (EDT)
> Dave Anderson wrote:
> >
> >
> > - Original Message -
> > > On Mon, Apr 21, 2014 at 4:48 PM, Greg Kurz
> > > wrote:
> > >
> > > > O
alysed using the crash utility
> (http://people.redhat.com/anderson/).
> Crash tool is a wrapper around gdb and in addition to normal gdb commands,
> it supports various other commands which make sense for a system dump.
>
> Based on my limited exposure to crash tool, currently cr
- Original Message -
> I haven't been there at the original creation of this functionality, but
> I tend to agree with you. For analyzing the vmcore with gdb or crash,
> the alignment doesn't seem to be important, so it was probably ignored.
With respect to the crash utility, the p_alig
tware/gdb/bugs/>...
> Reading symbols from
> /usr/lib/debug/lib/modules/2.6.32-71.el6.x86_64/vmlinux...done.
> [New ]
> [New ]
> #0 0x8103be8b in ?? ()
> (gdb) bt
> #0 0x8103be8b in ?? ()
> Cannot access memory at address 0x8170dec8
> (gdb) q
>
> My first and the most important question is that: Is there necessary
> to continue this work?
>
> The attachment is the sample patch.
>
> Thanks
> Wen Congyang
>From an enterprise/support point of view, the wholesale replacement
of the current use of the savevm dumpfile format by "virsh dump" with
this ELF style format would be a *huge* improvement.
Dave Anderson
- Original Message -
> On 10/25/2011 10:23 AM, Avi Kivity wrote:
> > On 10/25/2011 10:06 AM, Wen Congyang wrote:
> >> Hi, Avi Kivity, Dave Anderson
> >>
> >> I have two questions about it:
> >>
> >> 1. How to know the guest&
- Original Message -
> > > No, an ELF image of the guest's physical memory.
> >
> > Well then that should be pretty straight forward to support. Depending upon
> > how similar it would be to the "standard" kdump ELF format, the only other
> > issue is how to determine the physical base
- Original Message -
> On 10/24/2011 04:25 PM, Dave Anderson wrote:
> > > The question is that: 'virsh dump' can not be used when host pci device
> > > is used by guest. We are discussing how to fix the problem. We have
> > > determined
> &g
- Original Message -
> The question is that: 'virsh dump' can not be used when host pci device
> is used by guest. We are discussing how to fix the problem. We have determined
> that introduce a new monitor command dump. Jan suggested that the core file's
> format is gdb standard core fo
var's value, or some other information from kernel. If kernel panics,
> >> we can use gdb to attach to a remote target as you said. But on end user
> >> machine,
> >> we can not do it, we should dump the memory into a file and analyze it in
> >> another
> >&g
18 matches
Mail list logo
