Question regarding call trace.

Question regarding call trace.

[Justin Piszcz]

I have a trace that looks like the following, my question is, are the 
process(es) at the top of the call trace responible for the actual crash 
of the machine?  Are they the root cause?

Would this point to a bad SCSI board?


  Call Trace:    [<c0107a24>] [<c0107b0e>] [<f892ad30>] 
[<c01073f6>] [<f8926590>]
scsi_eh_0     S 00000012  6376   166      1           167    13 (L-TLB)
Call Trace:    [<c0107a24>] [<c0107b0e>] [<c01fffa1>] [<c0108d76>] 
[<c01073f6>]
   [<c01ffc80>]
scsi_eh_1     S 00000010  6372   167      1           168   166 (L-TLB)
Call Trace:    [<c0107a24>] [<c0107b0e>] [<c01fffa1>] [<c0108d76>] 
[<c01073f6>]
   [<c01ffc80>]
scsi_eh_2     S 00000015  6372   168      1           169   167 (L-TLB)
Call Trace:    [<c0107a24>] [<c0107b0e>] [<c01fffa1>] [<c0108d76>] 
[<c01073f6>]
   [<c01ffc80>]
scsi_eh_3     S 00000012  6372   169      1           165   168 (L-TLB)
Call Trace:    [<c0107a24>] [<c0107b0e>] [<c01fffa1>] [<c0108d76>] 
[<c01073f6>]
   [<c01ffc80>]
kjournald     S 00000019  2608   185      1           186   162 (L-TLB)
Call Trace:    [<c0117dfa>] [<c017f6fa>] [<c017f570>] [<c01073f6>] 
[<c017f590>]
kjournald     S 00000019     0   186      1           187   185 (L-TLB)
Call Trace:    [<c0117dfa>] [<c017f6fa>] [<c017f570>] [<c01073f6>] 
[<c017f590>]
kjournald     S 00000016  2608   187      1           188   186 (L-TLB)
Call Trace:    [<c0117dfa>] [<c017f6fa>] [<c017f570>] [<c01073f6>] 
[<c017f590>]
kjournald     S 00000019  2608   188      1           675   187 (L-TLB)
Call Trace:    [<c0117dfa>] [<c017f6fa>] [<c017f570>] [<c01073f6>] 
[<c017f590>]
sshd          S C850FBA0    20   675      1           699   188 (NOTLB)
Call Trace:    [<c0108944>] [<c0117417>] [<c022e480>] [<c015676a>] 
[<c0156af8>]
syslogd08dc3>]R 0000001A  3660   699      1           704

Re: Question regarding call trace.

[Jesper Juhl]

On 2/27/06, Justin Piszcz <jpiszcz@lucidpixels.com> wrote:
> I have a trace that looks like the following, my question is, are the
> process(es) at the top of the call trace responible for the actual crash
> of the machine?  Are they the root cause?
>

As a general rule, functions near the top of a trace are more likely
to be the cause of the crash than functions near the bottom, but
that's not always the case.
Also sometimes when dealing with race conditions some part of the
kernel messes up and causes a different part of the kernel to crase so
that what you see in the trace is not what actually *caused* the
problem but merely what was affected by a problem somewhere else.
And if there's memory corruption going on then sometimes one part of
the kernel can scrible on random memory and cause a different and
completely unrelated part of the kernel to blow up.
So you cannot always trust a call trace 100%.


> Would this point to a bad SCSI board?
>
I'm sorry, I can't tell you :(

You might want to try enable debugging symbols and frame pointers to
get a more readable trace.

Consider these options (in the Kernel Hacking section of menuconfig) :
  CONFIG_DEBUG_KERNEL
  CONFIG_DEBUG_INFO
  CONFIG_FRAME_POINTER
  CONFIG_UNWIND_INFO

There are other options in there as well that may help, read their
description and decide for yourself if you think they will be needed -
or maybe someone else who understands your dump better than me can
advice on what specific options to enable.

Hope this helps you.

--
Jesper Juhl <jesper.juhl@gmail.com>
Don't top-post  http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please      http://www.expita.com/nomime.html

Re: Question regarding call trace.

[Justin Piszcz]

Thanks for the information.

On Mon, 27 Feb 2006, Jesper Juhl wrote:

> On 2/27/06, Justin Piszcz <jpiszcz@lucidpixels.com> wrote:
>> I have a trace that looks like the following, my question is, are the
>> process(es) at the top of the call trace responible for the actual crash
>> of the machine?  Are they the root cause?
>>
>
> As a general rule, functions near the top of a trace are more likely
> to be the cause of the crash than functions near the bottom, but
> that's not always the case.
> Also sometimes when dealing with race conditions some part of the
> kernel messes up and causes a different part of the kernel to crase so
> that what you see in the trace is not what actually *caused* the
> problem but merely what was affected by a problem somewhere else.
> And if there's memory corruption going on then sometimes one part of
> the kernel can scrible on random memory and cause a different and
> completely unrelated part of the kernel to blow up.
> So you cannot always trust a call trace 100%.
>
>
>> Would this point to a bad SCSI board?
>>
> I'm sorry, I can't tell you :(
>
> You might want to try enable debugging symbols and frame pointers to
> get a more readable trace.
>
> Consider these options (in the Kernel Hacking section of menuconfig) :
>  CONFIG_DEBUG_KERNEL
>  CONFIG_DEBUG_INFO
>  CONFIG_FRAME_POINTER
>  CONFIG_UNWIND_INFO
>
> There are other options in there as well that may help, read their
> description and decide for yourself if you think they will be needed -
> or maybe someone else who understands your dump better than me can
> advice on what specific options to enable.
>
> Hope this helps you.
>
> --
> Jesper Juhl <jesper.juhl@gmail.com>
> Don't top-post  http://www.catb.org/~esr/jargon/html/T/top-post.html
> Plain text mails only, please      http://www.expita.com/nomime.html
>

Re: Question regarding call trace.

[Robert Hancock]

Justin Piszcz wrote:
> I have a trace that looks like the following, my question is, are the 
> process(es) at the top of the call trace responible for the actual crash 
> of the machine?  Are they the root cause?

This looks like a dump from a SysRq-T keypress to dump the stack on all 
threads.. where is the crash?

-- 
Robert Hancock      Saskatoon, SK, Canada
To email, remove "nospam" from hancockr@nospamshaw.ca
Home Page: http://www.roberthancock.com/