|
|
 |
|
| |
This KGDB patch has been tested on a dual CPU opteron machine. All
kgdb features including thread support and console messages through gdb
were tested and found to work.
x86_64 gdb cannot show stack trace correctly beyond do_IRQ function on
the CPU which runs kgdb. For getting this stack trace, a shadow thread
has been implemented. This thread's stack trace is the missing stack
trace. It's shown in the example below:
Press Ctrl+C in gdb
Program received signal SIGTRAP, Trace/breakpoint trap.
breakpoint () at kernel/kgdbstub.c:1056
1056
atomic_set(&kgdb_setting_breakpoint, 0);
(gdb) bt
#0 breakpoint () at kernel/kgdbstub.c:1056
#1 0xffffffff801e3f17 in kgdb8250_interrupt (irq=3, dev_id=0x0,
regs=0x1)
at drivers/serial/kgdb_8250.c:143
#2 0xffffffff80113341 in handle_IRQ_event (irq=3,
regs=0x10001a1dc48,
action=0x1001ff29840) at arch/x86_64/kernel/irq.c:219
#3 0xffffffff801134e1 in do_IRQ (regs=0x10001a1dc48)
at arch/x86_64/kernel/irq.c:387
#4 0xffffffff80110eab in common_interrupt () at elfcore.h:92
Previous frame inner to this frame (corrupt stack?)
gdb can't trace beyond this point correctly. Check whether thread
listing contains a shadow thread. It can be identified by tag Stack at
interrupt entrypoint.
(gdb) info thr
10 Thread 32769 (Stack at interrupt entrypoint) __delay
(loops=1384000)
at arch/x86_64/lib/delay.c:30
9 Thread 32768 (Shadow task 0 for pid 0)
0xffffffff8010eb3e in cpu_idle ()
at sched.h:914
8 Thread 8 (aio/0) 0xffffffff8013f41c in worker_thread (
__startup=0x1001ff28d60) at sched.h:914
7 Thread 7 (kswapd0) kswapd (p=0xffffffff803170e8) at
mm/vmscan.c:1046
6 Thread 6 (pdflush) __pdflush (my_work=0x1001fd71f18) at
current.h:11
5 Thread 5 (pdflush) __pdflush (my_work=0x1001fd73f18) at
current.h:11
4 Thread 4 (kblockd/0) 0xffffffff8013f41c in worker_thread
(
__startup=0x1001ff28ae0) at sched.h:914
3 Thread 3 (events/0) 0xffffffff8013f41c in worker_thread (
__startup=0x1001ff3cd60) at sched.h:914
2 Thread 2 (ksoftirqd/0) ksoftirqd
(__bind_cpu=0xffffffff8030be20)
at current.h:11
* 1 Thread 1 (swapper) breakpoint () at kernel/kgdbstub.c:1056
It is thread 10 in above listing. We can get the lost back trace
from thread 10
(gdb) bt
#0 __delay (loops=1384000) at arch/x86_64/lib/delay.c:30
#1 0xffffffff80212bfd in ide_delay_50ms () at
drivers/ide/ide.c:1451
#2 0xffffffff8020b252 in actual_try_to_identify
(drive=0xffffffff803c05e8,
cmd=236 ' ') at drivers/ide/ide-probe.c:351
#3 0xffffffff8020b67a in try_to_identify
(drive=0xffffffff803c05e8,
cmd=236 ' ') at drivers/ide/ide-probe.c:405
#4 0xffffffff8020b7ef in do_probe (drive=0xffffffff803c05e8,
cmd=236 '�)
at drivers/ide/ide-probe.c:497
#5 0xffffffff8020bcaa in probe_hwif (hwif=0xffffffff803c04a0)
at drivers/ide/ide-probe.c:613
#6 0xffffffff8020bf46 in probe_hwif_init (hwif=0xffffffff803c04a0)
at drivers/ide/ide-probe.c:868
#7 0xffffffff8021a10d in ide_setup_pci_device (dev=0x1f9e8,
d=0x1f7)
at drivers/ide/setup-pci.c:740
....
|
|
| |
|
|
|
