3fa048c0a6
confirmation after sending off the startup IPIs. We simply moved on and setup the temporary stack address for the next CPU to be started. With this it was possible that the trampoline code did not manage to load the address before we overwrote it. So for configurations with more than two CPUs it was possible that two CPUs were setup to the same kernel stack which could have caused all sorts of things - most likely a tripple fault and a reboot. On real hardware this seems very unlikely but it was easily reproducible with QEMU and -smp >2. We now use the shared trampoline stack to implement a notification mechanism. The trampoline code will clear the stack location variable once it has loaded everything it needs from the trampoline stack. On the other side smp_boot_other_cpus() will wait for this variable to be cleared after it sent the startup IPIs so that it knows when it can safely move on and overwrite the area to boot the next CPU. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@23800 a95241bf-73f2-0310-859d-f6bbb57e9c96 |
||
|---|---|---|
| .. | ||
| boot | ||
| glue | ||
| kernel | ||
| ldscripts | ||
| libroot | ||
| runtime_loader | ||
| Jamfile | ||