On Wed, Oct 09, 2019 at 09:03:25AM -0400, Dave Anderson wrote:
>
>
> - Original Message -
> > On Tue, Oct 08, 2019 at 04:55:48PM -0400, Dave Anderson wrote:
> > >
> > > > - Original Message -
> > > > > Hi Dave,
> > > > >
> > > > > I tried to use crash v7.2.7 with kernel v5.4-rc1
On Tue, Oct 08, 2019 at 04:55:48PM -0400, Dave Anderson wrote:
>
> > - Original Message -
> > > Hi Dave,
> > >
> > > I tried to use crash v7.2.7 with kernel v5.4-rc1 on arm64.
> > >
> > > 1. VA_BITS_ACTUAL is missing in vmcoreinfo.
> > >Does anyone work on fixing it on kernel side?
>
Hi Bhupesh,
On Thu, Oct 03, 2019 at 11:25:25AM +0530, Bhupesh Sharma wrote:
> Hi Akashi,
>
> On Thu, Oct 3, 2019 at 10:49 AM AKASHI Takahiro
> wrote:
> >
> > Hi Dave,
> >
> > I tried to use crash v7.2.7 with kernel v5.4-rc1 on arm64.
> >
>
Hi Dave,
I tried to use crash v7.2.7 with kernel v5.4-rc1 on arm64.
1. VA_BITS_ACTUAL is missing in vmcoreinfo.
Does anyone work on fixing it on kernel side?
(just adding one or two lines though)
2. With a tweak above, I still fail to run crash with vmcore
seeing the following errors;
ne to be before PAN")
[3] commit 4b65a5db3627 ("arm64: Introduce uaccess_{disable,enable}
functionality based on TTBR0_EL1")
Signed-off-by: AKASHI Takahiro
---
arm64.c | 16 ++--
1 file changed, 14 insertions(+), 2 deletions(-)
diff --git a/arm64.c b/arm64.c
index
004 SYSCALLNO: 16 PSTATE: 6000
> >
> > Dave
> >
> >
> >
> > - Original Message -----
> > > Dave,
> > >
> > > On Wed, Oct 18, 2017 at 02:12:17PM -0400, Dave Anderson wrote:
> > > >
> &
e that it's mostly the stacksize and stackframe
> related updates, but would it be possible for you to make a patch
> that can be applied to the github sources?
Here is what you requested. Pls check.
Thanks,
-Takahiro AKASHI
===8<===
>From 7b99a1c2e688ba81e18541c21a7d0fa70504e5bc M
t some sort of
clean-ups/readability improvements with deleting incomplete fixes
against "bt -o."
Thanks,
-Takahiro AKASHI
===8<===
>From 826147807e2f2e00155b41b8ab97d3083bb0e607 Mon Sep 17 00:00:00 2001
From: AKASHI Takahiro
Date: Thu, 12 Oct 2017 10:46:34 +0900
Subject: [
b
> > > >
> > > > Again, though, note that "bt" does not work with 4.14.
> > >
> > > Even with your latest changes in 7.2.0, "bt" still has some issues:
> > > a.register dump at exception frame doesn't have correct va
And please note that THREAD_SIZE, hence IRQ_STACK_SIZE,
is no longer constant since v4.14 due to KASAN and VMAP_STACK.
-Takahiro AKASHI
On Fri, Oct 13, 2017 at 05:29:12PM +0900, AKASHI Takahiro wrote:
> Dave,
>
> On Fri, Sep 22, 2017 at 03:06:00PM -0400, Dave Anderson wrote:
>
perfect, it may help give you a heads-up.
Thanks,
-Takahiro AKASHI
===8<===
>From 156ec115b2a436a0738908153d676f8eeed84cb1 Mon Sep 17 00:00:00 2001
From: AKASHI Takahiro
Date: Thu, 12 Oct 2017 10:46:34 +0900
Subject: [PATCH] arm64: backtrace for v4.14
---
arm64.c | 172 +++
On Fri, Apr 28, 2017 at 09:05:07AM -0400, Dave Anderson wrote:
>
> > Hello,
> >
> > Is there arm64 big endian support in crash utility? And when it appears?
> >
> > Best regards,
> > Denys
> >
>
> What happens when you rebuild the crash package from scratch on a
> big-endian arm64 host?
I ga
Since v4.10, arm64 kernel supports CONFIG_THREAD_INFO_IN_TASK.
This means that bt->tc->thread_info is no longer equal to the base
address of the task's stack.
This patch fixes this issue.
Signed-off-by: AKASHI Takahiro
---
arm64.c | 10 ++
1 file changed, 6 insertions(+),
On Tue, Oct 11, 2016 at 10:57:37AM +0900, AKASHI Takahiro wrote:
> Dave,
>
> On Fri, Oct 07, 2016 at 11:02:01AM -0400, Dave Anderson wrote:
> >
> > - Original Message -
> > > Dave,
> > >
> > > >
> > > > Now, thi
Signed-off-by: AKASHI Takahiro
---
arm64.c | 69 +
1 file changed, 69 insertions(+)
diff --git a/arm64.c b/arm64.c
index b9fa14d..8235e3c 100644
--- a/arm64.c
+++ b/arm64.c
@@ -2540,6 +2540,59 @@ arm64_is_task_addr(ulong task
Dave,
On Fri, Oct 07, 2016 at 11:02:01AM -0400, Dave Anderson wrote:
>
> - Original Message -
> > Dave,
> >
> > >
> > > Now, this sample patch doesn't deal with branch instructions other than
> > > "bl",
> > > so perhaps it could just check whether the last argument in the
> > > instr
Dave,
On Thu, Oct 06, 2016 at 04:35:42PM -0400, Dave Anderson wrote:
>
> Hi Akashi,
>
> I was playing around with this, and noted that if a module's debuginfo data
> is not
> loaded into a crash session with the "mod" command, branch instruction
> targets
> that are within the module space ar
such kind of indirect addressing
to a symbolic name at dis command?
(It may be difficult to discriminate PLT from normal branches, though).
Thanks,
-Takahiro AKASHI
> > Signed-off-by: AKASHI Takahiro
>
> Queued for crash-7.1.6:
>
>
> https://github.com/crash-utilit
: AKASHI Takahiro
---
symbols.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/symbols.c b/symbols.c
index 99c8b8b..a657ead 100644
--- a/symbols.c
+++ b/symbols.c
@@ -2251,10 +2251,11 @@ store_module_kallsyms_v2(struct load_module *lm, int
start, int curr
Dave,
My apologies for slow response since I was attending LinuxCon last week.
On Wed, Jul 13, 2016 at 04:49:31PM -0400, Dave Anderson wrote:
>
> Nakahiro,
>
> As I had last proposed, I have kept the original backtrace method in place,
> while making your redesigned method available as a bt op
On Wed, Jun 29, 2016 at 05:25:27PM -0400, Dave Anderson wrote:
>
>
> Hi Takahiro,
>
> Here is another thing that I would prefer not to change/omit.
>
> In the current code, the raw exception frame data is dumped as
> part of the "bt -[fF]" output, just prior to it being translated
> as an exce
; But please note that this change may also make people a bit confused
> > because a value of LR in the stack dump of "bt -f" doesn't match with
> > an address in one-line summary.
> >
> > #2 [cc7511407eb0] schedule at d628aee0
> > ffffcc75114
Dave,
If you don't like my patches, that is OK.
Applying them or not is totally up to you.
I will *never* submit my patches again.
Having said so, I think I would better explain my intentions on the code.
On Wed, Jun 29, 2016 at 04:09:01PM -0400, Dave Anderson wrote:
>
>
> Hi Takahiro,
>
> I
VHE-enabled system.
So the "subject" may be overstated.
Thanks,
-Takahiro AKASHI
> Dave
>
>
> - Original Message -
> > On VHE-enabled system, the kernel runs in EL2.
> >
> > Signed-off-by: AKASHI Takahiro
> > ---
> > arm64.c | 2 ++
>
ummary.
> >
> > #2 [cc7511407eb0] schedule at d628aee0
> > cc7511407eb0: cc6d22f23080 d5b44d6c <= LR
> > cc7511407ec0: cc7511407ed0
> > #3 [cc7511407ed0] work_resched at d5b44d68 <= c
n address in one-line summary.
#2 [cc7511407eb0] schedule at d628aee0
cc7511407eb0: cc6d22f23080 d5b44d6c <= LR
cc7511407ec0: cc7511407ed0
#3 [cc7511407ed0] work_resched at d5b44d68 <= correcrted PC
Signed-o
On VHE-enabled system, the kernel runs in EL2.
Signed-off-by: AKASHI Takahiro
---
arm64.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arm64.c b/arm64.c
index bad36aa..b9fa14d 100644
--- a/arm64.c
+++ b/arm64.c
@@ -1414,6 +1414,8 @@ arm64_is_kernel_exception_frame(struct bt_info *bt
Signed-off-by: AKASHI Takahiro
---
arm64.c | 546
defs.h | 6 +
2 files changed, 386 insertions(+), 166 deletions(-)
diff --git a/arm64.c b/arm64.c
index 06676d1..0ac5894 100644
--- a/arm64.c
+++ b/arm64.c
@@ -42,18 +42,18
tch[3/3]
applying this patch would be a discussion.
AKASHI Takahiro (4):
arm64: more improvement of bt -f
arm64: find a correct starting stackframe at bt
arm64: correct a PC shown in bt
arm64: add VHE support
arm64.c | 603
frame pointer should be sane for later use.
This patch adds some check.
Signed-off-by: AKASHI Takahiro
---
arm64.c | 32 +---
1 file changed, 21 insertions(+), 11 deletions(-)
diff --git a/arm64.c b/arm64.c
index 0ac5894..b74d2c4 100644
--- a/arm64.c
+++ b/arm64.c
@@ -1
On Wed, Jun 22, 2016 at 04:31:12PM -0400, Dave Anderson wrote:
>
> Hi Takahiro,
>
> BTW, in your next patch posting, can you possibly expound upon the diagram
> below?
>
> For example, I'm presuming that 'p', 'c' and 'n' mean previous, current and
> next?
> But I'm not sure about 'N', or what
On Wed, Jun 22, 2016 at 01:35:02PM +0900, AKASHI Takahiro wrote:
> Signed-off-by: AKASHI Takahiro
> ---
> arm64.c | 504
> +++-
> defs.h | 6 +
> 2 files changed, 344 insertions(+), 166 deletions(-)
>
> diff
>
> > [1] https://www.redhat.com/archives/crash-utility/2016-June/msg00040.html
> >
> > Thanks,
> > -Takahiro AKASHI
>
> Takahiro,
>
> I hope to be able to take a look at this tomorrow, but upon an initial
> compile,
> there's an error at li
but fp still points to IRQ stack.
* add patch[2/3]
This should be applied even withtout patch[1/3]
* add patch[3/3]
applying this patch would be a discussion.
AKASHI Takahiro (3):
arm64: more improvement of bt -f
arm64: find a correct starting stackframe at bt
arm64: correct a PC shown i
later use.
This patch adds some check.
Signed-off-by: AKASHI Takahiro
---
arm64.c | 32 +---
1 file changed, 21 insertions(+), 11 deletions(-)
diff --git a/arm64.c b/arm64.c
index 4f85772..5327370 100644
--- a/arm64.c
+++ b/arm64.c
@@ -1893,9 +1893,9
n address in one-line summary.
#2 [cc7511407eb0] schedule at d628aee0
cc7511407eb0: cc6d22f23080 d5b44d6c <= LR
cc7511407ec0: cc7511407ed0
#3 [cc7511407ed0] work_resched at d5b44d68 <= correcrted PC
Signed-o
Signed-off-by: AKASHI Takahiro
---
arm64.c | 504 +++-
defs.h | 6 +
2 files changed, 344 insertions(+), 166 deletions(-)
diff --git a/arm64.c b/arm64.c
index 06676d1..4f85772 100644
--- a/arm64.c
+++ b/arm64.c
@@ -42,18 +42,18
Sep 17 00:00:00 2001
From: AKASHI Takahiro
Date: Thu, 16 Jun 2016 09:29:52 +0900
Subject: [PATCH v3] arm64: more improvement of bt -f
Signed-off-by: AKASHI Takahiro
---
arm64.c | 486 +++-
defs.h | 6 +
2 files changed, 337 inse
On Tue, Jun 14, 2016 at 10:08:25AM -0400, Dave Anderson wrote:
>
> > Dave,
> >
> > On Mon, Jun 13, 2016 at 04:06:22PM -0400, Dave Anderson wrote:
> > >
> > >
> > > - Original Message -
> > > > In my next version of kdump patch, the following VMCOREINFO will be
> > > > added:
> > > >
On Tue, Jun 14, 2016 at 10:42:03AM -0400, Dave Anderson wrote:
>
> > On Mon, Jun 13, 2016 at 11:30:24AM -0400, Dave Anderson wrote:
> > >
> > > > Dave,
> > > >
> > > > On Fri, Jun 10, 2016 at 04:37:42PM -0400, Dave Anderson wrote:
> > > > > Hi Takahiro,
> > > > >
> > > > > To address my concern
sage
> >
> > changes in v2:
> > * Fixed build warnings
> > * Moved ARM64_NEW_VMEMMAP to machdep->flags
> > * Show additional kaslr-related parameters in arm64_dump_machdep_table()
> > * Handle a VMCOREINFO, "NUMBER(kimage_voffset)"
> >
> > ==
On Tue, Jun 14, 2016 at 04:56:43PM -0400, Dave Wysochanski wrote:
> On Mon, 2016-06-13 at 11:30 -0400, Dave Anderson wrote:
> >
> > - Original Message -
> > > Dave,
> > >
> > > On Fri, Jun 10, 2016 at 04:37:42PM -0400, Dave Anderson wrote:
> > > > Hi Takahiro,
> > > >
> > > > To address
nfigured
> > * Fixed a renaming of a member of struct page
> > * Removed a commit message regarding an issue of backtracing a panic'ed task
> > because this is not a bug in this tool, but my kdump patch's.
> > * Reported "kmem " issue in a commit message
> >
> > change
On Mon, Jun 13, 2016 at 11:30:24AM -0400, Dave Anderson wrote:
>
> > Dave,
> >
> > On Fri, Jun 10, 2016 at 04:37:42PM -0400, Dave Anderson wrote:
> > > Hi Takahiro,
> > >
> > > To address my concerns about your patch, I added a few additional changes
> > > and attached
> > > it to this email.
Pratyush,
On Mon, Jun 13, 2016 at 02:33:22PM +0530, Pratyush Anand wrote:
> Hi Takahiro,
>
> On 13/06/2016:05:10:08 PM, AKASHI Takahiro wrote:
> > In my next version of kdump patch, the following VMCOREINFO will be
> > added:
> > NUMBER(VA_BITS)
> > NUMB
age
changes in v2:
* Fixed build warnings
* Moved ARM64_NEW_VMEMMAP to machdep->flags
* Show additional kaslr-related parameters in arm64_dump_machdep_table()
* Handle a VMCOREINFO, "NUMBER(kimage_voffset)"
==8<==
>From 666cdf305aa246ce6b30282d8e89e950dc828f70 Mon Sep 17
a live system if CONFIG_RANDOMIZE_RAM is
> > not configured
> > * Fixed a renaming of a member of struct page
> > * Removed a commit message regarding an issue of backtracing a panic'ed task
> > because this is not a bug in this tool, but my kdump patch's.
>
ep_table()
* Handle a VMCOREINFO, "NUMBER(kimage_voffset)"
==8<==
>From a6dd9d73120dcc3f2d68dbe9a8f2d16a128c4002 Mon Sep 17 00:00:00 2001
From: AKASHI Takahiro
Date: Mon, 16 May 2016 17:31:55 +0900
Subject: [PATCH v5] arm64: fix kernel memory map handling for kaslr-enabled
ke
<==
>From d8683645599a238578a0f586af563bc9f847d52c Mon Sep 17 00:00:00 2001
From: AKASHI Takahiro
Date: Wed, 8 Jun 2016 11:14:22 +0900
Subject: [PATCH v2] arm64: dump a stack frame based on fp
Signed-off-by: AKASHI Takahiro
---
arm64.c
Dave,
On Fri, Jun 10, 2016 at 04:37:42PM -0400, Dave Anderson wrote:
> Hi Takahiro,
>
> To address my concerns about your patch, I added a few additional changes and
> attached
> it to this email. The changes are:
>
> (1) Prevent the stack dump "below" the #0 level. Yes, the stack data region
80815f8
#2 [800022f6b020] gic_handle_irq at 080815f8
800022f6b020: 0003 1fff
800022f6b030: 800020107ed0 08e60c54
800022f6b040: 800022f6b080 08084c4c
=== END ===
(*) append_elf_note()
Thanks,
-Takahiro AKASHI
==8<=
On Tue, Jun 07, 2016 at 03:01:49PM -0400, Dave Anderson wrote:
>
> And a fix for the phantom exception frame issue has been checked in:
>
>
> https://github.com/crash-utility/crash/commit/14b3eadfd8cfafa19115c06aa4e52a8d23f823cf
>
> Fix for the ARM64 "bt" command in Linux 4.5 and later kern
On Tue, Jun 07, 2016 at 03:50:12PM -0400, Dave Anderson wrote:
>
> - Original Message -
> >
> >
> > - Original Message -
> > > On Wed, Jun 01, 2016 at 10:32:56AM -0400, Dave Anderson wrote:
> > > >
> > > > - Original Message -
> > > > > On Tue, May 31, 2016 at 03:30:44PM
On Thu, Jun 02, 2016 at 10:52:28AM -0400, Dave Anderson wrote:
>
> - Original Message -
> > Dave,
> >
> > When I ran "bt" against a process running in a user mode, I got
> > an odd backtrace result:
> > ===8<===
> > crash> ps
> >...
> > > 1324 1223 2 80002018be80 RU 0.0
On Thu, Jun 02, 2016 at 11:37:24AM -0400, Dave Anderson wrote:
> - Original Message -
> > On Wed, Jun 01, 2016 at 11:41:04AM -0400, Dave Anderson wrote:
> > >
> > > - Original Message -
> > >
> > > > > >
> > > > > > case PRE_GDB:
> > > > > > + /* This check is some
Dave,
When I ran "bt" against a process running in a user mode, I got
an odd backtrace result:
===8<===
crash> ps
...
> 1324 1223 2 80002018be80 RU 0.0 960468 dhry
1325 2 1 800021089900 IN 0.0 0 0 [kworker/u16:0]
crash> bt 1324
PID: 1324 TAS
On Wed, Jun 01, 2016 at 11:41:04AM -0400, Dave Anderson wrote:
>
> - Original Message -
>
> > > >
> > > > case PRE_GDB:
> > > > + /* This check is somewhat redundant */
> > > > + if (kernel_symbol_exists("kimage_voffset"))
> > > > +
On Wed, Jun 01, 2016 at 10:32:56AM -0400, Dave Anderson wrote:
>
> - Original Message -
> > On Tue, May 31, 2016 at 03:30:44PM -0400, Dave Anderson wrote:
> > >
> > > This patch looks good -- if it wasn't layered on top of the KASLR patch,
> > > I would check it into github.
> >
> > This
pre-NEW_VMEMMAP kernels now that
> the VA_BITS calculation has been fixed.
>
> >
> > * For a core dump file, we can do simply:
> >$ crash
> > as long as the file has "NUMBER(kimage_voffset)"
> >
is conflicting.
When you merge it, please make a change.
-Takahiro AKASHI
> Thanks,
> Dave
>
>
> - Original Message -----
> > From: AKASHI Takahiro
> >
> > Signed-off-by: AKASHI Takahiro
> > ---
> > arm64.c | 120
> > +++
ool, but my kdump patch's.
* Reported "kmem " issue in a commit message
changes in v2:
* Fixed build warnings
* Moved ARM64_NEW_VMEMMAP to machdep->flags
* Show additional kaslr-related parameters in arm64_dump_machdep_table()
* Handle a VMCOREINFO, "NUMBER(kimage_voffset)"
t my kdump patch's.
> > * Reported "kmem " issue in a commit message
> >
> > changes in v2:
> > * Fixed build warnings
> > * Moved ARM64_NEW_VMEMMAP to machdep->flags
> > * Show additional kaslr-related parameters in arm64_dump_machdep_table()
&
ically set.)
I'm planning to add this enhancement in my next version of kexec/kdump
patch, i.e. v17.
Signed-off-by: AKASHI Takahiro
---
arm64.c | 218 --
defs.h| 24 +--
main.c| 7 +-
symbols.c | 12 ++--
4 fil
From: AKASHI Takahiro
Signed-off-by: AKASHI Takahiro
---
arm64.c | 120
defs.h | 25 +-
2 files changed, 137 insertions(+), 8 deletions(-)
diff --git a/arm64.c b/arm64.c
index c16ea67..b6bfbf3 100644
--- a/arm64.c
On arm64, the kernel with 4KB page size supports 39-bit or 48-bit addresses
for user and kernel space. The former uses 3-level of translation tables,
while the latter 4-level.
This patch is a reminder for the future task that we should add 4-level
translation support.
Signed-off-by: AKASHI
e a VMCOREINFO, "NUMBER(kimage_voffset)"
AKASHI Takahiro (3):
arm64: fix kernel memory map handling for kaslr-enabled kernel
fix a renaming of a member of struct page, _count to _refcount
arm64: show a warning for 48-bit kernel with 4KB page
arm64.c | 219 +
(8000 is 1st of 8 pages)
kmem: invalid structure member offset: page_count
FILE: memory.c LINE: 5503 FUNCTION: dump_mem_map_SPARSEMEM()
Signed-off-by: AKASHI Takahiro
---
memory.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/memory.c b/memory.c
i
0
VMAP_AREA VM_STRUCT ADDRESS RANGESIZE
ffd3a0020c00 ffd3a0020b80 0840 - 0861 2162688
2f100000: physical address not found in mem map
Signed-off-by: AKASHI Takahiro
---
arm64.c | 217 ++
On Fri, May 27, 2016 at 10:37:38AM +0530, Pratyush Anand wrote:
> On 27/05/2016:01:03:56 PM, AKASHI Takahiro wrote:
> > On Thu, May 26, 2016 at 03:09:55PM +0530, Pratyush Anand wrote:
> > > On 26/05/2016:05:13:30 PM, AKASHI Takahiro wrote:
> > > > On Wed, May 25,
On Fri, May 27, 2016 at 09:46:10AM +0530, Pratyush Anand wrote:
> On 27/05/2016:12:18:56 PM, AKASHI Takahiro wrote:
> > On Thu, May 26, 2016 at 01:27:08PM +0530, Pratyush Anand wrote:
> > > On 26/05/2016:04:04:08 PM, AKASHI Takahiro wrote:
> > > > Pratyush,
> >
On Wed, May 25, 2016 at 09:29:27AM -0400, Dave Anderson wrote:
>
>
> - Original Message -
> > On Tue, May 24, 2016 at 09:35:54AM -0400, Dave Anderson wrote:
> > >
> > >
> > > - Original Message -
> > > > > >
> > > > > > Now that PHYS_OFFSET is defined as "memstart_addr", we ca
On Thu, May 26, 2016 at 03:09:55PM +0530, Pratyush Anand wrote:
> On 26/05/2016:05:13:30 PM, AKASHI Takahiro wrote:
> > On Wed, May 25, 2016 at 10:28:10AM -0400, Dave Anderson wrote:
>
> [...]
>
> > > > (This is the reason that I don't think we need a VMCOREINF
On Thu, May 26, 2016 at 01:27:08PM +0530, Pratyush Anand wrote:
> On 26/05/2016:04:04:08 PM, AKASHI Takahiro wrote:
> > Pratyush,
> >
> > Just for debug purpose.
> > Please add the following line to *your* arch_crash_save_vmcoreinfo():
> > > vmcoreinfo_appen
On Wed, May 25, 2016 at 11:44:23AM -0400, Dave Anderson wrote:
>
> - Original Message -
> > >
> > > Are you using a mainline kernel (final v4.6, not -rcX)?
> >
> > Good point. When I configured my arm64 test system, I installed the latest
> > Fedora kernel available at the time (4.6.0-0
t usable memory block in SYSTEM RAM due to the fact mentioned
> > > > above.
> > > >
> > > > This patch addresses this change and allows the crash utility to access
> > > > memory contents with correct addresses.
> > > > *However*, it is
Pratyush,
Just for debug purpose.
Please add the following line to *your* arch_crash_save_vmcoreinfo():
> vmcoreinfo_append_str("NUMBER(kimage_voffset)=%llx\n", kimage_voffset);
I will add this to my next kdump patch.
Thanks,
-Takahiro AKASHI
On Thu, May 26, 2016 at 10:58:24AM +0530, Pratyush
fdfee0c0 4300 1
> 4400 reserved
> crash>
>
> And "kmem" alone recognizes it:
>
> crash> kmem fdfee000
> PAGE PHYSICAL MAPPING INDEX CNT FLAGS
> f
On Tue, May 24, 2016 at 09:35:54AM -0400, Dave Anderson wrote:
>
>
> - Original Message -
> > > >
> > > > Now that PHYS_OFFSET is defined as "memstart_addr", we can get the
> > > > value
> > > > if we can access this symbol (on a live system).
> > >
> > > When PHYS_OFFSET/memstart_add
fe27e391 Mon Sep 17 00:00:00 2001
From: AKASHI Takahiro
Date: Mon, 16 May 2016 17:31:55 +0900
Subject: [PATCH v2] arm64: fix kernel memory map handling for kaslr-enabled
kernel
In kernel v4.6, Kernel ASLR (KASLR) is supported on arm64, and the start
address of the kernel image c
t; > any comments are very welcome.
> > > > I will try to fix the known issues before I submit a new
> > > > version of kexec/kdump patch for v4.7 merge window.
> > > >
> > > > Thanks,
> > > > -Takahiro AKASHI
> > > >
> > > &
> > I will try to fix the known issues before I submit a new
> > version of kexec/kdump patch for v4.7 merge window.
> >
> > Thanks,
> > -Takahiro AKASHI
> >
> > ===8<===
> > >From fdc7c881d98ef00ed1ff38a058b4913a1d5bcda6 Mon Sep 17 00:00:00 2001
&
Sep 17 00:00:00 2001
From: AKASHI Takahiro
Date: Mon, 16 May 2016 17:31:55 +0900
Subject: [PATCH v1] arm64: fix kernel memory map handling for kaslr-enabled
kernel
In kernel v4.6, Kernel ASLR (KASLR) is supported on arm64, and the start
address of the kernel image can be randomi
82 matches
Mail list logo