Discussion:
[Fastboot] vmcore file 0 size in x86_64
Chandan12 K
2009-08-13 12:45:54 UTC
Permalink
Hi,

I checked.. through and fond out that one of the following check condition
is failing

516 if (memcmp(ehdr.e_ident, ELFMAG, SELFMAG) != 0 ||
517 (ehdr.e_type != ET_CORE) ||
518 !vmcore_elf_check_arch(&ehdr) ||
519 ehdr.e_ident[EI_CLASS] != ELFCLASS64 ||
520 ehdr.e_ident[EI_VERSION] != EV_CURRENT ||
521 ehdr.e_version != EV_CURRENT ||
522 ehdr.e_ehsize != sizeof(Elf64_Ehdr) ||
523 ehdr.e_phentsize != sizeof(Elf64_Phdr) ||
524 ehdr.e_phnum == 0) {
525 printk(KERN_WARNING "Warning: Core image elf
header is not"
526 "sane:%ld\n",elfcorehdr_addr);
527 return -EINVAL
528 }

If I comment this return at line 527, then the code flows through and the
vmcore is getting generated.

However, I am facing a new issue, my user space is 32 bit and the kernel
is 64 bit. And I want to access the high memory (high_memory -
BACK_UP_SIZE) area of the previous/primary kernel. Where some log data I
had saved. The toral RAM is 8GB.

As the 32 bit pointers could not reach there... means simple file
operations lseek() , read etc are not working.. to access some region
around 8GB.

Can you please suggest me some way to reach that memory and read my raw
data from the user space.

I am able to read the data from kernel space( a simple kernel module via
/proc interface to transfer the data from kernel to user space using
physical address of the primary kernel).



Chandan Kumar
TCS Mumbai




Chandan12 K <chandan12.k at tcs.com>
Sent by: kexec-bounces at lists.infradead.org
08/13/2009 03:40 PM

To
kexec at lists.infradead.org
cc

Subject
vmcore file 0 size in x86_64







Hi,

Adding boot logs

NET: Registered protocol family 1
audit: initializing netlink socket (disabled)
type=2000 audit(1250069944.104:1): initialized
VFS: Disk quotas dquot_6.5.1
Dquot-cache hash table entries: 512 (order 0, 4096 bytes)
Warning: Core image elf header is notsane
Kdump: vmcore not initialized
Registering unionfs 2.2-mm
msgmni has been set to 90
io scheduler noop registered
io scheduler anticipatory registered


however, similar case has already been discussed in other mailing lists
with vivek. The only difference is that, I am not using redhat system and
dont have any user level kexel tools.

https://lists.linux-foundation.org/pipermail/fastboot/2007-January/012572.html


The kernel command line of capture kernel (kexe'ed kernel) : Kernel
command line: root=/dev/nfs rw console=ttyS0,115200 ip=::::::dhcp
selinux=0 noacpi maxcpus=1 memmap=exactmap memmap=640K at 0K
memmap=64876K at 16384K elfcorehdr=81260K


Command line for the Primary kernel : root=/dev/nfs rw
console=ttyS0,115200 ip=::::::dhcp crashkernel=64M at 16M

kexec command used : kexec -p bzImage --append="root=/dev/nfs rw
console=ttyS0,115200 ip=::::::dhcp selinux=0 noacpi maxcpus=1"

Kconfig options :

CONFIG_CRASH_DUMP=y
CONFIG_PHYSICAL_START=0x200000
CONFIG_RELOCATABLE=y
CONFIG_PHYSICAL_ALIGN=0x200000

Please suggest.


Chandan


Dave Anderson <anderson at redhat.com>
Sent by: crash-utility-bounces at redhat.com
08/12/2009 07:39 PM

Please respond to
"Discussion list for crash utility usage, maintenance and
development" <crash-utility at redhat.com>



To
"Discussion list for crash utility usage, maintenance and
development" <crash-utility at redhat.com>
cc

Subject
Re: [Crash-utility] vmcore file size 0 on x86_64











Forwarded to kexec list:

http://lists.infradead.org/pipermail/kexec/2009-August/003474.html
Hi,
I am little new in this mailing list. I just wondered if anybody could
help me regarding the vmcore file generation. I ran kexec on my x86_64
machine, and the /proc/vmcore file is created with zero size.
However, even if I read the /dev/oldmem file, I am only able to read
till 16M. I guess I am only able to read till the 'X', where X is
crashkernel=Y at X.
Moreover, My machine seems to have 32 bit user space and ofcourse, 64
bit kernel space.
Appreciate any response.
Chandan Kumar
____________________________________________ =====-----=====-----=====
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
--
Crash-utility mailing list
Crash-utility at redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility
--
Crash-utility mailing list
Crash-utility at redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility

ForwardSourceID:NT0000987A
=====-----=====-----=====
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


_______________________________________________
kexec mailing list
kexec at lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

ForwardSourceID:NT000098BE

Chandan Kumar
TCS Mumbai
=====-----=====-----=====
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


_______________________________________________
kexec mailing list
kexec at lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

ForwardSourceID:NT0000994A
=====-----=====-----=====
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


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.linux-foundation.org/pipermail/fastboot/attachments/20090813/0b63e5f3/attachment-0001.htm
Eric W. Biederman
2009-08-13 20:39:06 UTC
Permalink
Hi,
I checked.. through and fond out that one of the following check condition is
failing
516 if (memcmp(ehdr.e_ident, ELFMAG, SELFMAG) != 0 ||
517 (ehdr.e_type != ET_CORE) ||
518 !vmcore_elf_check_arch(&ehdr) ||
519 ehdr.e_ident[EI_CLASS] != ELFCLASS64 ||
520 ehdr.e_ident[EI_VERSION] != EV_CURRENT ||
521 ehdr.e_version != EV_CURRENT ||
522 ehdr.e_ehsize != sizeof(Elf64_Ehdr) ||
523 ehdr.e_phentsize != sizeof(Elf64_Phdr) ||
524 ehdr.e_phnum == 0) {
525 printk(KERN_WARNING "Warning: Core image elf header is
not"
526 "sane:%ld\n",elfcorehdr_addr);
527 return -EINVAL
528 }
If I comment this return at line 527, then the code flows through and the
vmcore is getting generated.
However, I am facing a new issue, my user space is 32 bit and the kernel is 64
bit. And I want to access the high memory (high_memory - BACK_UP_SIZE) area of
the previous/primary kernel. Where some log data I had saved. The toral RAM is
8GB.
As the 32 bit pointers could not reach there... means simple file operations
lseek() , read etc are not working.. to access some region around 8GB.
Can you please suggest me some way to reach that memory and read my raw data
from the user space.
I am able to read the data from kernel space( a simple kernel module via /proc
interface to transfer the data from kernel to user space using physical address
of the primary kernel).
Typically in user space that can be solved in a 32bit userspace
with FILE_OFFSET=64 or something like that.

There are 32bit syscalls that accept 64bit offsets to files.

Eric
Ken'ichi Ohmichi
2009-08-17 06:27:48 UTC
Permalink
Hi,
Post by Chandan12 K
I checked.. through and fond out that one of the following check condition
is failing
516 if (memcmp(ehdr.e_ident, ELFMAG, SELFMAG) != 0 ||
517 (ehdr.e_type != ET_CORE) ||
518 !vmcore_elf_check_arch(&ehdr) ||
519 ehdr.e_ident[EI_CLASS] != ELFCLASS64 ||
520 ehdr.e_ident[EI_VERSION] != EV_CURRENT ||
521 ehdr.e_version != EV_CURRENT ||
522 ehdr.e_ehsize != sizeof(Elf64_Ehdr) ||
523 ehdr.e_phentsize != sizeof(Elf64_Phdr) ||
524 ehdr.e_phnum == 0) {
525 printk(KERN_WARNING "Warning: Core image elf
header is not"
526 "sane:%ld\n",elfcorehdr_addr);
527 return -EINVAL
528 }
If I comment this return at line 527, then the code flows through and the
vmcore is getting generated.
However, I am facing a new issue, my user space is 32 bit and the kernel
is 64 bit. And I want to access the high memory (high_memory -
BACK_UP_SIZE) area of the previous/primary kernel. Where some log data I
had saved. The toral RAM is 8GB.
As the 32 bit pointers could not reach there... means simple file
operations lseek() , read etc are not working.. to access some region
around 8GB.
Can you please suggest me some way to reach that memory and read my raw
data from the user space.
I am able to read the data from kernel space( a simple kernel module via
/proc interface to transfer the data from kernel to user space using
physical address of the primary kernel).
If compiling your user space program with tree options
(-D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE),
it can access the high memory.


Thanks
Ken'ichi Ohmichi

Loading...