On Feb 19, 2025, at 12:52 PM, BALATON Zoltan <balaton@eik.bme.hu> wrote:
On Wed, 19 Feb 2025, Jd Lyons wrote:
This is the patch against the current master of qemu, it should apply clean now, but things changed a little a few days ago and I had to fix the patch.
[patch cut]
I’m thinking we already had a race condition on mac99,via=pmu and smp just made it worse.
What makes you think that?
The IPI code in OpenPIC likely needs some work too to clear some issues with smp.
The openpic code apparently works with the ppce500 machine with multiple CPUs so unless the Mac does something different or has a different openpic implementation it should be generally working even with SMP so I'm not sure it's within openpic or somewhere else. (Although e500 uses a different variant so it could be the problem is only with the variant Mac machines use. This would be selected by the mpic_version in openpic emulation so code guarded by that could be inspected.)
I’ll have to check, I think the race condition is there even without these patches, or more CPUs trying to come out of reset, causes the race condition.
Thanks for pointing out the e500 machine I’ll look into the code and see if I can glean anything from it.
These patches are NOT Ready For Primetime by any means, I didn’t write them, they came from the list and emasculation forums.
Who wrote the patch? If they are not cc'd not much use to comment on it. I also did not find the discussion on the emaculation.com/forum so can't guess how you ended up with this patch.
It was Andrew R., he posted the patch to qemu in the thread you two had last year at Qemu-ppc mailing list of the same name as this subject you pointed me too, but I had already read to start this In the first place. I thought I was replying to that thread over there but I must have started a duplicate thread. He posted the Openbios patch in a code box in the qemu subform at Emacultion.
Not sure that link will serve the list.
I’ve looked them over and tested them and made a bunch of changes trying to get IDE working so we can boot an OS, but no luck, the IRQ storm and race condition screws up everything but video and you can’t mount any media on the IDE bus once you load a kernel, even OS 9’s nonaKernel.
Set debug to true in the openpic.c and you’ll get spammed with the IRQ storm.
It's not an error in itself to see a lot of interrupts especially when loading something from a disk where in PIO mode you can get an interrupt for each sector or transfer so the question is rather if these interrupts end up at the right CPU and handled there correctly. Hopefully Linux would log if there was something off but I don't know and haven't seen the logs.
I also don't see anything in the patch to connect the GPIO to CPU reset. How did you solve the stuck CPU problem then?
I can’t figure out if the CPUs have conflating IRQs or the extra cpus have conflicting IRQs with the systems bus items, but IRQ 37 seem to hang in a loop while in Openbios and IRQ 13( IDE ) seem to hang in a loop while booting a kernel. I’m not sure I ever get additional cpus fully working, I stared the additional CPUs without them halted, but that made the race condition so fast I can’t even load a full boot loader to get a kernel up before IDE dies.
I did see 800% cpu usage out of qemu-system-ppc64 and it dipped down around 500% before the system just hung. So 5 cores of 8 were likely stuck in the race condition.
The additional cores will respond to IRQ/Interrupt changes, or that’s what the log shows.
I saw this before 10 or so years ago when I tried to hack in smp support. All the cores just maxed out all the time and you could not load a boot loader from Openbios.