FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Redhat > Crash Utility

 
 
LinkBack Thread Tools
 
Old 09-10-2010, 06:50 PM
"LI, Feng"
 
Default How to open 32 bit dom0 kdump....

Hey you all,

I am a kind of new to xen kernel dump analysis.* Right now I have a fishy problem.* I have generated vmcore dump from dom0 which is 32 bit PAE linux kernel running over 64 bit XEN kernel.*

BUT, I have diverticulitis to open the vmcore file. If I open it with crash32,* crash32 would complain that vmcore is 64 bit image, while crash64 would complain dom0 kernel image is 32 bit.*


Could any body solve my problem ?
Thanks in advance for any help and suggestions.

Yours
Kevin F LI

--
Crash-utility mailing list
Crash-utility@redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility
 
Old 09-10-2010, 07:17 PM
Dave Anderson
 
Default How to open 32 bit dom0 kdump....

----- "Feng LI" <funglee@gmail.com> wrote:

> Hey you all,
>
> I am a kind of new to xen kernel dump analysis. Right now I have a
> fishy problem. I have generated vmcore dump from dom0 which is 32 bit
> PAE linux kernel running over 64 bit XEN kernel.
>
> BUT, I have diverticulitis to open the vmcore file. If I open it with
> crash32, crash32 would complain that vmcore is 64 bit image, while
> crash64 would complain dom0 kernel image is 32 bit.
>
> Could any body solve my problem ?
> Thanks in advance for any help and suggestions.

Can you explain again what your setup is? I don't understand what
you mean when you say that you "have generated vmcore dump from dom0
which is 32 bit PAE linux kernel running over 64 bit XEN kernel".

What crashed -- the 64-bit dom0 kernel or the 32-bit domU guest kernel?

Dave

>
> Yours
> Kevin F LI

--
Crash-utility mailing list
Crash-utility@redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility
 
Old 09-10-2010, 07:36 PM
"LI, Feng"
 
Default How to open 32 bit dom0 kdump....

Sorry about the confusion, I don't have any domU guest running...

My grub menu.lst is,
******* kernel /boot/xen.gz watchdog=0 dom0_mem=1024M lowmem_emergency_pool=16M crashkernel=128M@32M nmi=dom0
******* module /boot/vmlinuz-2.6.27.42-0.1.1.xs5.6.0.44.111158xen ro ramdisk_size=250000 nmi_watchdog=0 xencons=off console=rcons0

******* module /boot/initrd-5.6.0-31188p.img

xen.gz is 64 bit one,* while dom0 kernel is 32bit...

I am using echo c > /proc/sysrq-trigger to generate the kernel dump.*

When I tried to open the kernel dump,




[debugger@crash HV_crash]$ crash32 vmlinux-2.6.27
vmcore-2010-09-02-22-30-38


crash32 5.0.3


……………….


This program has absolutely no warranty.* Enter "help
warranty" for details.


*


WARNING: machine type mismatch:


******** crash utility:
X86


********
vmcore-2010-09-02-22-30-38: X86_64


*


crash32: vmcore-2010-09-02-22-30-38: not a supported file format


*


*


[debugger@crash HV_crash]$ crash64 vmlinux-2.6.27
vmcore-2010-09-02-22-30-38


crash64 5.0.3


………………….


WARNING: machine type mismatch:


******** crash utility:
X86_64


******** vmlinux-2.6.27:
X86


*


crash64: vmlinux-2.6.27: not a supported file format


*



Thanks Dave.





On Fri, Sep 10, 2010 at 3:17 PM, Dave Anderson <anderson@redhat.com> wrote:



----- "Feng LI" <funglee@gmail.com> wrote:



> Hey you all,

>

> I am a kind of new to xen kernel dump analysis. Right now I have a

> fishy problem. I have generated vmcore dump from dom0 which is 32 bit

> PAE linux kernel running over 64 bit XEN kernel.

>

> BUT, I have diverticulitis to open the vmcore file. If I open it with

> crash32, crash32 would complain that vmcore is 64 bit image, while

> crash64 would complain dom0 kernel image is 32 bit.

>

> Could any body solve my problem ?

> Thanks in advance for any help and suggestions.



Can you explain again what your setup is? *I don't understand what

you mean when you say that you "have generated vmcore dump from dom0

which is 32 bit PAE linux kernel running over 64 bit XEN kernel".



What crashed -- the 64-bit dom0 kernel or the 32-bit domU guest kernel?



Dave



>

> Yours

> Kevin F LI



--

Crash-utility mailing list

Crash-utility@redhat.com

https://www.redhat.com/mailman/listinfo/crash-utility



--
Crash-utility mailing list
Crash-utility@redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility
 
Old 09-10-2010, 08:27 PM
Dave Anderson
 
Default How to open 32 bit dom0 kdump....

----- "Feng LI" <funglee@gmail.com> wrote:

> Sorry about the confusion, I don't have any domU guest running...
>
> My grub menu.lst is,
> kernel /boot/xen.gz watchdog=0 dom0_mem=1024M
> lowmem_emergency_pool=16M crashkernel=128M@32M nmi=dom0
> module /boot/vmlinuz-2.6.27.42-0.1.1.xs5.6.0.44.111158xen ro
> ramdisk_size=250000 nmi_watchdog=0 xencons=off console=rcons0
> module /boot/initrd-5.6.0-31188p.img
>
> xen.gz is 64 bit one, while dom0 kernel is 32bit...
>
> I am using echo c > /proc/sysrq-trigger to generate the kernel dump.
>
> When I tried to open the kernel dump,
>
>
>
> [debugger@crash HV_crash]$ crash32 vmlinux-2.6.27
> vmcore-2010-09-02-22-30-38
>
> crash32 5.0.3
>
> ……………….
>
> This program has absolutely no warranty. Enter "help warranty" for
> details.
>
> WARNING: machine type mismatch:
> crash utility: X86
> vmcore-2010-09-02-22-30-38: X86_64
>
> crash32: vmcore-2010-09-02-22-30-38: not a supported file format

Well, for starters, the crash utility must match the vmlinux file type,
i.e., you should be using the 32-bit version.

What is the output of:

# readelf -a vmcore-010-09-02-22-30-38

Dave

>
> [debugger@crash HV_crash]$ crash64 vmlinux-2.6.27 vmcore-2010-09-02-22-30-38
>
> crash64 5.0.3
>
> ………………….
>
> WARNING: machine type mismatch:
> crash utility: X86_64
> vmlinux-2.6.27: X86
>
> crash64: vmlinux-2.6.27: not a supported file format
>
>

--
Crash-utility mailing list
Crash-utility@redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility
 
Old 09-10-2010, 08:32 PM
 
Default How to open 32 bit dom0 kdump....

Malparidoo no quiero que me mandes mas mensajes

Sent from my BlackBerry® wireless device

-----Original Message-----
From: Dave Anderson <anderson@redhat.com>
Sender: crash-utility-bounces@redhat.com
Date: Fri, 10 Sep 2010 16:27:02
To: Discussion list for crash utility usage,maintenance and development<crash-utility@redhat.com>
Reply-To: "Discussion list for crash utility usage,
maintenance and development" <crash-utility@redhat.com>
Subject: Re: [Crash-utility] How to open 32 bit dom0 kdump....


----- "Feng LI" <funglee@gmail.com> wrote:

> Sorry about the confusion, I don't have any domU guest running...
>
> My grub menu.lst is,
> kernel /boot/xen.gz watchdog=0 dom0_mem=1024M
> lowmem_emergency_pool=16M crashkernel=128M@32M nmi=dom0
> module /boot/vmlinuz-2.6.27.42-0.1.1.xs5.6.0.44.111158xen ro
> ramdisk_size=250000 nmi_watchdog=0 xencons=off console=rcons0
> module /boot/initrd-5.6.0-31188p.img
>
> xen.gz is 64 bit one, while dom0 kernel is 32bit...
>
> I am using echo c > /proc/sysrq-trigger to generate the kernel dump.
>
> When I tried to open the kernel dump,
>
>
>
> [debugger@crash HV_crash]$ crash32 vmlinux-2.6.27
> vmcore-2010-09-02-22-30-38
>
> crash32 5.0.3
>
> ……………….
>
> This program has absolutely no warranty. Enter "help warranty" for
> details.
>
> WARNING: machine type mismatch:
> crash utility: X86
> vmcore-2010-09-02-22-30-38: X86_64
>
> crash32: vmcore-2010-09-02-22-30-38: not a supported file format

Well, for starters, the crash utility must match the vmlinux file type,
i.e., you should be using the 32-bit version.

What is the output of:

# readelf -a vmcore-010-09-02-22-30-38

Dave

>
> [debugger@crash HV_crash]$ crash64 vmlinux-2.6.27 vmcore-2010-09-02-22-30-38
>
> crash64 5.0.3
>
> ………………….
>
> WARNING: machine type mismatch:
> crash utility: X86_64
> vmlinux-2.6.27: X86
>
> crash64: vmlinux-2.6.27: not a supported file format
>
>

--
Crash-utility mailing list
Crash-utility@redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility

--
Crash-utility mailing list
Crash-utility@redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility
 
Old 09-10-2010, 08:48 PM
"LI, Feng"
 
Default How to open 32 bit dom0 kdump....

Thanks Dave.
*
I attached the output of elfread -a with this email...
*
*
Yours
*
Kevin F Li
*
[debugger@crash HV_crash]$ readelf -a vmcore-2010-09-09-19-36-54
ELF Header:
Magic: 7f 45 4c 46 02 01 01 00 00 00 00 00 00 00 00 00
Class: ELF64
Data: 2's complement, little endian
Version: 1 (current)
OS/ABI: UNIX - System V
ABI Version: 0
Type: CORE (Core file)
Machine: Advanced Micro Devices X86-64
Version: 0x1
Entry point address: 0x0
Start of program headers: 64 (bytes into file)
Start of section headers: 0 (bytes into file)
Flags: 0x0
Size of this header: 64 (bytes)
Size of program headers: 56 (bytes)
Number of program headers: 7
Size of section headers: 0 (bytes)
Number of section headers: 0
Section header string table index: 0

There are no sections in this file.

There are no section groups in this file.

Program Headers:
Type Offset VirtAddr PhysAddr
FileSiz MemSiz Flags Align
NOTE 0x00000000000001c8 0x0000000000000000 0x0000000000000000
0x0000000000001408 0x0000000000001408 0
LOAD 0x00000000000015d0 0x00000000c0000000 0x0000000000000000
0x00000000000a0000 0x00000000000a0000 RWE 0
LOAD 0x00000000000a15d0 0x00000000c0100000 0x0000000000100000
0x0000000001f00000 0x0000000001f00000 RWE 0
LOAD 0x0000000001fa15d0 0x00000000ca000000 0x000000000a000000
0x000000002e000000 0x000000002e000000 RWE 0
LOAD 0x000000002ffa15d0 0xffffffffffffffff 0x0000000038000000
0x000000004698a000 0x000000004698a000 RWE 0
LOAD 0x000000007692b5d0 0xffffffffffffffff 0x0000000080000000
0x0000000057f70000 0x0000000057f70000 RWE 0
LOAD 0x00000000ce89b5d0 0xffffffffffffffff 0x0000000100000000
0x0000000128000000 0x0000000128000000 RWE 0

There is no dynamic section in this file.

There are no relocations in this file.

There are no unwind sections in this file.

No version information found in this file.

Notes at offset 0x000001c8 with length 0x00001408:
Owner Data size Description
VMCOREINFO 0x000003f0 Unknown note type: (0x00000000)
VMCOREINFO_XEN 0x00000fe4 Unknown note type: (0x00000000)--
Crash-utility mailing list
Crash-utility@redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility
 
Old 09-10-2010, 09:03 PM
Dave Anderson
 
Default How to open 32 bit dom0 kdump....

----- "Feng LI" <funglee@gmail.com> wrote:

> Thanks Dave.
>
> I attached the output of elfread -a with this email...

Hmmm -- now that I think about it, it's seems that the crash
utility has never supported dom0 vmcores generated from this
type of Xen hypervisor/dom0 combination.

Red Hat kernel versions come with the xen.gz and vmlinuz files
packaged together, i.e., both 64-bit or both 32-bit:

# rpm -qpl kernel-xen-2.6.18-219.el5.x86_64.rpm
/boot/.vmlinuz-2.6.18-219.el5xen.hmac
/boot/System.map-2.6.18-219.el5xen
/boot/config-2.6.18-219.el5xen
/boot/symvers-2.6.18-219.el5xen.gz
/boot/vmlinuz-2.6.18-219.el5xen
/boot/xen-syms-2.6.18-219.el5
/boot/xen.gz-2.6.18-219.el5 <= 64-bit
...

# rpm -qpl kernel-xen-2.6.18-219.el5.i686.rpm
/boot/.vmlinuz-2.6.18-219.el5xen.hmac
/boot/System.map-2.6.18-219.el5xen
/boot/config-2.6.18-219.el5xen
/boot/symvers-2.6.18-219.el5xen.gz
/boot/vmlinuz-2.6.18-219.el5xen
/boot/xen-syms-2.6.18-219.el5
/boot/xen.gz-2.6.18-219.el5 <= 32-bit
...

So, it's highly unlikely that either internally to Red Hat,
or any of our customers, would ever run such a combination.
And I don't recall ever working with the crash utility to
support it.

I'm curious whether anybody on this list has ever done this?

After all these years of Xen existence, you would think that
somebody else would have bumped into this anomoly before...

Dave

--
Crash-utility mailing list
Crash-utility@redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility
 
Old 09-12-2010, 01:15 AM
"LI, Feng"
 
Default How to open 32 bit dom0 kdump....

Thanks Dave,

I had tried another combination: 32 bit Xen kernel with 32 bit Dom0 kernel, but I have the similar issue. The vmcore file is still in 64 bit format. (Our system has a large memory configuration 8GB-192GB), Is there any way I can generate elf32 vmcore file ?


Thanks.

On Fri, Sep 10, 2010 at 5:03 PM, Dave Anderson <anderson@redhat.com> wrote:



----- "Feng LI" <funglee@gmail.com> wrote:



> Thanks Dave.

>

> I attached the output of elfread -a with this email...



Hmmm -- now that I think about it, it's seems that the crash

utility has never supported dom0 vmcores generated from this

type of Xen hypervisor/dom0 combination.



Red Hat kernel versions come with the xen.gz and vmlinuz files

packaged together, i.e., both 64-bit or both 32-bit:



*# rpm -qpl kernel-xen-2.6.18-219.el5.x86_64.rpm

*/boot/.vmlinuz-2.6.18-219.el5xen.hmac

*/boot/System.map-2.6.18-219.el5xen

*/boot/config-2.6.18-219.el5xen

*/boot/symvers-2.6.18-219.el5xen.gz

*/boot/vmlinuz-2.6.18-219.el5xen

*/boot/xen-syms-2.6.18-219.el5

*/boot/xen.gz-2.6.18-219.el5 * * * <= 64-bit

*...



*# rpm -qpl kernel-xen-2.6.18-219.el5.i686.rpm

*/boot/.vmlinuz-2.6.18-219.el5xen.hmac

*/boot/System.map-2.6.18-219.el5xen

*/boot/config-2.6.18-219.el5xen

*/boot/symvers-2.6.18-219.el5xen.gz

*/boot/vmlinuz-2.6.18-219.el5xen

*/boot/xen-syms-2.6.18-219.el5

*/boot/xen.gz-2.6.18-219.el5 * * * <= 32-bit

*...



So, it's highly unlikely that either internally to Red Hat,

or any of our customers, would ever run such a combination.

And I don't recall ever working with the crash utility to

support it.



I'm curious whether anybody on this list has ever done this?



After all these years of Xen existence, you would think that

somebody else would have bumped into this anomoly before...



Dave



--

Crash-utility mailing list

Crash-utility@redhat.com

https://www.redhat.com/mailman/listinfo/crash-utility



--
Crash-utility mailing list
Crash-utility@redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility
 
Old 09-13-2010, 01:02 PM
Dave Anderson
 
Default How to open 32 bit dom0 kdump....

----- "Feng LI" <funglee@gmail.com> wrote:

> Thanks Dave,
>
> I had tried another combination: 32 bit Xen kernel with 32 bit Dom0
> kernel, but I have the similar issue. The vmcore file is still in 64
> bit format. (Our system has a large memory configuration 8GB-192GB),
> Is there any way I can generate elf32 vmcore file ?
>

OK, now I'm thinking mabye we've got a regression of some sort. The
bare-metal kdump procedure is designed to use the 64-bit vmcore format
all of the time because physical memory beyond the 4GB limit cannot
be referenced using the fields in a 32-bit vmcore header.

However, you can configure 32-bit by modifying /etc/sysconfig/kdump here:

# Example:
# KEXEC_ARGS="--elf32-core-headers"
KEXEC_ARGS=" --args-linux"

by making KEXEC_ARGS=" --args-linux --elf32-core-headers"

But before doing that, can you try applying the attached patch to
the crash utility?

Thanks,
Dave


> Thanks.
>
>
> On Fri, Sep 10, 2010 at 5:03 PM, Dave Anderson < anderson@redhat.com >
> wrote:
>
>
>
>
> ----- "Feng LI" < funglee@gmail.com > wrote:
>
>
> > Thanks Dave.
> >
> > I attached the output of elfread -a with this email...
>
> Hmmm -- now that I think about it, it's seems that the crash
> utility has never supported dom0 vmcores generated from this
> type of Xen hypervisor/dom0 combination.
>
> Red Hat kernel versions come with the xen.gz and vmlinuz files
> packaged together, i.e., both 64-bit or both 32-bit:
>
> # rpm -qpl kernel-xen-2.6.18-219.el5.x86_64.rpm
> /boot/.vmlinuz-2.6.18-219.el5xen.hmac
> /boot/System.map-2.6.18-219.el5xen
> /boot/config-2.6.18-219.el5xen
> /boot/symvers-2.6.18-219.el5xen.gz
> /boot/vmlinuz-2.6.18-219.el5xen
> /boot/xen-syms-2.6.18-219.el5
> /boot/xen.gz-2.6.18-219.el5 <= 64-bit
> ...
>
> # rpm -qpl kernel-xen-2.6.18-219.el5.i686.rpm
> /boot/.vmlinuz-2.6.18-219.el5xen.hmac
> /boot/System.map-2.6.18-219.el5xen
> /boot/config-2.6.18-219.el5xen
> /boot/symvers-2.6.18-219.el5xen.gz
> /boot/vmlinuz-2.6.18-219.el5xen
> /boot/xen-syms-2.6.18-219.el5
> /boot/xen.gz-2.6.18-219.el5 <= 32-bit
> ...
>
> So, it's highly unlikely that either internally to Red Hat,
> or any of our customers, would ever run such a combination.
> And I don't recall ever working with the crash utility to
> support it.
>
> I'm curious whether anybody on this list has ever done this?
>
> After all these years of Xen existence, you would think that
> somebody else would have bumped into this anomoly before...
>
> Dave
>
>
>
>
> --
> Crash-utility mailing list
> Crash-utility@redhat.com
> https://www.redhat.com/mailman/listinfo/crash-utility
>
>
> --
> Crash-utility mailing list
> Crash-utility@redhat.com
> https://www.redhat.com/mailman/listinfo/crash-utility
--
Crash-utility mailing list
Crash-utility@redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility
 
Old 09-13-2010, 06:20 PM
"LI, Feng"
 
Default How to open 32 bit dom0 kdump....

Thanks Dave,*
I tried the patch you attached in the previous email.
I am using the 32 bit crash utilities, and it seems to be able to load the vmcore (64bit). But

I still have a problem, the physical address 0x7fed9050 was padding as 0x7fed9050000, and crash32 exited with error message*
<readmem: 7fed9050000, PHYSADDR, "xen kdump p2m mfn list page", 4096, (ROE), 894f538>
** *addr: 7fed9050000 *paddr: 7fed9050000 *cnt: 4096crash32: read error: physical address: 7fed9050000 *type: "xen kdump p2m mfn list page"

Yours
Kevin F Li
ps.The output of patched crash32


This GDB was configured as "i686-pc-linux-gnu"...GETBUF(128 -> 0)
**GETBUF(1500 -> 1)
**FREEBUF(1)FREEBUF(0)<readmem: c034e720, KVADDR, "kernel_config_data", 32768, (ROE), 898e8e0>** *addr: c034e720 *paddr: 34e720 *cnt: 2272
x86_xen_kdump_p2m_create: p2m_mfn: 0<readmem: 0, PHYSADDR, "xen kdump p2m mfn page", 4096, (ROE), 894f538>** *addr: 0 *paddr: 0 *cnt: 409600000000: 7fed9050 7fed904c 7fed9058 7fed9054
00000010: 7fed9060 7fed905c f000859c f000ff5300000020: f000fea5 f000e987 f0000c75 f0000c7500000030: 99800b7c f0000c75 f000ef57 f000f545
<readmem: 7fed9050000, PHYSADDR, "xen kdump p2m mfn list page", 4096, (ROE), 894f538>
** *addr: 7fed9050000 *paddr: 7fed9050000 *cnt: 4096crash32: read error: physical address: 7fed9050000 *type: "xen kdump p2m mfn list page"
crash32: cannot read xen kdump p2m mfn list page


On Mon, Sep 13, 2010 at 9:02 AM, Dave Anderson <anderson@redhat.com> wrote:



----- "Feng LI" <funglee@gmail.com> wrote:



> Thanks Dave,

>

> I had tried another combination: 32 bit Xen kernel with 32 bit Dom0

> kernel, but I have the similar issue. The vmcore file is still in 64

> bit format. (Our system has a large memory configuration 8GB-192GB),

> Is there any way I can generate elf32 vmcore file ?

>



OK, now I'm thinking mabye we've got a regression of some sort. *The

bare-metal kdump procedure is designed to use the 64-bit vmcore format

all of the time because physical memory beyond the 4GB limit cannot

be referenced using the fields in a 32-bit vmcore header.



However, you can configure 32-bit by modifying /etc/sysconfig/kdump here:



*# Example:

*# * KEXEC_ARGS="--elf32-core-headers"

*KEXEC_ARGS=" --args-linux"



by making KEXEC_ARGS=" --args-linux --elf32-core-headers"



But before doing that, can you try applying the attached patch to

the crash utility?



Thanks,

*Dave





> Thanks.

>

>

> On Fri, Sep 10, 2010 at 5:03 PM, Dave Anderson < anderson@redhat.com >

> wrote:

>

>

>

>

> ----- "Feng LI" < funglee@gmail.com > wrote:

>

>

> > Thanks Dave.

> >

> > I attached the output of elfread -a with this email...

>

> Hmmm -- now that I think about it, it's seems that the crash

> utility has never supported dom0 vmcores generated from this

> type of Xen hypervisor/dom0 combination.

>

> Red Hat kernel versions come with the xen.gz and vmlinuz files

> packaged together, i.e., both 64-bit or both 32-bit:

>

> # rpm -qpl kernel-xen-2.6.18-219.el5.x86_64.rpm

> /boot/.vmlinuz-2.6.18-219.el5xen.hmac

> /boot/System.map-2.6.18-219.el5xen

> /boot/config-2.6.18-219.el5xen

> /boot/symvers-2.6.18-219.el5xen.gz

> /boot/vmlinuz-2.6.18-219.el5xen

> /boot/xen-syms-2.6.18-219.el5

> /boot/xen.gz-2.6.18-219.el5 <= 64-bit

> ...

>

> # rpm -qpl kernel-xen-2.6.18-219.el5.i686.rpm

> /boot/.vmlinuz-2.6.18-219.el5xen.hmac

> /boot/System.map-2.6.18-219.el5xen

> /boot/config-2.6.18-219.el5xen

> /boot/symvers-2.6.18-219.el5xen.gz

> /boot/vmlinuz-2.6.18-219.el5xen

> /boot/xen-syms-2.6.18-219.el5

> /boot/xen.gz-2.6.18-219.el5 <= 32-bit

> ...

>

> So, it's highly unlikely that either internally to Red Hat,

> or any of our customers, would ever run such a combination.

> And I don't recall ever working with the crash utility to

> support it.

>

> I'm curious whether anybody on this list has ever done this?

>

> After all these years of Xen existence, you would think that

> somebody else would have bumped into this anomoly before...

>

> Dave

>

>

>

>

> --

> Crash-utility mailing list

> Crash-utility@redhat.com

> https://www.redhat.com/mailman/listinfo/crash-utility

>

>

> --

> Crash-utility mailing list

> Crash-utility@redhat.com

> https://www.redhat.com/mailman/listinfo/crash-utility


--

Crash-utility mailing list

Crash-utility@redhat.com

https://www.redhat.com/mailman/listinfo/crash-utility




--
Crash-utility mailing list
Crash-utility@redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility
 

Thread Tools




All times are GMT. The time now is 08:53 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org