All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andres Salomon <dilinger@debian.org>
To: Andi Kleen <ak@suse.de>
Cc: linux-kernel@vger.kernel.org
Subject: Re: [PATCH] x86_64 stack trace cleanup
Date: Fri, 24 Feb 2006 06:29:12 -0500	[thread overview]
Message-ID: <1140780552.5073.26.camel@localhost.localdomain> (raw)
In-Reply-To: <200602241147.03041.ak@suse.de>

[-- Attachment #1: Type: text/plain, Size: 2151 bytes --]

On Fri, 2006-02-24 at 11:47 +0100, Andi Kleen wrote:
> On Friday 24 February 2006 11:41, Andres Salomon wrote:
> > Hi,
> > 
> > This patch cleans up the clutter of x86_64 stack traces, making the
> > output closer to what i386 and sparc64 stack traces look like.  It uses
> > print_symbol instead of resolving the symbols manually, and prints one
> > frame per line instead of displaying multiple frames per line.  I left
> > the other stuff in the stack dump alone; this affects only the frame
> > list.
> > 
> > I know this has been brought up before
> > (http://www.uwsg.iu.edu/hypermail/linux/kernel/0602.0/2238.html,
> > although I noticed a slight problem w/ that patch, as __print_symbol
> > returns void); however, for people that don't spend all their time
> > looking at x86_64 backtraces, I think this consistency shouldn't be
> > scoffed at.  When you switch back and forth between different archs,
> > x86_64's backtrace is cluttered and confusing in comparison.
> 
> If the formatting of the oopses is  your only problem you are a 
> lucky man.
> 

That would be nice.  Unfortunately, I'm trying to figure out why my dual
opteron box likes to push the load up to 15 and then hang while doing
i/o to the 3ware 9500S-8 card.  Looks like the load/d-state processes
are caused by a whole lot (well, MAX_PDFLUSH_THREADS) of pdflush
processes spinning on base->lock in lock_timer_base(); not sure if
that's intentional or not, but it seems rather odd.  Whether the hanging
is related to the high load remains to be seen.


> The problem is your new format uses more screen estate, which is precious
> after an oops because the VGA scrollback is so small.
> That is why i rejected the earlier attempts at changing this.
> 

I don't see why this is a problem.  Other architectures have done this
for ages, without problems.  I suspect most people get their backtraces
from either serial console or logs, as copying them down from the screen
or taking a picture of the panic is a rather large pain.  It seems like
you're penalizing everyone for a few select use cases.

Of course, this is all opinion.

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 191 bytes --]

  reply	other threads:[~2006-02-24 11:29 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-02-24 10:41 [PATCH] x86_64 stack trace cleanup Andres Salomon
2006-02-24 10:47 ` Andi Kleen
2006-02-24 11:29   ` Andres Salomon [this message]
2006-02-24 12:22     ` Andi Kleen
2006-02-24 19:25       ` Alistair John Strachan
2006-02-24 19:40         ` Jesper Juhl
2006-02-24 13:35     ` Jesper Juhl
2006-02-24 12:50   ` Andrew Morton
2006-02-24 13:00     ` Andi Kleen
2006-02-24 13:13       ` Andrew Morton
2006-02-24 13:20         ` Andi Kleen
2006-02-24 15:53         ` Randy.Dunlap

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=1140780552.5073.26.camel@localhost.localdomain \
    --to=dilinger@debian.org \
    --cc=ak@suse.de \
    --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.