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
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 kernels which
are not configured with CONFIG_FUNCTION_GRAPH_TRACER. Without th
Hello Takahiro,
I went ahead and checked in a fix for the user-space backtrace issue here:
https://github.com/crash-utility/crash/commit/2d53b97a476e71bfd5e2054d64aacfc5fd895e30
Fix for the ARM64 "bt" command in Linux 4.5 and later kernels which
use per-cpu IRQ stacks. Without the pa
- Original Message -
> > But I'm not sure what happens when an arm64 IRQ exception occurs when
> > the task is running in user space. Does it lay an exception frame down on
> > the
> > process stack and then make the transition? (and therefore the user-space
> > frame
> > above is
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
- 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 960468 dhry
>1325 2 1 800021089900 IN 0.0 0
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
