All of lore.kernel.org
 help / color / mirror / Atom feed
From: Justin Piszcz <jpiszcz@lucidpixels.com>
To: Jesper Juhl <jesper.juhl@gmail.com>
Cc: linux-kernel@vger.kernel.org
Subject: Re: Question regarding call trace.
Date: Mon, 27 Feb 2006 14:52:04 -0500 (EST)	[thread overview]
Message-ID: <Pine.LNX.4.64.0602271452010.5678@p34> (raw)
In-Reply-To: <9a8748490602271133o4aa673e4x3c069c1ab08fc392@mail.gmail.com>

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
>

  reply	other threads:[~2006-02-27 19:52 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-02-27 19:12 Question regarding call trace Justin Piszcz
2006-02-27 19:33 ` Jesper Juhl
2006-02-27 19:52   ` Justin Piszcz [this message]
     [not found] <5KW4H-13v-11@gated-at.bofh.it>
2006-02-27 23:38 ` Robert Hancock

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Pine.LNX.4.64.0602271452010.5678@p34 \
    --to=jpiszcz@lucidpixels.com \
    --cc=jesper.juhl@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.