Fixes smp_call_function (again)
authorBarret Rhoden <brho@cs.berkeley.edu>
Mon, 12 Jan 2015 17:13:45 +0000 (12:13 -0500)
committerBarret Rhoden <brho@cs.berkeley.edu>
Mon, 12 Jan 2015 17:13:45 +0000 (12:13 -0500)
commitdba684161574d1dc700050b304dac4770d01a909
treedab1ea1cac73ffe64e05cf037e4682a096f9eb61
parent2e856c58ec2c091ff11e2f110d1934d8830fe2bb
Fixes smp_call_function (again)

2e856c58 was wrong; past-barret was right.  It's a checklist, so you tick off
items as they are done.  The confusing part when debugging was that the IRQ
handlers were firing, but were not downing the checklist.

The root of the problem was that the SMP_CALL IRQ numbers didn't line up with
the "clever" initialization routine used for the handler wrappers.  A while
back I reorganized the x86 IRQ vectors and moved SMP_CALL0 to 224 from 240.
The initialization didn't change, so the smp_call vectors were still 240.  240
happened to be the timer IRQ, which means an smp_call_function would run on the
timer tick too.  The main thing was that the check for downing the checklist
didn't happen, since it expected 224-228, so the checklist would never clear.
That appeared like the waiting code was wrong, which it was not.
kern/arch/x86/smp_boot.c
kern/arch/x86/trap.h
kern/src/atomic.c