Call critical_enter/critical_exit around (fast) interrupt handlers. All
non-threaded interrupts are fast, and the threaded interrupt scheduler is
itself a fast interrupt.
Assert that an interrupt handler we are about to call is non-zero.
Be paranoid about restoring the users global registers. Do it as the
last thing before switching to alternate globals (when we magically get
our preloaded registers back), and do it with interrupts disabled. Any
kind of kernel trap when the globals are not setup properly is bad news.
Don't save and restore the kernel g6, it invariably points to the current
pcb now.
data word in an interrupt packet is non-zero, it points to code to execute
to handle the ipi, so jump to it instead of enqueueing the packet. It
is unclear if we will need queued ipis.
Interrupt g7 now points to pcpu, instead of to the per-cpu interrupt queue
itself, so use that instead. Interrupt g6 is no longer reserved.
parameters needed for smp support.
If we are not the boot processor, jump to the smp startup code instead.
Implement a per-cpu panic stack, which is used for bootstrapping both
primary and secondary processors and during faults on the kernel stack.
Arrange the per-cpu page like the pcb, with the struct pcpu at the end
of the page and the panic stack before it.
Use the boot processor's panic stack for calling sparc64_init.
Split the code to set preloaded global registers and to map the kernel
tsb out into functions, which non-boot processors can call.
Allocate the kstack for thread0 dynamically in pmap_bootstrap, and give
it a guard page too.
to the current pcb.
Remove interrupt global defines; they use PCPU_REG now.
Move ATOMIC_INC_INT here from exception.s, add ATOMIC_DEC_INT.
Add a KASSERT macro for use in assembler.
- The disktab was taken from etc.alpha.
- rc.sparc64 doesn't do anything right now.
- The ttys file has all the vty's commented out since we don't know how
those will work yet. Also, an entry is added for the Openfirmware
console device.
Submitted by: jake (partially)
instead of relying on the previous filters to be present.
Back out r1.125, as a reset is needed to unload any existing microcode,
(which clears the multicast addresses), as it is superceded by this change.
interaction between the leftright and number options.
PR: bin/23912
Reported by: "Stephen D. Spencer" <gladiatr@boneyard.lawrence.ks.us>
Obtained from: skimo@kotnet.org
filesystem using a block size of 8192. Since this seems unlikely to
be fixed soon (specifically in time for 4.5-RELEASE on the RELENG_4
branch), fall back to the old default block and frag sizes of 8192 and
1024 in sysinstall on the alpha.
Reported by: jhb
to recover its space into the previous partition. Revert 'D'elete
to not attempt to recover any space.
Do not auto-create /home as per release engineers decision (though
I think this is a mistake). However, all of this code will be
replaced later on anyway either with Jordan's stuff or with
some other sort of templater, so it isn't a big deal.
argument. Leave a compatibility shim for Delete_Chunk().
Implement DELCHUNK_RECOVER flag so sysinstall can ask libdisk
to recover space when deleting a chunk.
The first "synopsis" example has a "[/prefixlength]" which shouldn't
be there, since that stuff is part of the preceeding "address" as is
explained in the description of "address".
(The way it is now, 192.168.0.1/16/prefixlength would be a proper
operand. Note that "prefixlength" is not mentioned by name anywhere.)
PR: 32462
Submitted by: Gary W. Swearingen <swear@blarg.net>
(at least a new one) would expect the manual page to be called (even
if the device is lo#).
PR: 32453
Submitted by: Gary W. Swearingen <swear@blarg.net>
disklabel(8)'s "Reading the disk label" section starts out "To examine
or save the label on a disk drive,...". This is confusing. The given
command (disklabel [-r] disk) doesn't save anything (except to standard
out, but that should go without saying). It reads as if the command
might save something on the disk drive.
PR: 32452
Submitted by: Gary W. Swearingen <swear@blarg.net>
data without confirming the connection by issuing a recvmsg(2) [...]".
There's no such code in the kernel.
PR: 26861
Submitted by: Richard A Steenbergen <ras@e-gerbil.net>,
Tom Rhodes <darklogik@pittgoth.com>
