* Reorganize mtmagazine_alloc() and mtmagazine_free() to make the code
more clear. Add assertions on 'continue' loops so we abort on
magazine memory corruption instead of looping forever.

* Pre-stage the new magazine that mtmagazine_free() might need to avoid
having to relock the depot. This also allows us to stage the new
magazine directory into the per-thread loaded field instead of running
it through the depot.

* Fix a deep or infinite recursion which can occur when mtmagazine_free()
calls _slaballoc(), which it does sometimes when it needs a new
magazine. Avoid reentrancy by temporarily disabling the per-thread
cache around the call.

POSIX:2008 introduces the MSG_NOSIGNAL flag that requests
not to send the SIGPIPE signal if an attempt to send
is made on a stream-oriented socket that is no longer
connected. The EPIPE error shall still be returned.

* fix `help' command by using $base/loader.help,
otherwise `help' didn't work when pwd outside $base.
* allow `cd' and `optcd' without arguments,
using $base as default.
* use pager for `?' and `local' commands.
* make `more' work with relative file names
* truncate very long lines (more than 256 chars),
and give warning; before they stopped include processing;
these are typically just comments.
* add `optcd kernel' when using ESC in `menu',
like the menu item (`9') that exits via dloader.menu.
* remove extra line in Fred menu (on right)
(it was scrolling warning about truncated line off screen).
* remove obsolete variables in loader.conf.
* update `help' output.
* update man pages.

It turned out that the x86_64 install's contents of / didn't fit into
256M. So increase to 320M for the smallest supported disks (2-4G) and
raise it gradually to 640M (4-10G) and 768 (anything above 10G). The
latter is also the HAMMER install's default recommendation.

The best solution here would probably be to base the recommendations
on the actual contents of the medium (to be tackled after the release).

* HAMMER UNDOs are addressed using zone-1 (HAMMER_ZONE_RAW_VOLUME) and
zone-2 (HAMMER_ZONE_RAW_BUFFER) data offsets. Normal filesystem
operations may use zone references which are incompatible with the UNDO
data references. That is, they may use a different zone accessing
the same physical disk offset.

Normally when the UNDO is run the modified buffers are flushed to disk
and the buffers are destroyed before normal filesystem operations begin.
Thus it isn't a problem for normal R+W mounts.

* Read-only mounts are a different story. The modified buffers from the
undo are left in core memory (they cannot be flushed yet because the
mount is read-only). The incompatible zones cause the HAMMER buffer
system to lose track of related locked buffer cache buffers and can lead
to a deadlock.

* Fix this by explicitly checking for a read-only mount and doing a
secondary lookup using the RAW zone for certain selected zones.

Some special code is necessary to have %D take precedence over the DD
length specifier (which is not present in gcc41). Eventually, we will
probably have to get rid of all these local conversions entirely.

This commit gets rid of a large bunch of warnings when compiling the
kernel with gcc44.

* thread destructors called by sophisticated pthreaded programs such
as firefox can wind up allocating/freeing space multiple times
AFTER nmalloc's destructor is run.

This can leave the mtmagazine in a weird state because it's destructor
fails to NULL-out tp->mags[i].loaded and tp->mags[i].prev.

* Properly NULL out tp->mags[i].{loaded,prev} in the destructor.

* Lockout mtmagazine use while the mtmagazine is being initialized or
destroyed.

* Permanently lockout mtmagazine use after its destructor has been run.

* Instead of trying to initialize the mtmagazine on the first free, which
might not occur until the destrutor is run (causing pthreads to complain
about destructors being left hanging), have libthread_xu call a new
function _nmalloc_thr_init() during thread creation and do all the slab
initialization there.

Previously, we had special code to handle the properties of %b and %D
(which are for printing bit masks and hexdumps, respectively). Remove
this code and instead use chained format_char_info's to pass the
information that both of these formats consume two arguments.

In the past gunzip(1) write()'s after each inflate return. This is
not optimal from a performance standpoint since the write buffer is
not necessarily be filled up when the inflate rountine reached the
end of input buffer and it's not the end of file.

The length parameter (2491404993) for the slice would have exceeded
INT_MAX (2147483647) and the slice would have been truncated to 1TB.

Since the installer is using fdisk with a configuration file, it
was previously not possible to use a whole >1TB disk from it (one
had to work around it from the command line).

To fix all this, read the numerical parameters in configuration file
lines into a long long.

Note that this change only affects the variable type into which the
parameters read from the file are stored and not any on-disk structures.
Also, checks at different places in fdisk(8) will of course still ensure
that we don't ever go above 2TB.

* Fix two cases where a zone is mis-handled by the new kfree(). Note,
however, that the race being fixed is nearly impossible (might even
BE impossible) to produce because it requires a slab to go from
completely empty to completely full through hysteresis and then destroyed
all in a few microseconds.

Essentially when a kfree() occurs on a cpu which is not the owner of
the zone the chunk is linked into a side-list on the zone using atomic
ops. Under certain (very rare) circumstances the cpu doing the kfree()
must IPI the cpu that owns the zone.

The moment the chunk is linked in the cpu owning the zone can race the
incoming IPI and destroy the zone (if it is now completely unused).
The old kmemusage code handled the race just fine but the new vm_page_t
based big-block handler could not.

The solution is to have an atomic-ops counter for inflight IPIs which
prevents the owning cpu from destroying the zone prematurely.

In addition to fixing a bug which counted vm_page_array_size twice
(which is also fixed on x86_64 in this commit), also put a soft cap
of 1.4M pv entries. Most production machines never even get close
to the old cap and this saves us at least 45MB of KVM on machines
with 3G+ of ram.

The cap can be raised with a kenv boot variable (vm.pmap.pv_entries).

* x86_64 - Increase the maximum buffer cache size from 400MB to 1GB.
This will effect machines with >4G of ram. A machine with 8G of
ram will wind up with ~800MB worth of buffer cache.

In particular this should improve HAMMER's cache performance since
the presence of a cache bp is needed to circumvent the per-mount
lock. This may also improve flushes but it is hard to say.

This all makes sense if you think about. The MB has on-board video and
the BIOS reserves video memory for it, so after taking that into account
the BIOS is really only eating around 4MB of ram for itself. The

"real memory" now correctly reflects memory remaining after the BIOS
took its cut whereas originally (the 8.4GB) was really more a reflection
of the highest mapped address, memory + IO/bus-space combined, and
did not accurately reflect how much memory the BIOS was handing to the
kernel.

* x86_64 sizeof(struct vm_page) goes from 136 to 128, keeping in mind
that it grew from 132 to 136 with the addition of ku_pagecnt. So,
net-net, we have still managed to decrease the size of struct vm_page
by a little.