I can see the problem right in arch/ppc/mm/ppc_mmu.c, in the MMU_init_hw
function. The code goes:
if ((cur_cpu_spec[0]->cpu_features & CPU_FTR_HPTE_TABLE) == 0)
return;
But later on there is code to set hash_page[0] = 0x4e800020. Instead
of returning it should execute that else clause, and make hash_page return.
After making that change the problem appears fixed, at long last. It wasn't
buggy hardware at all, it *was* a bug in the linux kernel.
-Dave
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
David Ashley wrote:
I can see the problem right in arch/ppc/mm/ppc_mmu.c, in the MMU_init_hw
function. The code goes:
if ((cur_cpu_spec[0]->cpu_features & CPU_FTR_HPTE_TABLE) == 0)
return;
But later on there is code to set hash_page[0] = 0x4e800020. Instead
of returning it should execute that else clause, and make hash_page return.
After making that change the problem appears fixed, at long last. It wasn't
buggy hardware at all, it *was* a bug in the linux kernel.
Hmm, it seems to be ok in the linux_2_4_devel tree:
http://ppc.bkbits.net:8080/linuxppc_2_4_devel/anno/arch/ppc/mm/ppc_mmu.c@1.4?nav=index.html|src/.|src/arch|src/arch/ppc|src/arch/ppc/mm
Does this mean that the linux_2_4 tree is less up-to-date?
Wolfgang.
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/