Messages in this thread |  | | From | Keith Owens <> | Subject | Re: (reiserfs hang at boot) where is the kernel debugger? | Date | Wed, 04 Oct 2000 02:47:10 +1100 |
| |
On Tue, 3 Oct 2000 12:32:37 -0300 (BRST), Rik van Riel <riel@conectiva.com.br> wrote: >On Wed, 4 Oct 2000, Keith Owens wrote: >> Rik van Riel <riel@conectiva.com.br> wrote: >> >Sysrq-T is broken on x86 ;(((((((( >> >> show_task() calls thread_saved_pc() which is giving bad results. >> Getting the correct PC for blocked threads is easy, >> But it does not give you much. Thread esp and eip are only >> saved during switch_to(), at which point eip always points to >> schedule+0x42c. > >Yup ;) > >So this function will need to look at the call trace and >give the function that called schedule() ...
Shudder. I had to do that for kdb and it is as ugly as sin. See kdba_prologue and kdb_get_next_ar in the kdb patch, especially the comments at the start of kdb_get_next_ar. ix86 back trace has special cases galore. This is why an oops dumps so much rubbish in the "call trace" on ix86, it is just too hard to get a correct call trace so we print anything on stack that might be a kernel or module address and expect the user to filter out all the false positives.
Also bear in mind that for running threads you have no idea where the stack pointer is, esp is not saved in the process table unless the thread blocks. So sysrq-T cannot even think about looking at the stack for running threads on other cpus unless you force them to block first.
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org Please read the FAQ at http://www.tux.org/lkml/
|  |