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 (<liberamenso10...@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 (<dam...@zamaudio.com>) > escribió: > >> >> -------- Original Message -------- >> On 1 Feb 2023, 10:35 pm, Almudena Garcia < liberamenso10...@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 >> >> >> >>
