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
andle_irq at 080815f8
800022f6b020: 0003 1fff
800022f6b030: 800020107ed0 08e60c54
800022f6b040: 800022f6b080 08084c4c
=== END ===
(*) append_elf_note()
Thanks,
-Takahiro AKASHI
==8<======
>From b3ca69ace916a5c233ce9379
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
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
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
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
<==
>From d8683645599a238578a0f586af563bc9f847d52c Mon Sep 17 00:00:00 2001
From: AKASHI Takahiro <takahiro.aka...@linaro.org>
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 <takahiro.aka...@linaro.or
* Handle a VMCOREINFO, "NUMBER(kimage_voffset)"
==8<==
>From a6dd9d73120dcc3f2d68dbe9a8f2d16a128c4002 Mon Sep 17 00:00:00 2001
From: AKASHI Takahiro <takahiro.aka...@linaro.org>
Date: Mon, 16 May 2016 17:31:55 +0900
Subject: [PATCH v5] arm64: fix kernel memory map ha
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.
d 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
> >
> > changes in v2:
> > * Fixed bu
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
> 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<==
> >
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
es 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 00:00:00 2
From: AKASHI Takahiro <akax.h...@gmail.com>
Signed-off-by: AKASHI Takahiro <takahiro.aka...@linaro.org>
---
arm64.c | 120
defs.h | 25 +-
2 files changed, 137 insertions(+), 8 deletions(-)
diff --git
h'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
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)"
AKASHI T
T ADDRESS RANGESIZE
ffd3a0020c00 ffd3a0020b80 0840 - 0861 2162688
2f10: physical address not found in mem map
Signed-off-by: AKASHI Takahiro <takahiro.aka...@linaro.org>
---
arm64.c | 217 ++
00 (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 <takahiro.aka...@linaro.org>
---
memory.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(
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
nflicting.
When you merge it, please make a change.
-Takahiro AKASHI
> Thanks,
> Dave
>
>
> - Original Message -
> > From: AKASHI Takahiro <akax.h...@gmail.com>
> >
> > Signed-off-by: AKASHI Takahiro <tak
emory 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 still rough-edged and we need
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 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
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 VMCOREINFO for
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, 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.
> >
> >
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"))
> > > > +
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
-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)"
> > (RELOC_AUTO|KASLR is automatically s
till 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 in bt
arm
for later use.
This patch adds some check.
Signed-off-by: AKASHI Takahiro <takahiro.aka...@linaro.org>
---
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/a
ress in one-line summary.
#2 [cc7511407eb0] schedule at d628aee0
cc7511407eb0: cc6d22f23080 d5b44d6c <= LR
cc7511407ec0: cc7511407ed0
#3 [cc7511407ed0] work_resched at d5b44d68 <= correcrted PC
Signed-off-by: AKASHI
Signed-off-by: AKASHI Takahiro <takahiro.aka...@linaro.org>
---
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
On Wed, Jun 22, 2016 at 01:35:02PM +0900, AKASHI Takahiro wrote:
> Signed-off-by: AKASHI Takahiro <takahiro.aka...@linaro.org>
> ---
> arm64.c | 504
> +++-
> defs.h | 6 +
> 2 files changed, 344 inse
Sep 17 00:00:00 2001
From: AKASHI Takahiro <takahiro.aka...@linaro.org>
Date: Thu, 16 Jun 2016 09:29:52 +0900
Subject: [PATCH v3] arm64: more improvement of bt -f
Signed-off-by: AKASHI Takahiro <takahiro.aka...@linaro.org>
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 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
/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
defs.h |
pointer should be sane for later use.
This patch adds some check.
Signed-off-by: AKASHI Takahiro <takahiro.aka...@linaro.org>
---
arm64.c | 32 +---
1 file changed, 21 insertions(+), 11 deletions(-)
diff --git a/arm64.c b/arm64.c
index 0ac5894..b74d2c4 100644
--- a
Signed-off-by: AKASHI Takahiro <takahiro.aka...@linaro.org>
---
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
Sep 17 00:00:00 2001
From: AKASHI Takahiro <takahiro.aka...@linaro.org>
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 kern
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
> > > >
> >
fe27e391 Mon Sep 17 00:00:00 2001
From: AKASHI Takahiro <takahiro.aka...@linaro.org>
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
addres
00 1
> 4400 reserved
> crash>
>
> And "kmem" alone recognizes it:
>
> crash> kmem fdfee000
> PAGE PHYSICAL MAPPING INDEX CNT FLAGS
> fdfee000 40 fe03f
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
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
at I have noticed so
far
on 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 <takahiro.ak
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,
>
>
t 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
> > cc7511407eb0: fff
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
0x04d78f4b608c <testmod_exit+100>: br x16
=> branch to 0x0e0045055120
(= panic())
===>8===
Is there any method to resolve such kind of indirect addressing
to a symbolic name at dis command?
(It may be diffic
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
-by: AKASHI Takahiro <takahiro.aka...@linaro.org>
---
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 *l
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
> > >
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 <takahiro.aka...@linaro.org>
---
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 +2
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 <takahiro.aka...@linaro.org>
---
arm64.c | 10 ++
1 fil
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
gt; > 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 values
> > > (due to added stac
ect, it may help give you a heads-up.
Thanks,
-Takahiro AKASHI
===8<===
>From 156ec115b2a436a0738908153d676f8eeed84cb1 Mon Sep 17 00:00:00 2001
From: AKASHI Takahiro <takahiro.aka...@linaro.org>
Date: Thu, 12 Oct 2017 10:46:34 +0900
Subject: [PATCH] arm64: backtrace for v4.14
---
arm64
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:
>
e 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 <takahiro.aka...@linaro.org>
Date: Thu, 12 Oct 2017 10:
y 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 Mon Sep 17 00:00:00 2001
Fro
: 6000
> >
> > Dave
> >
> >
> >
> > - Original Message -
> > > Dave,
> > >
> > > On Wed, Oct 18, 2017 at 02:12:17PM -0400, Dave Anderson wrote:
> > > >
> > > >
> > > > - Original Message
ne to be before PAN")
[3] commit 4b65a5db3627 ("arm64: Introduce uaccess_{disable,enable}
functionality based on TTBR0_EL1")
Signed-off-by: AKASHI Takahiro <takahiro.aka...@linaro.org>
---
arm64.c | 16 ++--
1 file changed, 14 insertions(+), 2 deletions(-)
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
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 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;
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.
> >
>
71 matches
Mail list logo
