My local branch is mixed with attempted work arounds that just made the IRQ situation worse, this is the original patch to Openbios…
diff --git a/arch/ppc/qemu/init.c b/arch/ppc/qemu/init.c index 253394c..7b7b09d 100644 --- a/arch/ppc/qemu/init.c +++ b/arch/ppc/qemu/init.c @@ -348,8 +348,9 @@ cpu_add_pir_property(void) unsigned long pir;
asm("mfspr %0, 1023\n" - : "=r"(pir) :); + : "=r"(pir) :);; PUSH(pir); + printk("Pir = %lu \n", pir); fword("encode-int"); push_str("reg"); fword("property"); @@ -381,9 +382,9 @@ static void cpu_g4_init(const struct cpudef *cpu) { cpu_generic_init(cpu); - cpu_add_pir_property(); + //cpu_add_pir_property();
- fword("finish-device"); + //fword("finish-device"); }
#ifdef CONFIG_PPC_64BITSUPPORT @@ -1073,13 +1074,23 @@ arch_of_init(void) push_str("reg"); fword("property");
+ int i; + + for (i= 0; i<temp; i++) { cpu = id_cpu(); cpu->initfn(cpu); - printk("CPU type %s\n", cpu->name);
- snprintf(buf, sizeof(buf), "/cpus/%s", cpu->name); + printk("CPU type %s\n", cpu->name); + snprintf(buf, sizeof(buf), "/cpus/%s", cpu->name); + PUSH(i); + fword("encode-int"); + push_str("reg"); + fword("property"); + fword("finish-device"); + } ofmem_register(find_dev("/memory"), find_dev(buf)); node_methods_init(buf); +
#ifdef CONFIG_RTAS /* OldWorld Macs don't have an /rtas node. */
Let me do some house keeping and I’ll get you the diff for Qemu….
On Feb 19, 2025, at 4:40 AM, Mark Cave-Ayland mark.cave-ayland@ilande.co.uk wrote:
On 19/02/2025 06:50, Jd Lyons via OpenBIOS wrote:
I can’t figure out this race condition but it causes an IRQ storm. I feel like I’m in the old days of PC’s when to had IRQ conflicts and had to sort them yourself deep in the bios. As a Mac person I only had to deal with that on a few friends PC’s. Starting the second CPU in a on state rather than halted just makes the race condition worse, twice as fast, and Openbios doesn’t want to get to the prompt, but throwing 3, 8, or 9 CPUs at it in a running state gets me to the prompt, but it ignores -prom-env setting with anything more that three. 300% cpu usage just speeds up the race condition and IRQ storm so IDE craps out before you can load BootX or a linux kernel. Then noting happens but the IRG storm and GPIO 1 asserting 0, likely to all the other CPUs, and that is likely the race conditions and pulling that low trigger the IRQ storm. I can’t make it stop, I even tied all IRQ and Interrupts handling to CPU0, and that working until the OS Kenral loads and starts sending stuff to CPU1, which is still in a halted state unless I start it with my hack. Even with only CPU0 dealing with IRQs and Interrupts the race condition is still there and the IRQ storm. I have to figure out why GPIO 1keeps getting triggered in a loop to pull low????
Specifically can you narrow it down to which patch or patches to QEMU/OpenBIOS cause the IRQ storm to start? It's almost impossible to provide some pointers without seeing all your changes. Perhaps push them to github or a somewhere similar?
ATB,
Mark.