The 2.6.29 kernel booted just fine (and 2.6.28, and 2.6.27...), but the 2.6.30
kernel does this right after openbios hands over control:
invalid/unsupported opcode: 00 - 12 - 00 (00009024) 0000938c 0
Which is usually qemu's way of saying "code jumped off into la-la land".
I bisected the problem in the linux kernel repository, and wound up here:
60ee031940c1b09c137b617a8829e2f081961fe0 is first bad commit
commit 60ee031940c1b09c137b617a8829e2f081961fe0
Author: Jeremy Kerr <[email protected]>
Date: Tue Feb 17 11:44:14 2009 +1100
powerpc/spufs: Use correct return value for spu_handle_mm_fault
Currently, spu_handle_mm_fault disregards the 'ret' variable and always
returns -EFAULT on error.
This change refactos spu_handle_mm_fault a little, to return the
ret variable as appropriate. This allows us to combine the error and
sucess paths.
Also, remove the #if-0-ed IS_VALID_EA() check, it has never been
used.
Signed-off-by: Jeremy Kerr <[email protected]>
Signed-off-by: Benjamin Herrenschmidt <[email protected]>
I'm building the kernel with the attached .config, and booting qemu with:
qemu-system-ppc -M g3beige -nographic -no-reboot -kernel "zImage-powerpc" -hda
"image-powerpc.sqf" -append "root=/dev/hda rw init=/usr/sbin/init.sh panic=1
PATH=/usr/bin console=ttyS0"
Here's a simpler qemu invocation so you don't need a root filesystem image to
test it. (If you get bootup messages on stdout, it's working, and if you get
an unsupported opcode message right after openbios hands over control, it's
not):
qemu-system-ppc -nographic -no-reboot -kernel zImage-powerpc \
-hda /dev/null -append "panic=1 console=ttyS0"
I'm testing with qemu svn 6657 (which is now qemu git 2d18e637e5ec), which is
the last version in the repository before some unrelated openbios changes
started a series of bugs that haven't quite been resolved yet. You can use
the v0.10.0 release if you prefer, but you'll have to update the openbios-ppc
image to the one from svn 6657.
I'm stumped. Help?
Thanks,
Rob
P.S. Is there a powerpc list I should have cc:'d this to? vger.kernel.org
just has kvm-ppc, no other "ppc" or "power". Google suggests ozlabs, but
their mailing lists only see to have cell, which this isn't...
--
Latency is more important than throughput. It's that simple. - Linus Torvalds
Hi Rob,
> I bisected the problem in the linux kernel repository, and wound up
> here:
>
> 60ee031940c1b09c137b617a8829e2f081961fe0 is first bad commit
> commit 60ee031940c1b09c137b617a8829e2f081961fe0
> Author: Jeremy Kerr <[email protected]>
> Date: Tue Feb 17 11:44:14 2009 +1100
>
> powerpc/spufs: Use correct return value for spu_handle_mm_fault
I think it's very unlikely that this commit would be causing the
problem, as qemu doesn't have any SPEs (they're specific to the Cell
architecture), which would be required to hit this code. Also, you're
not compiling with CONFIG_SPU_BASE, so the file that this changed
shouldn't even be built.
Perhaps try the bisect again?
> P.S. Is there a powerpc list I should have cc:'d this to?
> vger.kernel.org just has kvm-ppc, no other "ppc" or "power". Google
> suggests ozlabs, but their mailing lists only see to have cell, which
> this isn't...
[email protected] is the one you want for this:
https://lists.ozlabs.org/listinfo/linuxppc-dev
Cheers,
Jeremy
On Saturday 27 June 2009 21:33:09 Jeremy Kerr wrote:
> Hi Rob,
>
> > I bisected the problem in the linux kernel repository, and wound up
> > here:
> >
> > 60ee031940c1b09c137b617a8829e2f081961fe0 is first bad commit
> > commit 60ee031940c1b09c137b617a8829e2f081961fe0
> > Author: Jeremy Kerr <[email protected]>
> > Date: Tue Feb 17 11:44:14 2009 +1100
> >
> > powerpc/spufs: Use correct return value for spu_handle_mm_fault
>
> I think it's very unlikely that this commit would be causing the
> problem, as qemu doesn't have any SPEs (they're specific to the Cell
> architecture), which would be required to hit this code. Also, you're
> not compiling with CONFIG_SPU_BASE, so the file that this changed
> shouldn't even be built.
Yeah, it seemed odd. That's why I needed help. :)
> Perhaps try the bisect again?
Sorry about that. I suck at git.
Part of the reason is that git bisect assumes that "good" always comes before
"bad" in the repository, so if you're looking for the patch that _fixed_ a bug
(I.E. good == new and bad == old), you have to reverse 'em to humor git
bisect. I had to do that this time to patch an intermediate version that
build breaks, which "git bisect run" called "skip" on over a dozen times
without noticeable progress. If good and bad then mean the opposite on the
_next_ bisect, I tend to get 'em confused occasionally. (Especially when I've
hit three or more unrelated bugs in the same bisect run. In this case the
build break in kmap_atomic_prot, whatever memory glitch is corrupting the
squashfs root filesystem image and spamming the console about it, and this bug.
Oh, and the really _fun_ part is that the squashfs bug only reproduces about
half the time. If you run the same binary twice, sometimes it'll work and
sometimes it'll spam squashfs errors to the console. Wheee...)
Anyway, on something like my fifth attempt I managed to bisect it to:
28794d34ecb6815a3fa0a4256027c9b081a17c5f is first bad commit
commit 28794d34ecb6815a3fa0a4256027c9b081a17c5f
Author: Benjamin Herrenschmidt <[email protected]>
Date: Tue Mar 10 17:53:27 2009 +0000
powerpc/kconfig: Kill PPC_MULTIPLATFORM
CONFIG_PPC_MULTIPLATFORM is a remain of the pre-powerpc days and isn't
really meaningful anymore. It was basically equivalent to PPC64 || 6xx.
This removes it along with the following changes:
- 32-bit platforms that relied on PPC32 && PPC_MULTIPLATFORM now rely
on 6xx which is what they want anyway.
- A new symbol, PPC_BOOK3S, is defined that represent compliance with
the "Server" variant of the architecture. This is set when either 6xx
or PPC64 is set and open the door for future BOOK3E 64-bit.
- 64-bit platforms that relied on PPC64 && PPC_MULTIPLATFORM now use
PPC64 && PPC_BOOK3S
- A separate and selectable CONFIG_PPC_OF_BOOT_TRAMPOLINE option is now
used to control the use of prom_init.c
Signed-off-by: Benjamin Herrenschmidt <[email protected]>
Which suggested that the problem was the new CONFIG_PPC_OF_BOOT_TRAMPOLINE
symbol wasn't set, and once I switched that on it started working again.
> [email protected] is the one you want for this:
>
> https://lists.ozlabs.org/listinfo/linuxppc-dev
Cool! Is there a reason it's hidden? (Or at least not listed in either
vger.kernel.org's list info page or in the "Maling lists" page linked from
ozlabs.org's top level web page.) Just curious, I couldn't find it when I
looked in the obvious (to me) places.
Rob
P.S. Yes I tried google: top hit for "linux powerpc list" is penguinppc.org,
which links to mailing lists on the right which is the ozlabs.org page that
doesn't list linuxppc-dev. In fact the entire first page of google hits for
that search doesn't give a hint of the existence of that list, although some
of the later ones might if I clicked through more of them...
--
Latency is more important than throughput. It's that simple. - Linus Torvalds
On Mon, Jun 29, 2009 at 06:34:06PM -0500, Rob Landley wrote:
> Cool! Is there a reason it's hidden? (Or at least not listed in either
> vger.kernel.org's list info page
Because it's not hosted on vger :( ... I guess we're controll freaks! :D
> or in the "Maling lists" page linked from
> ozlabs.org's top level web page.)
Ahh this is becuase we're currently on the process of moving the lists to
"lists.ozlabs.org", there is an alias in place so the old address still works.
So at some level it's just bad timing :(
We'll do what we can to make this easier during the transition.
> Just curious, I couldn't find it when I
> looked in the obvious (to me) places.
Not to be flipant but it's in the MAINTAINERS file:
---
LINUX FOR POWERPC (32-BIT AND 64-BIT)
P: Benjamin Herrenschmidt
M: [email protected]
P: Paul Mackerras
M: [email protected]
W: http://www.penguinppc.org/
L: [email protected]
T: git git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc.git
S: Supported
---
> P.S. Yes I tried google: top hit for "linux powerpc list" is penguinppc.org,
> which links to mailing lists on the right which is the ozlabs.org page that
> doesn't list linuxppc-dev. In fact the entire first page of google hits for
> that search doesn't give a hint of the existence of that list, although some
> of the later ones might if I clicked through more of them...
Rats, not really sure what we can do about that :(
Yours Tony
On Mon, 2009-06-29 at 18:34 -0500, Rob Landley wrote:
> Which suggested that the problem was the new CONFIG_PPC_OF_BOOT_TRAMPOLINE
> symbol wasn't set, and once I switched that on it started working again.
What defconfig are you using? It sounds like maybe something should be
'select'ing OF_BOOT_TRAMPOLINE.
> > [email protected] is the one you want for this:
> >
> > https://lists.ozlabs.org/listinfo/linuxppc-dev
>
> Cool! Is there a reason it's hidden? (Or at least not listed in either
> vger.kernel.org's list info page or in the "Maling lists" page linked from
> ozlabs.org's top level web page.) Just curious, I couldn't find it when I
> looked in the obvious (to me) places.
It's not hidden, it's just in the process of moving from ozlabs.org to
lists.ozlabs.org - and it's a bit hard to find in the process. I've
updated the ozlabs.org page to point to it in the meantime.
It's also in maintainers :D
LINUX FOR POWERPC (32-BIT AND 64-BIT)
P: Benjamin Herrenschmidt
M: [email protected]
P: Paul Mackerras
M: [email protected]
W: http://www.penguinppc.org/
L: [email protected]
T: git git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc.git
S: Supported
cheers
On Mon, 2009-06-29 at 18:34 -0500, Rob Landley wrote:
>
> Which suggested that the problem was the new
> CONFIG_PPC_OF_BOOT_TRAMPOLINE
> symbol wasn't set, and once I switched that on it started working
> again.
Ah, I might have forgot to set it to default y...
> > [email protected] is the one you want for this:
> >
> > https://lists.ozlabs.org/listinfo/linuxppc-dev
>
> Cool! Is there a reason it's hidden? (Or at least not listed in
> either
> vger.kernel.org's list info page or in the "Maling lists" page linked
> from
> ozlabs.org's top level web page.) Just curious, I couldn't find it
> when I
> looked in the obvious (to me) places.
It's a glitch of the transition from ozlabs.org to lists.ozlabs.org for
lists... they haven't all moved over yet so it's still a bit messy.
> Rob
>
> P.S. Yes I tried google: top hit for "linux powerpc list" is
> penguinppc.org,
> which links to mailing lists on the right which is the ozlabs.org page
> that
> doesn't list linuxppc-dev. In fact the entire first page of google
> hits for
> that search doesn't give a hint of the existence of that list,
> although some
> of the later ones might if I clicked through more of them...
I'll check with Stephen if we can get the ozlabs.org page a link to the
new lists.ozlabs.org or something like that...
Cheers,
Ben.
On Tue, 2009-06-30 at 10:24 +1000, Michael Ellerman wrote:
> On Mon, 2009-06-29 at 18:34 -0500, Rob Landley wrote:
> > Which suggested that the problem was the new CONFIG_PPC_OF_BOOT_TRAMPOLINE
> > symbol wasn't set, and once I switched that on it started working again.
>
> What defconfig are you using? It sounds like maybe something should be
> 'select'ing OF_BOOT_TRAMPOLINE.
Right, pmac, pseries and chrp probably ... though I don't like select
for a user-visible option, I'd rather fix things if I inadvertently
forgot the "default y" here, after all, one may want to do a minimum
kdump kernel without prom_init.c in it.
Cheers,
Ben.
>
> > > [email protected] is the one you want for this:
> > >
> > > https://lists.ozlabs.org/listinfo/linuxppc-dev
> >
> > Cool! Is there a reason it's hidden? (Or at least not listed in either
> > vger.kernel.org's list info page or in the "Maling lists" page linked from
> > ozlabs.org's top level web page.) Just curious, I couldn't find it when I
> > looked in the obvious (to me) places.
>
> It's not hidden, it's just in the process of moving from ozlabs.org to
> lists.ozlabs.org - and it's a bit hard to find in the process. I've
> updated the ozlabs.org page to point to it in the meantime.
>
> It's also in maintainers :D
>
> LINUX FOR POWERPC (32-BIT AND 64-BIT)
> P: Benjamin Herrenschmidt
> M: [email protected]
> P: Paul Mackerras
> M: [email protected]
> W: http://www.penguinppc.org/
> L: [email protected]
> T: git git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc.git
> S: Supported
>
>
> cheers
> _______________________________________________
> Linuxppc-dev mailing list
> [email protected]
> https://lists.ozlabs.org/listinfo/linuxppc-dev
On Tue, 2009-06-30 at 20:50 +1000, Benjamin Herrenschmidt wrote:
> On Tue, 2009-06-30 at 10:24 +1000, Michael Ellerman wrote:
> > On Mon, 2009-06-29 at 18:34 -0500, Rob Landley wrote:
> > > Which suggested that the problem was the new CONFIG_PPC_OF_BOOT_TRAMPOLINE
> > > symbol wasn't set, and once I switched that on it started working again.
> >
> > What defconfig are you using? It sounds like maybe something should be
> > 'select'ing OF_BOOT_TRAMPOLINE.
>
> Right, pmac, pseries and chrp probably ... though I don't like select
> for a user-visible option, I'd rather fix things if I inadvertently
> forgot the "default y" here, after all, one may want to do a minimum
> kdump kernel without prom_init.c in it.
Yeah true. In that case there's not much to do, it's default y, and the
help text says "In case of doubt, say Y".
Rob, do you remember saying "no" to this option when it came up, or did
you run 'make <something defconfig>' and end up with it unset? The
latter would be a bug, the former would not :)
cheers