On Thu, 20 Feb 2025, Jd Lyons wrote:
Making some progress with spm as far as getting some useful debug info.
I seem to be raising an exception state when Mac OS X 10.4.11 Kernel loads and tries to reset and wake the additional cores
qemu-system-ppc64-unsigned: info: Core0: openpic_update_irq: IRQ 255 is disabled qemu-system-ppc64-unsigned: info: Core0: openpic_update_irq: IRQ 255 is already inactive qemu-system-ppc64-unsigned: info: Core0: Set IVPR 255 to 0x80000000 -> 0x80000000 qemu-system-ppc64-unsigned: info: Core0: openpic_gbl_write: addr 0x10e0 <= 000000ff qemu-system-ppc64-unsigned: info: Core0: openpic_gbl_write: addr 0x1020 <= 20000000 qemu-system-ppc64-unsigned: info: Core0: openpic_cpu_write_internal: cpu 0 addr 0x80 <= 0x00000000 qemu-system-ppc64-unsigned: info: Core0: openpic_cpu_write_internal: set CPU 0 ctpr to 0, raised 0 servicing 0 qemu-system-ppc64-unsigned: info: Core0: openpic_cpu_write_internal: Lower OpenPIC INT output cpu 0 due to ctpr qemu-system-ppc64-unsigned: info: Core0: openpic_cpu_write_internal: cpu 1 addr 0x1080 <= 0x00000000 qemu-system-ppc64-unsigned: info: Core0: openpic_cpu_write_internal: set CPU 1 ctpr to 0, raised 0 servicing 0 qemu-system-ppc64-unsigned: info: Core0: openpic_cpu_write_internal: Lower OpenPIC INT output cpu 1 due to ctpr qemu-system-ppc64-unsigned: info: Core0: openpic_cpu_write_internal: cpu 2 addr 0x2080 <= 0x00000000 qemu-system-ppc64-unsigned: info: Core0: openpic_cpu_write_internal: set CPU 2 ctpr to 0, raised 0 servicing 0 qemu-system-ppc64-unsigned: info: Core0: openpic_cpu_write_internal: Lower OpenPIC INT output cpu 2 due to ctpr qemu-system-ppc64-unsigned: info: Core0: openpic_cpu_write_internal: cpu 3 addr 0x3080 <= 0x00000000 qemu-system-ppc64-unsigned: info: Core0: openpic_cpu_write_internal: set CPU 3 ctpr to 0, raised 0 servicing 0 qemu-system-ppc64-unsigned: info: Core0: openpic_cpu_write_internal: Lower OpenPIC INT output cpu 3 due to ctpr<—exception state starts here and terminal output ends after the kernel tries to enable the additional cores but accesses the non-existent L2 CR( SPR 1012 )
Is there anyting inbetween here and the logs below? It's hard to tell what happens if you don't include logs and the patches you're using.
Raise exception at 00000000fff10698 => DSI (2) error=00 Raise exception at 00000000fff17098 => ISI (3) error=40000000 Raise exception at 00000000fff0ad08 => DSI (2) error=00 Raise exception at 00000000fff171f4 => DSI (2) error=00 Trying to read invalid spr 1012 (0x3f4) at 0000000000092884 <———————Here from the qemu log that we raise an exception state when the kernel tries to read the L2 cache cr
Do you get this same message when booting with only one CPU? I think accessing L2 cache control is not related to SMP so you could see this without -smp and if that works maybe it's not a problem. But it could be SMP needs something else with the cache that's not emulated and it crashes due to that. You'd have to check the CPU docs what this register does and see what the kernel tries to do then check what QEMU does and correct if needed. (And stick to -smp 2 at first, I'll ignore anything with more than 2 CPUs from now on.)
Raise exception at 00000000000af72c => SYSCALL (8) error=00 syscall r0=0000000000007ff4 r3=0000000000000000 r4=0000000000000000 r5=0000000000000000 r6=0000000000000000 r7=0000000000000000 r8=0000000072696e67 nip=00000000000af72c
While syscall is called exception this is just how it's implemented on PPC CPUs, getting these are normal when executing the 'sc' opcode which is when something calls the kernel so seeing a lot of these just means the system is running and something accessing the kernel. Unfortunately it can flood the log and make it harder to spot the relevant info there so maybe you can filter it out in some way.
Regards, BALATON Zoltan