2:35 a.m.
Hi Dave,
Current I am trying to make crash support display out function param and local value while
backtracing.
The idea for this patch is to mimic core dump support in gdb, teaching the crash to supply
the regset to the gdb, so that gdb could have full knowledge what is going on in the panic
point.
A few progress has been made, the first two frames could display out correctly, but while
it is going on to display out the third frame, it report fail as “Cannot access memory” to
the stack address.
While I use the rd command to access this range, and could correct pc value there.
With further check, I find it failed at value_fetch_lazy at gdb code.
Do you have any idea why gdb side couldn’t read the stack content?
The generated log as:
crash> bt
PID: 886 TASK: c54991a0 CPU: 0 COMMAND: "sh"
#0 sysrq_handle_crash (key=99) at drivers/tty/sysrq.c:132
No locals.
#1 0xc02da6dc in __handle_sysrq (key=99, check_mask=false) at drivers/tty/sysrq.c:522
op_p = 0xc06dbeb8
orig_log_level = 7
i = -1066549576
flags = 1610612755
Cannot access memory at address 0xd29d5f34
bt: display local fail at c02da1c0
crash> rd 0xd29d5f34 1
d29d5f34: c02da7cc ..-.
crash> sym c02da7cc
c02da7cc (t) write_sysrq_trigger+40 /kernel/drivers/tty/sysrq.c: 873
Thanks,
Lei
8:27 a.m.
----- Original Message -----
Hi Dave,
Current I am trying to make crash support display out function param
and local value while backtracing.
The idea for this patch is to mimic core dump support in gdb,
teaching the crash to supply the regset to the gdb, so that gdb
could have full knowledge what is going on in the panic point.
A few progress has been made, the first two frames could display out
correctly, but while it is going on to display out the third frame,
it report fail as “Cannot access memory” to the stack address.
While I use the rd command to access this range, and could correct pc
value there.
With further check, I find it failed at value_fetch_lazy at gdb code.
Do you have any idea why gdb side couldn’t read the stack content?
The generated log as:
crash> bt
PID: 886 TASK: c54991a0 CPU: 0 COMMAND: "sh"
#0 sysrq_handle_crash (key=99) at drivers/tty/sysrq.c:132
No locals.
#1 0xc02da6dc in __handle_sysrq (key=99, check_mask=false) at drivers/tty/sysrq.c:522
op_p = 0xc06dbeb8
orig_log_level = 7
i = -1066549576
flags = 1610612755
Cannot access memory at address 0xd29d5f34
bt: display local fail at c02da1c0
crash> rd 0xd29d5f34 1
d29d5f34: c02da7cc ..-.
crash> sym c02da7cc
c02da7cc (t) write_sysrq_trigger+40 /kernel/drivers/tty/sysrq.c: 873
Thanks,
Lei
Hello Lei,
When the embedded gdb needs to read kernel memory, its code path typically
ends up calling target_read_memory() in gdb-7.3.1/gdb/target.c, which has
been patched to redirect the read back up into the crash source code:
int
target_read_memory (CORE_ADDR memaddr, gdb_byte *myaddr, int len)
{
#ifdef CRASH_MERGE
extern int gdb_readmem_callback(unsigned long, void *, int, int);
if (gdb_readmem_callback(memaddr, (void *)myaddr, len, 0))
return 0;
else
return EIO;
#endif
/* Dispatch to the topmost target, not the flattened current_target.
Memory accesses check target->to_has_(all_)memory, and the
flattened target doesn't inherit those. */
if (target_read (current_target.beneath, TARGET_OBJECT_MEMORY, NULL,
myaddr, memaddr, len) == len)
return 0;
else
return EIO;
}
The gdb_readmem_callback() function is in the crash source file gdb_interface.c.
But since the read is failing, I'm guessing that it's trying to access the
memory from a different path, probably like this:
value_fetch_lazy()
read_value_memory()
and read_value_memory() looks like this:
void
read_value_memory (struct value *val, int embedded_offset,
int stack, CORE_ADDR memaddr,
gdb_byte *buffer, size_t length)
{
if (length)
{
VEC(mem_range_s) *available_memory;
if (get_traceframe_number () < 0
|| !traceframe_available_memory (&available_memory, memaddr, length))
{
if (stack)
read_stack (memaddr, buffer, length); <== this path has never been
used
else
read_memory (memaddr, buffer, length);
}
If read_memory() were called, then it would call the patched target_read_memory()
function above, and the read would work OK. But if read_stack() is called, it takes
a different path:
read_stack()
target_read_stack()
and target_read_stack() does not call target_read_memory(), but rather it
calls the similar function target_read_stack().
And it appears that target_read_stack() can be modified in the same way
that target_read_memory() has been, since they are essentially the same:
int
target_read_stack (CORE_ADDR memaddr, gdb_byte *myaddr, int len)
{
/* Dispatch to the topmost target, not the flattened current_target.
Memory accesses check target->to_has_(all_)memory, and the
flattened target doesn't inherit those. */
if (target_read (current_target.beneath, TARGET_OBJECT_STACK_MEMORY, NULL,
myaddr, memaddr, len) == len)
return 0;
else
return EIO;
}
So just try cut-and-pasting the same #ifdef CRASH_MERGE section into target_read_stack().
Dave
9:55 p.m.
Hello Lei,
And it appears that target_read_stack() can be modified in the same way
that target_read_memory() has been, since they are essentially the same:
int
target_read_stack (CORE_ADDR memaddr, gdb_byte *myaddr, int len)
{
}
So just try cut-and-pasting the same #ifdef CRASH_MERGE section into
target_read_stack().
Yep, it did solve my issue, now the backtrace would unwind happily to the next frame.
While I am trying to apply the similar logic to another thread instead of current panic
one, I find the gdb would directly complain for "<segmentation violation in
gdb> ". Haven't figure out what happened there...
Dave
Thanks,
Lei
7:54 a.m.
----- Original Message -----
> Hello Lei,
>
>
> And it appears that target_read_stack() can be modified in the same
> way
> that target_read_memory() has been, since they are essentially the
> same:
>
> int
> target_read_stack (CORE_ADDR memaddr, gdb_byte *myaddr, int len)
> {
> }
>
> So just try cut-and-pasting the same #ifdef CRASH_MERGE section into
> target_read_stack().
Yep, it did solve my issue, now the backtrace would unwind happily to
the next frame.
While I am trying to apply the similar logic to another thread
instead of current panic one, I find the gdb would directly complain
for "<segmentation violation in gdb> ". Haven't figure out what
happened there...
When gdb is invoked, it passes through this in gdb_interface():
if (!(pc->flags & DROP_CORE))
SIGACTION(SIGSEGV, restart, &pc->sigaction, NULL);
else
SIGACTION(SIGSEGV, SIG_DFL, &pc->sigaction, NULL);
which causes any segmentation violations in gdb code to restart back
to the command prompt. To get an actual core dump (to set DROP_CORE),
try this:
crash> set core on
core: on (drop core on error message)
crash>
If you do the above, however, any call to error(FATAL, ...),
error(INFO, ...), or error(WARNING, ...) will also generate
a core dump. If that gets in the way of your gdb testing, you
should just comment out the "if-else" statement above.
Dave
8:10 a.m.
Hi Dave,
----- Original Message -----
> > Hello Lei,
> >
> >
> > And it appears that target_read_stack() can be modified in the same
> > way
> > that target_read_memory() has been, since they are essentially the
> > same:
> >
> > int
> > target_read_stack (CORE_ADDR memaddr, gdb_byte *myaddr, int len)
> > {
> > }
> >
> > So just try cut-and-pasting the same #ifdef CRASH_MERGE section into
> > target_read_stack().
>
> Yep, it did solve my issue, now the backtrace would unwind happily to
> the next frame.
>
> While I am trying to apply the similar logic to another thread
> instead of current panic one, I find the gdb would directly complain
> for "<segmentation violation in gdb> ". Haven't figure out what
> happened there...
When gdb is invoked, it passes through this in gdb_interface():
if (!(pc->flags & DROP_CORE))
SIGACTION(SIGSEGV, restart, &pc->sigaction, NULL);
else
SIGACTION(SIGSEGV, SIG_DFL, &pc->sigaction, NULL);
which causes any segmentation violations in gdb code to restart back
to the command prompt. To get an actual core dump (to set DROP_CORE),
try this:
crash> set core on
core: on (drop core on error message)
crash>
If you do the above, however, any call to error(FATAL, ...),
error(INFO, ...), or error(WARNING, ...) will also generate
a core dump. If that gets in the way of your gdb testing, you
should just comment out the "if-else" statement above.
This seems interesting function; I would give it a try. :)
Thanks,
Lei
10:58 a.m.
2012/10/16 Lei Wen <leiwen(a)marvell.com>:
Current I am trying to make crash support display out function param
and
local value while backtracing.
The idea for this patch is to mimic core dump support in gdb, teaching the
crash to supply the regset to the gdb, so that gdb could have full knowledge
what is going on in the panic point.
Just for comparison/inspiration, I'm attaching the patch I've been using
for some time now to get this information in crash. It enables gdb's
backtrace directly so you will need to run it with "backtrace" or "gdb
bt".
I've made no attempt to clean up the patch, it's as-is (hacky) and
applies on top of Crash 6.0.6. I've only tested it on ARM and there are
several rough edges even on ARM (example, observe the "request failed"
message after the successful trace).
It looks like this:
crash> set 533
crash> bt
PID: 533 TASK: e62d4560 CPU: 1 COMMAND: "kworker/u:2"
#0 [<c0648f14>] (__schedule) from [<c0649688>]
#1 [<c0649688>] (schedule) from [<c064a898>]
#2 [<c064a898>] (__mutex_lock_slowpath) from [<c064a98c>]
#3 [<c064a98c>] (mutex_lock) from [<c03171dc>]
#4 [<c03171dc>] (device_attach) from [<c03168fc>]
#5 [<c03168fc>] (bus_probe_device) from [<c03149dc>]
#6 [<c03149dc>] (device_add) from [<c040cd88>]
#7 [<c040cd88>] (sdio_add_func) from [<c040c060>]
#8 [<c040c060>] (mmc_attach_sdio) from [<c0404930>]
#9 [<c0404930>] (mmc_rescan) from [<c00bb5e4>]
#10 [<c00bb5e4>] (process_one_work) from [<c00bbaf4>]
#11 [<c00bbaf4>] (worker_thread) from [<c00c0564>]
#12 [<c00c0564>] (kthread) from [<c0064288>]
crash> gdb bt
#0 0xc0648f14 in context_switch (next=0xe49b6520, prev=0xe62d4560,
rq=0xc1b4a8c0) at /tmp/kernel/kernel/sched.c:3216
#1 __schedule () at /tmp/kernel/kernel/sched.c:4354
#2 0xc0649688 in schedule () at /tmp/kernel/kernel/sched.c:4406
#3 0xc064a898 in __mutex_lock_common (state=2, lock=0xe49f1c3c,
subclass=<optimized out>, nest_lock=<optimized out>, ip=<optimized
out>) at /tmp/kernel/kernel/mutex.c:244
#4 __mutex_lock_slowpath (lock_count=0xe49f1c3c) at
/tmp/kernel/kernel/mutex.c:405
#5 0xc064a98c in __mutex_fastpath_lock (fail_fn=0xc064a760
<__mutex_lock_slowpath>, count=0xe49f1c3c) at
/tmp/kernel/arch/arm/include/asm/mutex.h:43
#6 mutex_lock (lock=0xe49f1c3c) at /tmp/kernel/kernel/mutex.c:90
#7 0xc03171dc in device_lock (dev=0xe49f1c08) at
/tmp/kernel/include/linux/device.h:673
#8 device_attach (dev=0xe49f1c08) at /tmp/kernel/drivers/base/dd.c:246
#9 0xc03168fc in bus_probe_device (dev=<optimized out>) at
/tmp/kernel/drivers/base/bus.c:493
#10 0xc03149dc in device_add (dev=0xe49f1c08) at
/tmp/kernel/drivers/base/core.c:978
#11 0xc040cd88 in sdio_add_func (func=0xe49f1c00) at
/tmp/kernel/drivers/mmc/core/sdio_bus.c:315
#12 0xc040c060 in mmc_attach_sdio (host=0xe6486800) at
/tmp/kernel/drivers/mmc/core/sdio.c:1197
#13 0xc0404930 in mmc_rescan_try_freq (freq=<optimized out>,
host=0xe6486800) at /tmp/kernel/drivers/mmc/core/core.c:2069
#14 mmc_rescan (work=0xe6486a08) at /tmp/kernel/drivers/mmc/core/core.c:2188
#15 0xc00bb5e4 in process_one_work (worker=0xe62e04e0,
work=0xe6486a08) at /tmp/kernel/kernel/workqueue.c:1870
#16 0xc00bbaf4 in worker_thread (__worker=0xe62e04e0) at
/tmp/kernel/kernel/workqueue.c:1981
#17 0xc00c0564 in kthread (_create=0xe60a9ec4) at
/tmp/kernel/kernel/kthread.c:96
#18 0xc0064288 in kernel_thread_helper ()
Register 25 is not available
gdb: gdb request failed: bt
crash> gdb bt full
#0 0xc0648f14 in context_switch (next=0xe49b6520, prev=0xe62d4560,
rq=0xc1b4a8c0) at /tmp/kernel/kernel/sched.c:3216
mm = 0x0
oldmm = <optimized out>
#1 __schedule () at /tmp/kernel/kernel/sched.c:4354
prev = 0xe62d4560
next = 0xe49b6520
switch_count = <optimized out>
rq = 0xc1b4a8c0
cpu = <optimized out>
#2 0xc0649688 in schedule () at /tmp/kernel/kernel/sched.c:4406
tsk = <unavailable>
#3 0xc064a898 in __mutex_lock_common (state=2, lock=0xe49f1c3c,
subclass=<optimized out>, nest_lock=<optimized out>, ip=<optimized
out>) at /tmp/kernel/kernel/mutex.c:244
task = 0xe62d4560
waiter = {
list = {
next = 0xe49f1c48,
prev = 0xe49f1c48
},
task = 0xe62d4560
}
#4 __mutex_lock_slowpath (lock_count=0xe49f1c3c) at
/tmp/kernel/kernel/mutex.c:405
lock = 0xe49f1c3c
#5 0xc064a98c in __mutex_fastpath_lock (fail_fn=0xc064a760
<__mutex_lock_slowpath>, count=0xe49f1c3c) at
/tmp/kernel/arch/arm/include/asm/mutex.h:43
__ex_flag = <optimized out>
__res = <optimized out>
#6 mutex_lock (lock=0xe49f1c3c) at /tmp/kernel/kernel/mutex.c:90
No locals.
#7 0xc03171dc in device_lock (dev=0xe49f1c08) at
/tmp/kernel/include/linux/device.h:673
No locals.
#8 device_attach (dev=0xe49f1c08) at /tmp/kernel/drivers/base/dd.c:246
ret = 0
#9 0xc03168fc in bus_probe_device (dev=<optimized out>) at
/tmp/kernel/drivers/base/bus.c:493
bus = <optimized out>
ret = <optimized out>
#10 0xc03149dc in device_add (dev=0xe49f1c08) at
/tmp/kernel/drivers/base/core.c:978
parent = 0xe3c7e008
class_intf = <optimized out>
error = 0
__func__ = "device_add"
#11 0xc040cd88 in sdio_add_func (func=0xe49f1c00) at
/tmp/kernel/drivers/mmc/core/sdio_bus.c:315
ret = <unavailable>
#12 0xc040c060 in mmc_attach_sdio (host=0xe6486800) at
/tmp/kernel/drivers/mmc/core/sdio.c:1197
err = <optimized out>
i = <optimized out>
funcs = 2
ocr = 553647872
card = 0xe3c7e000
#13 0xc0404930 in mmc_rescan_try_freq (freq=<optimized out>,
host=0xe6486800) at /tmp/kernel/drivers/mmc/core/core.c:2069
No locals.
#14 mmc_rescan (work=0xe6486a08) at /tmp/kernel/drivers/mmc/core/core.c:2188
host = 0xe6486800
i = <optimized out>
#15 0xc00bb5e4 in process_one_work (worker=0xe62e04e0,
work=0xe6486a08) at /tmp/kernel/kernel/workqueue.c:1870
cwq = 0xe6344a00
gcwq = <optimized out>
bwh = <unavailable>
cpu_intensive = <optimized out>
f = 0xc04046e4 <mmc_rescan>
#16 0xc00bbaf4 in worker_thread (__worker=0xe62e04e0) at
/tmp/kernel/kernel/workqueue.c:1981
work = <optimized out>
worker = 0xe62e04e0
gcwq = 0xc09c0a60
#17 0xc00c0564 in kthread (_create=0xe60a9ec4) at
/tmp/kernel/kernel/kthread.c:96
create = 0xe60a9ec4
threadfn = 0xc00bb960 <worker_thread>
data = 0xe62e04e0
self = {
should_stop = 0,
data = 0xe62e04e0,
exited = {
done = 0,
wait = {
lock = {
{
rlock = {
raw_lock = {
lock = 0
},
break_lock = 0
}
}
},
task_list = {
next = 0xe62effd0,
prev = 0xe62effd0
}
}
}
}
ret = -4
#18 0xc0064288 in kernel_thread_helper ()
No symbol table info available.
Register 25 is not available
gdb: gdb request failed: bt full
noon
----- Original Message -----
2012/10/16 Lei Wen <leiwen(a)marvell.com>:
> Current I am trying to make crash support display out function param and
> local value while backtracing.
>
> The idea for this patch is to mimic core dump support in gdb, teaching the
> crash to supply the regset to the gdb, so that gdb could have full knowledge
> what is going on in the panic point.
Just for comparison/inspiration, I'm attaching the patch I've been using
for some time now to get this information in crash. It enables gdb's
backtrace directly so you will need to run it with "backtrace" or "gdb
bt".
I've made no attempt to clean up the patch, it's as-is (hacky) and
applies on top of Crash 6.0.6. I've only tested it on ARM and there are
several rough edges even on ARM (example, observe the "request failed"
message after the successful trace).
Interesting -- I'm sure that Lei can take advantage of some of the work
you've done.
BTW, what happens when you run it against a task that has taken a
kernel-mode exception or kernel-mode interrupt?
Dave
It looks like this:
crash> set 533
crash> bt
PID: 533 TASK: e62d4560 CPU: 1 COMMAND: "kworker/u:2"
#0 [<c0648f14>] (__schedule) from [<c0649688>]
#1 [<c0649688>] (schedule) from [<c064a898>]
#2 [<c064a898>] (__mutex_lock_slowpath) from [<c064a98c>]
#3 [<c064a98c>] (mutex_lock) from [<c03171dc>]
#4 [<c03171dc>] (device_attach) from [<c03168fc>]
#5 [<c03168fc>] (bus_probe_device) from [<c03149dc>]
#6 [<c03149dc>] (device_add) from [<c040cd88>]
#7 [<c040cd88>] (sdio_add_func) from [<c040c060>]
#8 [<c040c060>] (mmc_attach_sdio) from [<c0404930>]
#9 [<c0404930>] (mmc_rescan) from [<c00bb5e4>]
#10 [<c00bb5e4>] (process_one_work) from [<c00bbaf4>]
#11 [<c00bbaf4>] (worker_thread) from [<c00c0564>]
#12 [<c00c0564>] (kthread) from [<c0064288>]
crash> gdb bt
#0 0xc0648f14 in context_switch (next=0xe49b6520, prev=0xe62d4560,
rq=0xc1b4a8c0) at /tmp/kernel/kernel/sched.c:3216
#1 __schedule () at /tmp/kernel/kernel/sched.c:4354
#2 0xc0649688 in schedule () at /tmp/kernel/kernel/sched.c:4406
#3 0xc064a898 in __mutex_lock_common (state=2, lock=0xe49f1c3c,
subclass=<optimized out>, nest_lock=<optimized out>, ip=<optimized
out>) at /tmp/kernel/kernel/mutex.c:244
#4 __mutex_lock_slowpath (lock_count=0xe49f1c3c) at
/tmp/kernel/kernel/mutex.c:405
#5 0xc064a98c in __mutex_fastpath_lock (fail_fn=0xc064a760
<__mutex_lock_slowpath>, count=0xe49f1c3c) at
/tmp/kernel/arch/arm/include/asm/mutex.h:43
#6 mutex_lock (lock=0xe49f1c3c) at /tmp/kernel/kernel/mutex.c:90
#7 0xc03171dc in device_lock (dev=0xe49f1c08) at
/tmp/kernel/include/linux/device.h:673
#8 device_attach (dev=0xe49f1c08) at
/tmp/kernel/drivers/base/dd.c:246
#9 0xc03168fc in bus_probe_device (dev=<optimized out>) at
/tmp/kernel/drivers/base/bus.c:493
#10 0xc03149dc in device_add (dev=0xe49f1c08) at
/tmp/kernel/drivers/base/core.c:978
#11 0xc040cd88 in sdio_add_func (func=0xe49f1c00) at
/tmp/kernel/drivers/mmc/core/sdio_bus.c:315
#12 0xc040c060 in mmc_attach_sdio (host=0xe6486800) at
/tmp/kernel/drivers/mmc/core/sdio.c:1197
#13 0xc0404930 in mmc_rescan_try_freq (freq=<optimized out>,
host=0xe6486800) at /tmp/kernel/drivers/mmc/core/core.c:2069
#14 mmc_rescan (work=0xe6486a08) at
/tmp/kernel/drivers/mmc/core/core.c:2188
#15 0xc00bb5e4 in process_one_work (worker=0xe62e04e0,
work=0xe6486a08) at /tmp/kernel/kernel/workqueue.c:1870
#16 0xc00bbaf4 in worker_thread (__worker=0xe62e04e0) at
/tmp/kernel/kernel/workqueue.c:1981
#17 0xc00c0564 in kthread (_create=0xe60a9ec4) at
/tmp/kernel/kernel/kthread.c:96
#18 0xc0064288 in kernel_thread_helper ()
Register 25 is not available
gdb: gdb request failed: bt
crash> gdb bt full
#0 0xc0648f14 in context_switch (next=0xe49b6520, prev=0xe62d4560,
rq=0xc1b4a8c0) at /tmp/kernel/kernel/sched.c:3216
mm = 0x0
oldmm = <optimized out>
#1 __schedule () at /tmp/kernel/kernel/sched.c:4354
prev = 0xe62d4560
next = 0xe49b6520
switch_count = <optimized out>
rq = 0xc1b4a8c0
cpu = <optimized out>
#2 0xc0649688 in schedule () at /tmp/kernel/kernel/sched.c:4406
tsk = <unavailable>
#3 0xc064a898 in __mutex_lock_common (state=2, lock=0xe49f1c3c,
subclass=<optimized out>, nest_lock=<optimized out>, ip=<optimized
out>) at /tmp/kernel/kernel/mutex.c:244
task = 0xe62d4560
waiter = {
list = {
next = 0xe49f1c48,
prev = 0xe49f1c48
},
task = 0xe62d4560
}
#4 __mutex_lock_slowpath (lock_count=0xe49f1c3c) at
/tmp/kernel/kernel/mutex.c:405
lock = 0xe49f1c3c
#5 0xc064a98c in __mutex_fastpath_lock (fail_fn=0xc064a760
<__mutex_lock_slowpath>, count=0xe49f1c3c) at
/tmp/kernel/arch/arm/include/asm/mutex.h:43
__ex_flag = <optimized out>
__res = <optimized out>
#6 mutex_lock (lock=0xe49f1c3c) at /tmp/kernel/kernel/mutex.c:90
No locals.
#7 0xc03171dc in device_lock (dev=0xe49f1c08) at
/tmp/kernel/include/linux/device.h:673
No locals.
#8 device_attach (dev=0xe49f1c08) at
/tmp/kernel/drivers/base/dd.c:246
ret = 0
#9 0xc03168fc in bus_probe_device (dev=<optimized out>) at
/tmp/kernel/drivers/base/bus.c:493
bus = <optimized out>
ret = <optimized out>
#10 0xc03149dc in device_add (dev=0xe49f1c08) at
/tmp/kernel/drivers/base/core.c:978
parent = 0xe3c7e008
class_intf = <optimized out>
error = 0
__func__ = "device_add"
#11 0xc040cd88 in sdio_add_func (func=0xe49f1c00) at
/tmp/kernel/drivers/mmc/core/sdio_bus.c:315
ret = <unavailable>
#12 0xc040c060 in mmc_attach_sdio (host=0xe6486800) at
/tmp/kernel/drivers/mmc/core/sdio.c:1197
err = <optimized out>
i = <optimized out>
funcs = 2
ocr = 553647872
card = 0xe3c7e000
#13 0xc0404930 in mmc_rescan_try_freq (freq=<optimized out>,
host=0xe6486800) at /tmp/kernel/drivers/mmc/core/core.c:2069
No locals.
#14 mmc_rescan (work=0xe6486a08) at
/tmp/kernel/drivers/mmc/core/core.c:2188
host = 0xe6486800
i = <optimized out>
#15 0xc00bb5e4 in process_one_work (worker=0xe62e04e0,
work=0xe6486a08) at /tmp/kernel/kernel/workqueue.c:1870
cwq = 0xe6344a00
gcwq = <optimized out>
bwh = <unavailable>
cpu_intensive = <optimized out>
f = 0xc04046e4 <mmc_rescan>
#16 0xc00bbaf4 in worker_thread (__worker=0xe62e04e0) at
/tmp/kernel/kernel/workqueue.c:1981
work = <optimized out>
worker = 0xe62e04e0
gcwq = 0xc09c0a60
#17 0xc00c0564 in kthread (_create=0xe60a9ec4) at
/tmp/kernel/kernel/kthread.c:96
create = 0xe60a9ec4
threadfn = 0xc00bb960 <worker_thread>
data = 0xe62e04e0
self = {
should_stop = 0,
data = 0xe62e04e0,
exited = {
done = 0,
wait = {
lock = {
{
rlock = {
raw_lock = {
lock = 0
},
break_lock = 0
}
}
},
task_list = {
next = 0xe62effd0,
prev = 0xe62effd0
}
}
}
}
ret = -4
#18 0xc0064288 in kernel_thread_helper ()
No symbol table info available.
Register 25 is not available
gdb: gdb request failed: bt full
3:22 a.m.
2012/10/17 Dave Anderson <anderson(a)redhat.com>:
BTW, what happens when you run it against a task that has taken a
kernel-mode exception or kernel-mode interrupt?
The backtrace stops at the exception point:
crash> bt
PID: 0 TASK: c0998778 CPU: 0 COMMAND: "swapper"
#0 [<c0320fb8>] (touch_softlockup_watchdog) from [<c0290030>]
#1 [<c0290030>] (asm_do_IRQ) from [<c029124c>]
pc : [<c02a1e60>] lr : [<c02a1e5c>] psr: 60000013
sp : c0983f18 ip : 00000002 fp : 000021ce
r10: a83a0af5 r9 : 0000289c r8 : c09ead48
r7 : 00000008 r6 : a7979c2b r5 : 00000001 r4 : 00000003
r3 : 00000000 r2 : 00000001 r1 : 80000093 r0 : c09ead8c
Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM
#2 [<c029124c>] (__irq_svc) from [<c02a1e5c>]
#3 [<c02a1e60>] (cpuidle_enter) from [<c05dfa3c>]
#4 [<c05dfa3c>] (cpuidle_idle_call) from [<c0292c98>]
#5 [<c0292c98>] (cpu_idle) from [<c0008cb0>]
#6 [<c0008cb0>] (start_kernel) from [<00008080>]
crash> gdb bt
#0 0xc0320fb8 in touch_softlockup_watchdog () at
/tmp/kernel/kernel/softlockup.c:77
#1 0xc0290030 in asm_do_IRQ (irq=80, regs=0x0) at
/tmp/kernel/arch/arm/kernel/irq.c:109
#2 0xc029124c in __irq_svc () at /tmp/kernel/arch/arm/kernel/entry-armv.S:229
Register 25 is not available
gdb: gdb request failed: bt
3:35 a.m.
New subject: [RFC] display function param and local value for backtrace
Hi Rabin,
-----Original Message-----
From: crash-utility-bounces(a)redhat.com
[mailto:crash-utility-bounces@redhat.com] On Behalf Of Rabin Vincent
Sent: Thursday, October 18, 2012 4:22 PM
To: Dave Anderson
Cc: Discussion list for crash utility usage, maintenance and development
Subject: Re: [Crash-utility] [RFC] display function param and local value for
backtrace
2012/10/17 Dave Anderson <anderson(a)redhat.com>:
> BTW, what happens when you run it against a task that has taken a
> kernel-mode exception or kernel-mode interrupt?
The backtrace stops at the exception point:
crash> bt
PID: 0 TASK: c0998778 CPU: 0 COMMAND: "swapper"
#0 [<c0320fb8>] (touch_softlockup_watchdog) from [<c0290030>]
#1 [<c0290030>] (asm_do_IRQ) from [<c029124c>]
pc : [<c02a1e60>] lr : [<c02a1e5c>] psr: 60000013
sp : c0983f18 ip : 00000002 fp : 000021ce
r10: a83a0af5 r9 : 0000289c r8 : c09ead48
r7 : 00000008 r6 : a7979c2b r5 : 00000001 r4 : 00000003
r3 : 00000000 r2 : 00000001 r1 : 80000093 r0 : c09ead8c
Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM
#2 [<c029124c>] (__irq_svc) from [<c02a1e5c>]
#3 [<c02a1e60>] (cpuidle_enter) from [<c05dfa3c>]
#4 [<c05dfa3c>] (cpuidle_idle_call) from [<c0292c98>]
#5 [<c0292c98>] (cpu_idle) from [<c0008cb0>]
#6 [<c0008cb0>] (start_kernel) from [<00008080>]
crash> gdb bt
#0 0xc0320fb8 in touch_softlockup_watchdog () at
/tmp/kernel/kernel/softlockup.c:77
#1 0xc0290030 in asm_do_IRQ (irq=80, regs=0x0) at
/tmp/kernel/arch/arm/kernel/irq.c:109
#2 0xc029124c in __irq_svc () at
/tmp/kernel/arch/arm/kernel/entry-armv.S:229
Register 25 is not available
gdb: gdb request failed: bt
Your patch still work well in 6.0.9. Good job!
While I am trying to do similar thing in my patch, exacting the registers from
thread_info, instead of crash_note for those not running task, I just could get the first
unwind function, then it failed. Do you have any idea for why?
The unwind goes normally for the panic task.
Also I see your "gdb bt" would always fails at below message, is there method to
provide the cpsr for the not running task?
Register 25 is not available
Thanks,
Lei
4:04 a.m.
2012/10/18 Lei Wen <leiwen(a)marvell.com>:
While I am trying to do similar thing in my patch, exacting the
registers from thread_info, instead of crash_note for those not
running task, I just could get the first unwind function, then it
failed. Do you have any idea for why? The unwind goes normally for
the panic task.
No idea from the top of my head.
Also I see your "gdb bt" would always fails at below
message, is there
method to provide the cpsr for the not running task?
I haven't really looked into this, sorry.
Rabin
10:08 a.m.
Hi Rabin,
On Thu, Oct 18, 2012 at 5:04 PM, Rabin Vincent <rabin(a)rab.in> wrote:
2012/10/18 Lei Wen <leiwen(a)marvell.com>:
> While I am trying to do similar thing in my patch, exacting the
> registers from thread_info, instead of crash_note for those not
> running task, I just could get the first unwind function, then it
> failed. Do you have any idea for why? The unwind goes normally for
> the panic task.
No idea from the top of my head.
> Also I see your "gdb bt" would always fails at below message, is there
> method to provide the cpsr for the not running task?
I haven't really looked into this, sorry.
Finally, I get all thread works. Inspired by your getting register from
thread_info,
now everything seems goes right, and there is no gdb complain for missing
cpsr.
Thanks,
Lei
4420
days inactive
4424
days old
devel@lists.crash-utility.osci.io
10 comments
4 participants
participants (4)
-
Dave Anderson -
Lei Wen -
Lei Wen -
Rabin Vincent