Queued for crash-7.2.1:
https://github.com/crash-utility/crash/commit/090bf28907782549ba980c588979372061764aa7
When 4.14 gets released and some dumpfiles start showing up, the pt_regs
raw stack dump issue can be revisited.
Thanks,
Dave
- Original Message -
>
>
> - Origina
- Original Message -
> Dave,
>
> Thanks for your double-check,
>
> On Thu, Oct 19, 2017 at 01:55:11PM -0400, Dave Anderson wrote:
> >
> >
> > - Original Message -
> > >
> > > Hi Takahiro,
> > >
> > > I haven't had a chance to investigate why it fails, but with this latest
>
Dave,
Thanks for your double-check,
On Thu, Oct 19, 2017 at 01:55:11PM -0400, Dave Anderson wrote:
>
>
> - Original Message -
> >
> > Hi Takahiro,
> >
> > I haven't had a chance to investigate why it fails, but with this latest
> > patch applied, the "bt -[fF]" option fails to show th
- Original Message -
>
> Hi Takahiro,
>
> I haven't had a chance to investigate why it fails, but with this latest
> patch applied, the "bt -[fF]" option fails to show the topmost frame dump
> for *all* user-space tasks.
By *all* user-space tasks, I mean in pre-4.14 dumpfiles. I don'
Hi Takahiro,
I haven't had a chance to investigate why it fails, but with this latest
patch applied, the "bt -[fF]" option fails to show the topmost frame dump
for *all* user-space tasks. For example, here frame #6 is missing its
dump:
crash> bt -f 1
PID: 1 TASK: ffc3e889 CP
Dave,
On Wed, Oct 18, 2017 at 02:12:17PM -0400, Dave Anderson wrote:
>
>
> - Original Message -
> > On Tue, Oct 17, 2017 at 03:44:36PM -0400, Dave Anderson wrote:
> > >
> > > Thanks Takahiro, much appreciated. Queued for crash-7.2.1:
> > >
> > >
> > > https://github.com/crash-util
- Original Message -
> On Tue, Oct 17, 2017 at 03:44:36PM -0400, Dave Anderson wrote:
> >
> > Thanks Takahiro, much appreciated. Queued for crash-7.2.1:
> >
> >
> > https://github.com/crash-utility/crash/commit/2b93c036edf2a5cc21a06a14f377cd9b365f858a
>
> Oops, I've made small cha
On Tue, Oct 17, 2017 at 03:44:36PM -0400, Dave Anderson wrote:
>
> Thanks Takahiro, much appreciated. Queued for crash-7.2.1:
>
>
> https://github.com/crash-utility/crash/commit/2b93c036edf2a5cc21a06a14f377cd9b365f858a
Oops, I've made small changes, nothing essential but some sort of
clean-
Thanks Takahiro, much appreciated. Queued for crash-7.2.1:
https://github.com/crash-utility/crash/commit/2b93c036edf2a5cc21a06a14f377cd9b365f858a
Dave
- Original Message -
> On Mon, Oct 16, 2017 at 03:33:45PM -0400, Dave Anderson wrote:
> >
> > Hi Takahiro,
> >
> > One question
On Mon, Oct 16, 2017 at 03:33:45PM -0400, Dave Anderson wrote:
>
> Hi Takahiro,
>
> One question about a segment of your patch that I can't test because
> I don't have a 4.14 dumpfile. Here in arm64_switch_stack(), you have
> conditionalized the display of the exception frame:
>
> @@ -2669,7 +2
Hi Takahiro,
One question about a segment of your patch that I can't test because
I don't have a 4.14 dumpfile. Here in arm64_switch_stack(), you have
conditionalized the display of the exception frame:
@@ -2669,7 +2753,9 @@ arm64_switch_stack(struct bt_info *bt, struct
arm64_stackframe *frame
Hi Takahiro,
Welcome back! It's great to get you back in the fold again...
I just ran a quick test of your patch on a set of sample dumpfiles,
and only found one issue. It was on a 4.2 QEMU dump where all of the
active tasks were running in user-space, and all of their "bt" commands
fail imme
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:
> >
> > Jan,
> >
>
Dave,
On Fri, Sep 22, 2017 at 03:06:00PM -0400, Dave Anderson wrote:
>
> Jan,
>
> I went back to creating a machdep->machspec->user_eframe_offset value
> to be able to account for both the 4.7 and the upcoming 4.14 pt_regs
> changes:
>
>
> https://github.com/crash-utility/crash/commit/c97500
Jan,
I went back to creating a machdep->machspec->user_eframe_offset value
to be able to account for both the 4.7 and the upcoming 4.14 pt_regs
changes:
https://github.com/crash-utility/crash/commit/c975008e61121ef8785622c3bc26964da8fe0deb
Again, though, note that "bt" does not work with 4.
- Original Message -
>
> - Original Message -
> > Ok. I have seen this change in the pt_regs struct before but did not connect
> > it to this problem. I see these new field in pt_regs in earlier kernel
> > versions than 4.7, but it is probably backports. It really does not matter
: Discussion list for crash utility usage, maintenance and development
Ämne: Re: [Crash-utility] Problem in bt for ARM64
On Thu, Sep 21, 2017 at 12:33 PM, Dave Anderson wrote:
>
>
> - Original Message -
> > Ok. I have seen this change in the pt_regs struct before but
On Thu, Sep 21, 2017 at 12:33 PM, Dave Anderson wrote:
>
>
> - Original Message -
> > Ok. I have seen this change in the pt_regs struct before but did not connect
> > it to this problem. I see these new field in pt_regs in earlier kernel
> > versions than 4.7, but it is probably backports.
- Original Message -
> Ok. I have seen this change in the pt_regs struct before but did not connect
> it to this problem. I see these new field in pt_regs in earlier kernel
> versions than 4.7, but it is probably backports. It really does not matter
> for the solution of the problem. The f
t; your patch does the same thing.
>
> Jan
>
>
> Från: crash-utility-boun...@redhat.com för
> Dave Anderson
> Skickat: den 21 september 2017 17:38
> Till: Discussion list for crash utility usage, maintenance and development
> Ämne: R
t.com för
Dave Anderson
Skickat: den 21 september 2017 17:38
Till: Discussion list for crash utility usage, maintenance and development
Ämne: Re: [Crash-utility] Problem in bt for ARM64
- Original Message -
>
>
> - Original Message -
> > Hi Dave
> >
> >
- Original Message -
>
>
> - Original Message -
> > Hi Dave
> >
> > I have experienced some problems in the bt command for ARM64. It seems that
> > the test in arm64_print_exception_frame in arm64.c if the task is running
> > in
> > 32 or 64-bit mode in userland does not work
- Original Message -
> Hi Dave
>
> I have experienced some problems in the bt command for ARM64. It seems that
> the test in arm64_print_exception_frame in arm64.c if the task is running in
> 32 or 64-bit mode in userland does not work. It "always" becomes 32-bit
> mode. Example:
>
> cr
Hi Dave
I have experienced some problems in the bt command for ARM64. It seems that the
test in arm64_print_exception_frame in arm64.c if the task is running in 32 or
64-bit mode in userland does not work. It "always" becomes 32-bit mode. Example:
crash> bt 1
PID: 1 TASK: ffe1f90f8000
24 matches
Mail list logo
