lkml.org 
[lkml]   [2000]   [Oct]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: (reiserfs hang at boot) where is the kernel debugger?
Date
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/

\
 
 \ /
  Last update: 2005-03-22 12:45    [W:0.074 / U:0.340 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site