From: Grant Grundler <grundler@puffin.external.hp.com>
To: Matthew Wilcox <willy@debian.org>
Cc: parisc-linux@lists.parisc-linux.org
Subject: Re: [parisc-linux] 2.4.6-pa5 crashes on B160L
Date: Sun, 08 Jul 2001 17:31:25 -0600 [thread overview]
Message-ID: <200107082331.RAA09058@puffin.external.hp.com> (raw)
In-Reply-To: Message from Matthew Wilcox <willy@debian.org> of "Sun, 08 Jul 2001 22:10:12 BST." <20010708221012.N6103@parcelfarce.linux.theplanet.co.uk>
Matthew Wilcox wrote:
> The stack dump isn't really necessary ... Does anyone else think we
> should turn it off by default?
...
No. I don't think we should turn it off.
Not until we can get memory core dumps on crashes like HPUX does.
> It'd also be helpful to show where the kernel got to before it did the
> stack dump -- might help track it down.
Isn't that what the stack dump is for?
If one is really good (like jsm) and has a matching vmlinux and System.map,
one can backtrace the stack by hand by looking at stack frame (return pointer
is in the stack frame) and seeing how much each subroutine grows the stack
(look at code around subroutine call, iirc). I think the mail archives
have a concise desription of exactly how to use the stack dump.
But I am too lazy to look for it now.
If one is lazy and not quite so good (like me), then look at build-tools/astk
script. astk can sift through the stackdump for kernel symbols to produce
something almost sortof like a stack trace with some extra garbage in it.
> > What else is needed to debug this? Is there a ksymoops equivalent?
> > I can supply .config, System.map on request.
>
> I tend to look it up by hand -- 102a4990 is the most interesting address,
> (IAOQ) and r2 is sometimes also interesting (not in this case, it
> would seem).
I use build-tools/a.c (compiled of course) to lookup symbols in a System.map.
The only other thing needed to debug the problem is for someone to unwind
the stack, see how it got where it was and then stare at the code until it's
clear why it crashed.
grant
Grant Grundler
parisc-linux {PCI|IOMMU|SMP} hacker
+1.408.447.7253
next prev parent reply other threads:[~2001-07-08 23:32 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-07-08 15:21 [parisc-linux] 2.4.6-pa5 crashes on B160L Scott Ashcroft
2001-07-08 21:10 ` Matthew Wilcox
2001-07-08 23:31 ` Grant Grundler [this message]
2001-07-08 23:48 ` Matthew Wilcox
2001-07-09 1:20 ` Grant Grundler
2001-07-09 15:34 ` B132 dies too (was Re: [parisc-linux] 2.4.6-pa5 crashes on B160L) LaMont Jones
2001-07-09 1:41 ` [parisc-linux] 2.4.6-pa5 crashes on B160L Scott Ashcroft
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=200107082331.RAA09058@puffin.external.hp.com \
--to=grundler@puffin.external.hp.com \
--cc=parisc-linux@lists.parisc-linux.org \
--cc=willy@debian.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.