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. El mié, 1 feb 2023 a las 12:32, Damien Zammit (<dam...@zamaudio.com>) escribió: > Hi Almu, > I removed the slave main function and instead called the cpu launch first > thread directly, see mpdesc. Of course, I have been testing the scheduler > with all cpus. Unfortunately it is currently stuck in machine idle > occasionally with interrupts off on one or more cpu and the first task dies > for some reason thus never boots, but the timers are working and the TLB > coherency interrupt seems to work via calling IPI to irq 251. It could use > some testing and more eyes on the code. > > We are nearly there! > > Damien > > > Sent from ProtonMail mobile > > > > -------- Original Message -------- > On 1 Feb 2023, 9:52 pm, Almudena Garcia < liberamenso10...@gmail.com> > wrote: > > > > However, with ncpus>1 and apic enabled, there are warnings spewed > > at beginning of gnumach regarding cpu_number, but doesnt prevent > > continuing to start of boot process. > > :-) > > Then, the next step (added to little refactors) will be add the APs to > scheduler, using `slave_main()` function. > After this, the AP will be available to the scheduler, which can assign > process (or threads) to these. > > El mié, 1 feb 2023 a las 11:27, Damien Zammit (<dam...@zamaudio.com>) > escribió: > >> This has been rebased onto master and reworked to address review. >> >> Same tests applied as last time, same results as last time. >> >> However, with ncpus>1 and apic enabled, there are warnings spewed >> at beginning of gnumach regarding cpu_number, but doesnt prevent >> continuing to start of boot process. >> >> Damien >> >> >> >>
