From: ebiederm@xmission.com (Eric W. Biederman)
To: Chandan12 K <chandan12.k@tcs.com>
Cc: kexec-bounces@lists.infradead.org,
fastboot@lists.linux-foundation.org, kexec@lists.infradead.org
Subject: Re: vmcore file 0 size in x86_64
Date: Thu, 13 Aug 2009 13:39:06 -0700 [thread overview]
Message-ID: <m1eirf30ut.fsf@fess.ebiederm.org> (raw)
In-Reply-To: <OF8B20E4B3.38CCED3C-ON65257611.003DC8CE-65257611.00461ED3@tcs.com> (Chandan's message of "Thu\, 13 Aug 2009 18\:15\:54 +0530")
Chandan12 K <chandan12.k@tcs.com> writes:
> 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
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
next prev parent reply other threads:[~2009-08-13 20:39 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-08-13 10:10 vmcore file 0 size in x86_64 Chandan12 K
2009-08-13 12:45 ` Chandan12 K
2009-08-13 20:39 ` Eric W. Biederman [this message]
2009-08-17 6:27 ` Ken'ichi Ohmichi
2009-08-18 5:50 ` Bernhard Walle
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=m1eirf30ut.fsf@fess.ebiederm.org \
--to=ebiederm@xmission.com \
--cc=chandan12.k@tcs.com \
--cc=fastboot@lists.linux-foundation.org \
--cc=kexec-bounces@lists.infradead.org \
--cc=kexec@lists.infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox