What cores do when they are idle

Discussions on more advanced topics such as monolithic vs micro-kernels, transactional memory models, and paging vs segmentation should go here. Use this forum to expand and improve the wiki!
User avatar
gravaera
Member
Member
Posts: 737
Joined: Tue Jun 02, 2009 4:35 pm
Location: Supporting the cause: Use \tabs to indent code. NOT \x20 spaces.

Re: What cores do when they are idle

Post by gravaera »

Didn't really properly read through, TBH, but I'm also having problems with booting APs. Kernel boots 3 successfully, and operates in single processor mode properly, but 4+ CPUs suddenly begins to manifest deadlocks. I could move on and just finish up, but I don't want to without first finding out what exactly is wrong. Lots of fun, so good luck with whatever is up with your AP booting :|
17:56 < sortie> Paging is called paging because you need to draw it on pages in your notebook to succeed at it.
rdos
Member
Member
Posts: 3276
Joined: Wed Oct 01, 2008 1:55 pm

Re: What cores do when they are idle

Post by rdos »

My only problem is that the PC restarts (probably tripple-faults). It sometimes restarts with 5 cores, and always restart with 6 cores. Once the system is booted, it is stable regardless if it has 2 or 5 cores running.
rdos
Member
Member
Posts: 3276
Joined: Wed Oct 01, 2008 1:55 pm

Re: What cores do when they are idle

Post by rdos »

After getting the IDE device-driver up (it's a SATA device, but setup to IDE emulation due to XP being installed, and it doesn't work to change mode to AHCI in the device-driver), I do experience some very probable scheduler-related faults. The server thread blocks on a signal with a timeout on core 1 (I know it is core 1 because FS on the stack points to core 1 being active as the call is made), but in the middle of blocking the thread, the timeout seems to occur, and then the thread starts executing on core 3 (very probably the core that received the timer interrupt) with SS:SP pointing at some "random" location, and then core 3 faults in the scheduler.

There is a need to make sure that a thread waiting for a signal (which may be sent from ISRs or timer-callbacks), cannot be rescheduled on a new core until the core executing it has saved the register context and has switched-over to it's scheduler stack.
Post Reply