Re: [Kgdb-bugreport] KGDB/RT integration woes
Status: Beta
Brought to you by:
jwessel
From: Sergei S. <ssh...@ru...> - 2007-06-19 18:51:25
|
Hello, I wrote: >>>This patch fixes some corner cases where KGDB will silently hang or >>>kill the system, if a user accidentally tries to source step into a >>>spin_unlock() call or source step in on a macro containing >>>smp_processor_id(). The use of raw_smp_processor_id is desired in >>>kernel/kgdb.c to fix this particular problem. >>>To fix issues with accidental source step in on spin_unlock(), the >>>idea is to check for the existence of a break point on the second >>>entry to kgdb and try to remove it. Next an attempt will be made to >>>continue normal operations. A third entry will generate a panic(), so >>>as to stop infinite loops. >>>Testing has shown that kgdb is much more robust with these changes >>>and "random accidental run control". >> It seems that something has been broken WRT backtracing... > Here's the more relevant trace -- got it at the initial KGDB breakpoint: Well, it seems to be caused by KGDB using the infamous unwinder which is a part of the -rt patch now... :-/ With the plain kernel, backtracing works well, however, that's what I'm getting after hitting breaklpint set to do_mount and continuing: BUG: scheduling while atomic: swapper/0x0000000a/1 Call Trace: [<ffffffff805724e0>] __sched_text_start+0x60/0x7ee [<ffffffff8027d7fb>] ____cache_alloc_node+0x111/0x120 [<ffffffff8022c4f9>] default_wake_function+0xd/0xf [<ffffffff80574a06>] __lock_text_start+0x2e/0x30 [<ffffffff80242734>] flush_cpu_workqueue+0x90/0xb8 [<ffffffff80246192>] autoremove_wake_function+0x0/0x37 [<ffffffff80242200>] __queue_work+0x7b/0x83 [<ffffffff80246192>] autoremove_wake_function+0x0/0x37 [<ffffffff8024229a>] queue_work+0x92/0x9e [<ffffffff802427ba>] flush_workqueue+0x5e/0x7f [<ffffffff80242c15>] flush_scheduled_work+0x10/0x12 [<ffffffff8056463b>] xs_connect+0xd3/0xd8 [<ffffffff80561f01>] xprt_connect+0x11a/0x123 [<ffffffff8056055c>] call_connect+0x79/0x7e [<ffffffff80565a43>] __rpc_execute+0x84/0x248 [<ffffffff80565c27>] rpc_execute+0x20/0x24 [<ffffffff80560095>] call_start+0x0/0x72 [<ffffffff8055ffc5>] rpc_call_sync+0x84/0xab [<ffffffff8056cca0>] rpc_getport_external+0xe1/0x104 [<ffffffff807abe8d>] root_nfs_getport+0x6e/0x79 [<ffffffff807ac04f>] nfs_root_data+0x1b7/0x32c [<ffffffff802983a1>] sys_mount+0xc1/0xd3 [<ffffffff8028b9b2>] sys_rmdir+0x11/0x13 [<ffffffff80796f30>] mount_root+0x1d/0x138 [<ffffffff80797152>] prepare_namespace+0x107/0x134 [<ffffffff80796a60>] init+0x25e/0x270 [<ffffffff80574e9b>] _spin_unlock_irq+0x15/0x2f [<ffffffff8022ac65>] schedule_tail+0x36/0x9d [<ffffffff8020a3b8>] child_rip+0xa/0x12 [<ffffffff803711b8>] acpi_ds_init_one_object+0x0/0x88 [<ffffffff80796802>] init+0x0/0x270 [<ffffffff8020a3ae>] child_rip+0x0/0x12 WBR, Sergei |