5:12 a.m.
Hi Dave,
When parsing vmcore generated by ARM linux, Crash utility does
"phys to pfn" converting using this:
" (paddr - machdep->machspec->phys_base) >> dd->block_shift;"
First it minuses offset of the memory, and then does right shift.
But I glanced over kernel codes(2.6.34 - 3.15). I found nothing
to support the rationality of this type converting for ARM linux.
And without this patch, the crash utility can not parse my vmcores.
Also I can not get the commit messages because this code added before
crash-7.0.4. So, What's your purpose to introduce this? Is this patch
necessary for crash utility ? Or should I do some addtional work for
compatibility?
(BTW,makedumpfile also has this type problem.)
Thanks,
Liu Hua
Signed-off-by: Liu Hua <sdu.liu(a)huawei.com>
---
diskdump.c | 8 --------
1 file changed, 8 deletions(-)
diff --git a/diskdump.c b/diskdump.c
index e230c1f..1d72364 100644
--- a/diskdump.c
+++ b/diskdump.c
@@ -914,15 +914,7 @@ page_is_cached(physaddr_t paddr)
static ulong
paddr_to_pfn(physaddr_t paddr)
{
-#ifdef ARM
- /*
- * In ARM, PFN 0 means first page in kernel direct-mapped view.
- * This is also first page in mem_map as well.
- */
- return (paddr - machdep->machspec->phys_base) >> dd->block_shift;
-#else
return paddr >> dd->block_shift;
-#endif
}
/*
--
1.9.0
10:36 a.m.
----- Original Message -----
Hi Dave,
When parsing vmcore generated by ARM linux, Crash utility does
"phys to pfn" converting using this:
" (paddr - machdep->machspec->phys_base) >> dd->block_shift;"
First it minuses offset of the memory, and then does right shift.
But I glanced over kernel codes(2.6.34 - 3.15). I found nothing
to support the rationality of this type converting for ARM linux.
And without this patch, the crash utility can not parse my vmcores.
Also I can not get the commit messages because this code added before
crash-7.0.4. So, What's your purpose to introduce this? Is this patch
necessary for crash utility ? Or should I do some addtional work for
compatibility?
(BTW,makedumpfile also has this type problem.)
It's been that way since support for 32-bit ARM was first put in place
almost four years ago:
revision 1.26
date: 2010/08/27 17:25:07; author: anderson; state: Exp; lines: +39 -3
Introduction of ARM processor support for the crash utility. This is
the result of collaborative effort between Nokia and Sony Ericsson.
The crash utility can be built as a native ARM binary to analyze ARM
dumpfiles or run live on an ARM host, or alternatively it can be
built as an x86 binary to analyze ARM dumpfiles. To build crash as
an ARM binary on an ARM host, enter "make" alone. To build crash as
an x86 binary on an x86 host, enter "make target=ARM". By extension,
the x86 binary can also be run on an x86_64 host. It supports kdump,
and diskdump formats, and live using /dev/mem on ARM hosts. Stack
unwinding support uses both frame pointers and ARM unwind tables.
(ext-mika.1.westerberg(a)nokia.com, Jan.Karlsson(a)sonyericsson.com,
Thomas.Fange(a)sonyericsson.com)
And released in crash-5.0.7:
http://people.redhat.com/anderson/crash.changelog.html#5_0_7
I have 3 sample compressed kdump ARM vmcores, all of which have
are more recent than 2.6.34 and all of which have non-zero
phys_base values that must be accounted for:
RELEASE: 2.6.35-rc3-00272-gd189df4
phys_base: 80000000
RELEASE: 2.6.38-rc2-00274-g1f0324c-dirty
phys_base: 80000000
RELEASE: 3.1.1
phys_base: c0000000
So obviously your patch is applied, they all fail to initialize, and
it's unclear why your implementation would be different.
I should note that support for 32-bit ARM was originally performed
by the 3 authors above, and ongoing support has been done by them
as well as several other key contributors on this mailing list.
Dave
Thanks,
Liu Hua
Signed-off-by: Liu Hua <sdu.liu(a)huawei.com>
---
diskdump.c | 8 --------
1 file changed, 8 deletions(-)
diff --git a/diskdump.c b/diskdump.c
index e230c1f..1d72364 100644
--- a/diskdump.c
+++ b/diskdump.c
@@ -914,15 +914,7 @@ page_is_cached(physaddr_t paddr)
static ulong
paddr_to_pfn(physaddr_t paddr)
{
-#ifdef ARM
- /*
- * In ARM, PFN 0 means first page in kernel direct-mapped view.
- * This is also first page in mem_map as well.
- */
- return (paddr - machdep->machspec->phys_base) >>
dd->block_shift;
-#else
return paddr >> dd->block_shift;
-#endif
}
/*
--
1.9.0
3863
days inactive
3863
days old
devel@lists.crash-utility.osci.io
1 comments
2 participants
participants (2)
-
Dave Anderson -
Liu Hua