From: Arnd Bergmann <arnd@arndb.de>
To: michael@ellerman.id.au
Cc: linuxppc-dev@ozlabs.org, Paul Mackerras <paulus@samba.org>
Subject: Re: [PATCH 6/16] cell: abstract spu management routines
Date: Tue, 14 Nov 2006 10:55:21 +0100 [thread overview]
Message-ID: <200611141055.22317.arnd@arndb.de> (raw)
In-Reply-To: <1163475880.8048.78.camel@localhost.localdomain>
On Tuesday 14 November 2006 04:44, Michael Ellerman wrote:
> OK, back to the task at hand :) =A0For the moment I'd rather see you leave
> out dump_data_fields(), as neither HV or baremetal implementations do
> anything. Just put the offending xmon code inside an #ifdef
> CONFIG_PPC_CELL_NATIVE. eg:
>=20
> Index: cell/arch/powerpc/xmon/xmon.c
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> --- cell.orig/arch/powerpc/xmon/xmon.c =A02006-11-14 14:43:11.000000000 +=
1100
> +++ cell/arch/powerpc/xmon/xmon.c =A0 =A0 =A0 2006-11-14 14:42:35.0000000=
00 +1100
> @@ -2807,12 +2807,11 @@ static void dump_spu_fields(struct spu *
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 in_be32(&spu->problem->sp=
u_status_R));
> =A0 =A0 =A0 =A0 DUMP_VALUE("0x%x", problem->spu_npc_RW,
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 in_be32(&spu->problem->sp=
u_npc_RW));
> +#ifdef CONFIG_PPC_CELL_NATIVE
> =A0 =A0 =A0 =A0 DUMP_FIELD(spu, "0x%p", priv1);
> -
> - =A0 =A0 =A0 if (spu->priv1) {
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 DUMP_VALUE("0x%lx", priv1->mfc_sr1_RW,
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 in_be64(&sp=
u->priv1->mfc_sr1_RW));
> - =A0 =A0 =A0 }
> + =A0 =A0 =A0 DUMP_VALUE("0x%lx", priv1->mfc_sr1_RW,
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 in_be64(&spu->priv1->mfc_sr=
1_RW));
> +#endif
Oops. Null pointer dereference.
You can't do this if you want to compile in both native and PS3PF
support in a single kernel. I think your original code that prints
priv1 and the sr1 only if priv1 exists is fine on both ways.
Arnd <><
next prev parent reply other threads:[~2006-11-14 9:55 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-11-10 20:01 [PATCH 6/16] cell: abstract spu management routines Geoff Levand
2006-11-13 4:11 ` Michael Ellerman
2006-11-13 4:34 ` Geoff Levand
2006-11-14 2:01 ` Michael Ellerman
2006-11-14 2:56 ` Geoff Levand
2006-11-14 3:13 ` Michael Ellerman
2006-11-14 11:32 ` Geoff Levand
2006-11-14 3:44 ` Michael Ellerman
2006-11-14 9:55 ` Arnd Bergmann [this message]
2006-11-14 10:50 ` Geoff Levand
2006-11-15 0:07 ` Michael Ellerman
2006-11-15 0:47 ` Geoff Levand
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=200611141055.22317.arnd@arndb.de \
--to=arnd@arndb.de \
--cc=linuxppc-dev@ozlabs.org \
--cc=michael@ellerman.id.au \
--cc=paulus@samba.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 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).