What does the message just before the BUG messages say about coherency?


        if (devtree_coherency != KERNEL_COHERENCY) {
                printk(KERN_ERR
                        "kernel coherency:%s != device tree_coherency:%s\n",
                        KERNEL_COHERENCY ? "on" : "off",
                        devtree_coherency ? "on" : "off");
                BUG();
        }

kernel coherency:off != device tree_coherency:on

I can confirm the same problem with kernel-2.6.31-0.38.rc1.git7.fc11.ppc on my iMac G4 (PowerPC G4 7450). On boot, the kernel fails with the message

kernel coherency:off != device tree_coherency:on

I have compiled my own kernel and switched off the option CONFIG_AMIGAONE. After booting this custom kernel everything works fine. The CONFIG_AMIGAONE triggers the CONFIG_NOT_COHERENT_CACHE option which is the root cause of the bug.

Unfortunatelly I have no clue how to have CONFIG_AMIGAONE on and still keep CONFIG_NOT_COHERENT_CACHE off in the same kernel image.

I have a g4 here that also fails to boot with the 2.6.31 rawhide kernels... 
I don't see an oops though, just: (typed in by hand, so forgive typos): 

Hierachial RCU implementation. 
NR_IRQS: 512
mpic: Setting to MPIC " MIPC 1    " version 1.2 at 80040000, max 4 CPUs
mpic: ISE size: 64, shift: 6, mask: 3f
mpic Initializing for 64 sources 
GMT Delta read from XPARM: 0 minutes, DST: off
clocksource: timebase multi[7827fcb1 shift[22] registered
Console: colour dummy device 80x25
console handover: boot [udby01 -> real [tty0]


Moveable zone start PFN for each node
early_node_map[1] active PFN ranges
    0: 0x00000000 -> 0x00030000
Built 1 zonelists in Zone order, mobility grouping on. Total pages: 195072
Kernel command line: ro
PID hash table entries: 4096 (order: 12, 16384 bytes)
Dentry cache hash table entries: 131072 (order: 7, 524288 bytes)
inode-cache hash table entries: 65536 (order: 6, 262144 bytes)
allocated 3932160 bytes of page_cgroup 
please try 'cgroup_disable=memory' option if you don't want memory cgroups
Memory: 733104k/786432k available (7756k kernel code, 52720k reserved, 1776k data, 6495k bss, 364k init)
kernel virtual memory layout: 
     * 0xffef000.0xfffff000   : fixmap
     * 0xff00000.0xffc000     : highmem PTSs

and it's hung. F11 kernel works fine. 
Is this likely this bug? Or something else? 
I can try a kernel without the config from comment #3 I suppose.

(In reply to comment #4)

It's hard to say whether this is the same/related bug or a completely different bug. To be sure, try a custom kernel with the options CONFIG_AMIGAONE and CONFIG_NOT_COHERENT_CACHE disabled. Then you can tell whether there is some relation with coherency setting.

I tried here without those and still got the hang, so I guess I am seeing something else. ;( 
I can file a new bug on it.

You know, it might also be that AmigaOne requires cache coherency to be off and iBooks require it to be on and since CONFIG_NOT_COHERENT_CACHE can only have one position without hacking on the kernel (unsure if easily done even then, theoretically could be done with having the setting overridable by kernel boot parameter), it might be impossible to support both on any one kernel. Probably a good idea to forward the bug upstream to get kernel devs' opinion on how it should be done.

(In reply to comment #7)

I have never said that removing the support for AmigaOne is the way to go. The support for AmigaOne was probably introduced deliberately into rawhide kernel, not by an accident. However, rendering the kernel unbootable on machines like iBook and iMac G4, where previous versions of Fedora worked perfectly, is also not a good outcome.

After examining the kernel sources I believe that the kernel can be modified to support both cache coherent and cache non-coherent machines at the same time, replacing the various "#ifdef CONFIG_NOT_COHERENT_CACHE" by run-time branching (there are only about 42 of them, plus some dependencies) with a negligible performance penalty. If nobody else has this in focus I'll try to create a patch myself later (I'm in a time pressure right now).

Another solution would be to provide two kernel packages (similarly as we have PAE and non-PAE kernels on x86).

Do note that I said without hacking the kernel. Implementing run-time branching downstream definitely counts as kernel hacking. This is why I said it might be a good idea to report the bug upstream and ask if you're supposed to be able to have support for both AmigaOne and PowerPC at the same time (which would imply this is a bug that should get fixed somehow upstream, whether it be done with run-time branching or not) or if you really are supposed to have separate kernels for both (which would imply this is a feature that should be sorted out in the distro by providing two kernels). And no, I never said removing support for either is the way to go myself either.

This bug was discussed at the Alpha blocker review meeting today. We tentatively agreed that this should be set as an Alpha blocker, and the appropriate strategy for the Alpha should be to disable AmigaOne support to ensure Mac hardware works OK for the Alpha release, as Mac hardware is far more prevalent.

For the final release we'd support Martin's proposed kernel code fix, if it can be cleanly implemented and upstreamed.

Setting to block f12alpha.

-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

Should be fixed by 2.6.31-0.118.rc5 (by disabling AMIGAONE).

Closing bug for now. We never had AmigaOne support before; if people want to make it work in a general-purpose kernel we'll happily enable it when they do (at an appropriate point in the release cycle).