Put in a little comment explaining why it went away.
Re-enable it in the case there an exisiting process is just splitting
off its address space and file descriptors.
(I donpt think anything uses that code but it needs some sort of locking
and this does the job.
Reviewed by: Davidxu, alc, others
MFC after: 3 days
CPUs to make sure idle threads are evicted from the softc before returning
from acpi_cpu_shutdown(). However, this is unnecessary since stop_cpus()
handles this for itself and at this point it's possible that our IPI will be
blocked (interrupts disabled).
Thanks to: Glen Leeder <glen.leeder / nokia.com>
MFC after: 3 days
nfsd(8), in mountd(8), and in rpc.statd(8)
-h bindip
Specify specific IP addresses to bind to for TCP and UDP requests.
This option may be specified multiple times. If no -h option is
specified, rpc.lockd will bind to INADDR_ANY. Note that when specifying
IP addresses with -h, rpc.lockd will automatically add 127.0.0.1 and
if IPv6 is enabled, ::1 to the list.
PR: bin/98500
MFC after: 1 week
don't do this right; instead go to the scan cache so we pass through
auth state (if the cache is warm we can do this w/o an actual scan)
MFC after: 1 week
a valid PMBR. Without this fix, if label a disk with a GPT, then relabel
it with an MBR the GPT tables are still present. If you then try to create
a GPT with 'gpt create', gpt(8) will fail to open the device because the
partitions in the stale GPT overlap with the slices in the MBR.
MFC after: 1 week
and in mountd(8)
-h bindip
Specify specific IP addresses to bind to for TCP and UDP requests.
This option may be specified multiple times. If no -h option is
specified, rpc.statd will bind to INADDR_ANY. Note that when specifying
IP addresses with -h, rpc.statd will automatically add 127.0.0.1 and if
IPv6 is enabled, ::1 to the list.
(coming for rpc.lockd too)
PR: bin/98500
MFC after: 1 week
disk devices have to consist of a block of sectors. Thus, when writing
gptboot to the boot partition, round the size of the gptboot file up to a
sector boundary, pre-zero it, and write out the full buffer to disk.
(BIO_WRITE and BIO_FLUSH) as it is done is Solaris. The difference is
that Solaris calls it only for sync requests, but we can't say in GEOM
is the request is sync or async, so we do it for every request.
MFC after: 1 week
src/Makefile.inc1 rev. 1.590, it can allow installing a world
cross-built for a different arch over the live system. The procedure
is more or less as follows:
cp -R /rescue /rescue.old
make installkernel TARGET_ARCH=foo
make -DNO_RTLD installworld TARGET_ARCH=foo
^^^^^^^^^
PATH=/rescue.old
chflags noschg /libexec/ld-elf.so.1
cp /usr/obj/foo/usr/src/libexec/rtld/ld-elf.so.1 /libexec
chflags schg /libexec/ld-elf.so.1
<ditto for ld-elf32.so.1 if installing for amd64>
reboot
I.e., not only copy them to a scratch dir, but also make them use saved
copies of libraries and locale files. That gives us several benefits:
1) ABI breakages should no longer affect installworld over the live system.
2) It becomes safe to run installworld while still running the old kernel.
However, it can be reasonable to save the old /rescue before that to be
able to run the old reboot(8), as the new binaries are rather likely to
fail with the old kernel. Anyhow, it's now possible to upgrade a system
in a single reboot _reliably_.
3) With a bit of hackery around rtld(8), it becomes possible to do destructive
cross-installs, e.g., i386->amd64 over the live system.
The only shared item left between the old and new systems is rtld(8),
which cannot be run from a saved copy easily because its full
pathname is stored in the respective field of each ELF executable.
(In theory, that field could be overridden, e.g., from the environment,
but this can lead to security issues.) That's why a destructive
cross-install isn't possible w/o hackery yet.
Fruitful ideas by: ru
Reviewed by: ru
Tested with: audit(4)
to change the freq before the other CPUs are active. The current code
always attempts to change all CPUs to match each other, and the requisite
sched_bind() call won't work before APs are launched.
/dev/agpgart and agp_free_res() frees resources like the BAR for the
aperture. Splitting this up lets chipset-specific detach routines
manipulate the aperture during their detach routines without panicing.
MFC after: 1 week
Reviewed by: anholt
