[boot_loader_openfirmware] panic: out of page table entries

[andreasf]

Booting Haiku CD on PowerMac G5 from OpenFirmware with boot cd:,\ppc\boot_loader_openfirmware results in panic:

Loading ELF
checking for memory...
0: empty region
1: empty region
2: empty region
3: base = 0x00000000, size = 536870912
4: empty region
5: empty region
6: base = 0x00000000, size = 1073741824
7: base = 0x40000000, size = 1
8: base = 0x00000000, size = 1073741824
9: empty region
10: empty region
11: empty region
total physical memory = 2560 MB
suggested page table size = 33554432
need new page table, size = 33554432!
MSR: 0x00003030
found 41 translations
found exception handlers!
found exception handlers!
found page table!
found exception handlers!
found exception handlers!
*** PANIC ***
out of page table entries! (you would think this could not happen in a boot loader...)
 ok
0 > 

[andreasf]

Is this related to the amount of memory installed? (3 GB vs. 384 MB on my G3)

Any constant I could tweak to fix or get past this issue?

[bonefish]

Replying to andreasf:

Is this related to the amount of memory installed? (3 GB vs. 384 MB on my G3)

Kind of.

Any constant I could tweak to fix or get past this issue?

This is actually a design problem of the PPC architecture. The "PowerPC Operating Environment Architecture Book III" says: "This can happen if too many hash collisions occur and there are more than 16 entries for the same primary/secondary pair of PTEGs. While this situation cannot be guaranteed not to occur for any size Page Table, making the Page Table larger than the minimum size (see Section 4.5.2) will reduce the frequency of occurrence of such collisions."

According to the debug output the page table size is 32 MB, which is the suggested minimum for up to 4 GB RAM. You could try to increase it. In src/system/boot/platform/openfirmware/arch/ppc/mmu.cpp:arch_mmu_init() just multiply suggestedTableSize by 2.

[andreasf]

local patch to tweak suggested page table size

[andreasf]

Replying to bonefish:

According to the debug output the page table size is 32 MB, which is the suggested minimum for up to 4 GB RAM. You could try to increase it. In src/system/boot/platform/openfirmware/arch/ppc/mmu.cpp:arch_mmu_init() just multiply suggestedTableSize by 2.

I tried multiplying by 2, 4, 8 - same error.

Also, after such a failure, on next boot attempt (now TFTP), I get:

Loading ELF

CLAIM failed
 ok
0 >

Is the bootloader maybe missing some cleanup for error cases like this?

[bonefish]

Replying to andreasf:

Replying to bonefish:

According to the debug output the page table size is 32 MB, which is the suggested minimum for up to 4 GB RAM. You could try to increase it. In src/system/boot/platform/openfirmware/arch/ppc/mmu.cpp:arch_mmu_init() just multiply suggestedTableSize by 2.

I tried multiplying by 2, 4, 8 - same error.

OK, then this is probably a bug. I guess someone will have to look into it. Personally I'm not so much interested in doing that ATM.

Also, after such a failure, on next boot attempt (now TFTP), I get:

Loading ELF

CLAIM failed
 ok
0 >

Is the bootloader maybe missing some cleanup for error cases like this?

I'm pretty sure the boot loader doesn't do any cleanup at all. If after some error it returns to the OF prompt, the only safe thing to do is a reset. If you mean you encounter the problem after a reset, then this sounds more like a OF bug.

[andreasf]

Replying to bonefish:

If you mean you encounter the problem after a reset, then this sounds more like a OF bug.

No, never encountered it directly after boot/reset, only after first failed boot attempt.

[kallisti5]

The CLAIM failed error is an Apple OF thing..

I know that if you fail booting an elf and attempt it again all hell breaks loose. (the same thing happens with NetBSD). Apple probably was not as interested in having reliable adhesion to the IEEE 1275-1994 standard... they just wanted OS X and OS 9 booting :)

Try a reset-all before booting another elf after a failure and disabling autoboot

[andreasf]

Independent of the page table issue, the physical map seems wrong - 3, 6, and 8 with same base 0x00000000, anonther of size 1, and 2.5 instead of 3 GB RAM.

The MMU mappings look weird too, similar to those before OpenBIOS r772 (we found differences between ppc and sparc), so I guess OF returns 64-bit physical and virtual addresses here.

[kallisti5]

This may be no longer valid after hrev42486. I fixed a bug where OpenFirmware was using 64-bit addresses on G5 systems.

Needs testing (and my G5 bit the dust long ago)