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.