Re: [PATCH 0/5 gnumach] Progress with SMP revisited

[Almudena Garcia]

https://github.com/AlmuHS/GNUMach_SMP/blob/master/kern/sched_prim.c#L1243

Check this line, and the rest of the function. I think that it was a modification which i did with Samuel

El mié, 1 feb 2023 a las 12:57, Almudena Garcia (<liberamenso10000@gmail.com>) escribió:

In previous time, Samuel proposed me to set a "bound processor", to force that booting use only BSP, and the AP will be using once booting are finishing.

But I don't remember fine how to do it.

Also we found that ext2fs had a thread which was never assigned to any processor, but we never discover the reason.

Check latest commits of this branch, in which I working together with Samuel (who told me indications via IRC) in this.

https://github.com/AlmuHS/GNUMach_SMP/commits/wip

El mié, 1 feb 2023 a las 12:53, Damien Zammit (<damien@zamaudio.com>) escribió:

-------- Original Message --------
On 1 Feb 2023, 10:35 pm, Almudena Garcia < liberamenso10000@gmail.com> wrote:
Ok. Now I understand better. Maybe it's the same problem which I found in my first implementation: the AP was stuck, and the scheduler was sending all threads to the BSP.
Try to debug it using gdb, and checking the registers values in qemu monitor.


Believe me, I have tried a lot! I'm at a point where I could use some help. My old branch booted because the APs were in fact stuck as you described. But with this patchset we have APs servicing interrupts periodically and resting in idle loops.
This is very different to being stuck.

Please try it. It's likely to be a few lines of code away from being bootable but I can't seem to figure it out yet.

Damien