From: Jeff Hartmann <jhartmann@valinux.com>
To: michdaen@iiic.ethz.ch
Cc: dri-devel@lists.sourceforge.net, linuxppc-dev@lists.linuxppc.org
Subject: Re: [Dri-devel] PPC Lockup (ati-pcigart-branch)
Date: Fri, 19 Jan 2001 09:40:30 -0700 [thread overview]
Message-ID: <3A686DFE.9030308@valinux.com> (raw)
In-Reply-To: 3A67B401.8282A00F@relog.ch
Michel Dänzer wrote:
> [CC'ing linuxppc-dev, hopefully someone there knows what might be up...]
>
> This is where it dies:
>
>
> /* FIXME: We should really have a kernel call for this...
> */
> entry->virtual = __vmalloc( (pages << PAGE_SHIFT),
> GFP_KERNEL,
> PAGE_KERNEL);
>
> printk("Checkpoint 2\n");
>
>
> Checkpoint 2 is never reached, the machine is absolutely dead.
>
>
> Michel
>
>
Since your running through klogd, this might not be 'exactly' where you
die. I would be TERRIBLY surprised if you died here. One thing you
have to remember about kernel debugging is that you can't always trust
what is in the log. Here is a technique that works for me when I'm
unsure of a piece of code:
Do what I suggested first, if it finds a likely problem, then great
(printk's on every line of a function).
When you get a general area where there is a failure, comment out every
line of code after that.
Line by line put the code back in.
This will help you find the hang.
This is a very common way of debugging kernel code with hangs. There
are other alternatives.
Setup a serial console, and turn of syslogd/klogd. This will give you
almost immediate information if you keep the output small (i.e., no
logging of lots of loop iterations or other high output stuff.) This is
one useful tool for kernel debugging.
If through the serial console you get an Oops message, you can use
ksymoops to find out what section of code was executing right before the
Oops. You have to do objdump usually to figure out which line of C code
caused the problem, unless the logic of the asm makes it obvious.
(i.e., I only do those types of operations on line X.)
I dunno if the kgdb patch works on powerpc, but you might try it. You
could single step through this code since your not at a point where
interrupts are disabled.
Unfortunately kdb (built-in kernel debugger) does not work on the
powerpc. It is REALLY useful when your debugging code when interrupts
are disabled, but it only works on ia64 and ia32 currently. I
personally like it alot more then kgdb, even though it has some
limitations kgdb doesn't.
Hope this helps,
-Jeff
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
next prev parent reply other threads:[~2001-01-19 16:40 UTC|newest]
Thread overview: 58+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-01-19 3:26 PPC Lockup (ati-pcigart-branch) Michel Dänzer
2001-01-19 3:55 ` Dan Malek
2001-01-19 6:53 ` [Dri-devel] " Gareth Hughes
2001-01-19 16:48 ` Jeff Hartmann
2001-01-19 17:24 ` Dan Malek
2001-01-20 0:45 ` Gareth Hughes
2001-01-19 16:40 ` Jeff Hartmann [this message]
2001-01-19 17:11 ` [Dri-devel] " Benjamin Herrenschmidt
2001-01-19 22:26 ` Chris Emerson
2001-01-19 22:59 ` Benjamin Herrenschmidt
2001-01-19 23:43 ` Chris Emerson
2001-01-20 1:38 ` Benjamin Herrenschmidt
2001-01-20 13:21 ` Michael Schmitz
2001-01-20 16:00 ` Benjamin Herrenschmidt
2001-01-20 17:03 ` Michael Schmitz
2001-01-20 2:46 ` Michel Dänzer
2001-01-20 4:17 ` Michel Dänzer
2001-01-22 9:44 ` Michel Dänzer
2001-01-22 17:59 ` Roman Zippel
2001-01-22 18:18 ` Michel Dänzer
2001-01-22 18:54 ` Roman Zippel
2001-01-22 19:39 ` Dan Malek
2001-01-22 20:08 ` Michel Dänzer
2001-01-22 20:30 ` Jeff Hartmann
2001-01-22 21:23 ` Roman Zippel
2001-01-22 23:12 ` Frank Rowand
2001-01-22 21:31 ` Dan Malek
2001-01-22 21:48 ` Jeff Hartmann
2001-01-22 22:15 ` Roman Zippel
2001-01-23 16:14 ` Mike Beede
2001-01-22 22:31 ` Roman Zippel
2001-01-23 0:24 ` Dan Malek
2001-01-23 2:28 ` Takashi Oe
2001-01-23 2:40 ` Dan Malek
2001-01-23 4:40 ` Ralph Metzler
2001-01-23 5:48 ` Takashi Oe
2001-01-23 11:24 ` Roman Zippel
2001-01-23 0:34 ` Frank Rowand
2001-01-23 0:43 ` Frank Rowand
2001-01-23 11:32 ` Roman Zippel
2001-01-22 20:43 ` Roman Zippel
2001-01-22 21:07 ` Jeff Hartmann
2001-01-22 17:33 ` Dan Malek
2001-01-22 17:38 ` Jeff Hartmann
2001-01-22 17:38 ` Gareth Hughes
2001-01-22 17:43 ` Michel Dänzer
2001-01-22 18:36 ` Dan Malek
2001-01-22 18:44 ` Jeff Hartmann
2001-01-22 18:47 ` Michel Dänzer
2001-01-22 21:13 ` Dan Malek
2001-01-22 21:58 ` Roman Zippel
2001-01-22 23:48 ` Paul Mackerras
2001-01-23 0:13 ` Dan Malek
2001-01-20 13:15 ` Michael Schmitz
2001-01-19 17:11 ` Wolfgang Denk
-- strict thread matches above, loose matches on Subject: below --
2001-01-23 3:34 Iain Sandoe
2001-01-23 6:49 Robert E Brose II
2001-01-23 7:01 ` Geert Uytterhoeven
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=3A686DFE.9030308@valinux.com \
--to=jhartmann@valinux.com \
--cc=dri-devel@lists.sourceforge.net \
--cc=linuxppc-dev@lists.linuxppc.org \
--cc=michdaen@iiic.ethz.ch \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).