to arrive here referencing the kernel_lev1map without having the
RESERVED ASN -- another CPU may have caused pmap_lev1map_destroy()
to be called, and that routine only invalidates the ASN for the
CPU that called it. So, in the MULTIPROCESSOR case, simply assign
the RESERVED ASN if we reference the kernel_lev1map rather than
asserting that we already have the RESERVED ASN. Thanks to Bill
Sommerfeld for helping me track down the problem.
Also add a new IPI that causes a CPU to re-activate its address
space if the pmap it's using changes level 1 maps (this probably
won't happen very often, but it's correct to have it).
This makes Alpha MP kernels boot multiuser. In fact, this commit
is being made from my dual-CPU AlphaServer 1200 running an MP kernel.
and place the definition in <machine/types.h>. This can now be used
as a flag to indicate whether or not <machine/intr.h> can be included
to get the generic soft interrupt API.
pci_attach_args *" instead of from four separate parameters which in
all cases were extracted from the same "struct pci_attach_args".
This both simplifies the driver api, and allows for alternate PCI
interrupt mapping schemes, such as one using the tables described in
the Intel Multiprocessor Spec which describe interrupt wirings for
devices behind pci-pci bridges based on the device's location rather
the bridge's location.
Tested on alpha and i386; welcome to 1.5Q
XXX if you have libc after citrus locale import, please recompile libc,
and your applications that use mbstate_t (rather rare). really sorry
for the mess.
multiprocessor support:
- Implement MP-safe halt.
- Make the FPU saving code more like Bill's on the i386 MP branch.
XXX This code will no doubt be revisited again.
- Pass the cpu_info and trapframe to IPI handlers, saving some work
in the handlers themselves, and also making it possible for the
"pause" handler to reference register state for DDB.
- Add "machine cpu" to DDB, making it possible to reference other
CPUs registers (and thus get e.g. a traceback) from whichever
CPU is actually running the debugger.
- Garbage-collect "machine halt" and "machine reboot" DDB commands.
They don't have a prayer of working properly in multiprocessor
kernels, and didn't really work all that well in uniprocessor kernels.
as normal device interrupts. Because of this, we won't get IPIs while
servicing such interrupts. This can lead to the following deadlock
scenario as reported by Bill Sommerfeld:
- Process runs on cpu1, but has FP state on cpu0.
- Process executes FP-using insn, causing an FP trap, which causes
the kernel lock to be acquired.
- At roughly the same time, cpu0 receives a device interrupt, and attempts
to acquire the kernel lock, which blocks since cpu1 already has it.
- cpu1 sends cpu0 a SYNCH FPU IPI, and waits for cpu0 to release its
FP state.
- Since cpu0 cannot notice the IPI until it has processed the device
interrupt, which it cannot do because it cannot acquire the kernel
lock, we have deadlock.
Solve the problem by adding a spinlock interlock release hook which
checks for pending IPIs and processes them.
Idea from Bill Sommerfeld.
