marcel [Sun, 23 Oct 2011 20:03:33 +0000 (20:03 +0000)]
Don't terminate the interactive root mount prompt on mount failure.
This restores the previous behaviour. While here, match '?' and '.'
inputs exactly and improve the error message.
Requested by: avg@
Derived from a patch by: Arnaud Lacombe <lacombar@gmail.com>
glebius [Sun, 23 Oct 2011 15:15:17 +0000 (15:15 +0000)]
Merge several fixes to bulk update processing from OpenBSD. Merged
revisions: 1.148, 1.149, 1.150. This makes number of states on
master/slave to be of a sane value.
glebius [Sun, 23 Oct 2011 15:08:18 +0000 (15:08 +0000)]
- Fix a bad typo (FreeBSD specific) in pfsync_bulk_update(). Instead
of scheduling next run pfsync_bulk_update(), pfsync_bulk_fail()
was scheduled.
This lead to instant 100% state leak after first bulk update
request.
- After above fix, it appeared that pfsync_bulk_update() lacks
locking. To fix this, sc_bulk_tmo callout was converted to an
mtx one. Eventually, all pf/pfsync callouts should be converted
to mtx version, since it isn't possible to stop or drain a
non-mtx callout without risk of race.
- Add comment that callout_stop() in pfsync_clone_destroy() lacks
locking. Since pfsync0 can't be destroyed (yet), let it be here.
glebius [Sun, 23 Oct 2011 14:59:54 +0000 (14:59 +0000)]
Fix from r226623 is not sufficient to close all races in pfsync(4).
The root of problem is re-locking at the end of pfsync_sendout().
Several functions are calling pfsync_sendout() holding pointers
to pf data on stack, and these functions expect this data to be
consistent.
To fix this, the following approach was taken:
- The pfsync_sendout() doesn't call ip_output() directly, but
enqueues the mbuf on sc->sc_ifp's interfaces queue, that
is currently unused. Then pfsync netisr is scheduled. PF_LOCK
isn't dropped in pfsync_sendout().
- The netisr runs through queue and ip_output()s packets
on it.
Apart from fixing race, this also decouples stack, fixing
potential issues, that may happen, when sending pfsync(4)
packets on input path.
hrs [Sun, 23 Oct 2011 06:34:52 +0000 (06:34 +0000)]
- Add description that IPv6 configuration will be ignored if $ifconfig_IF_ipv6
is empty.
- Move a configuration example "inet6 accept_rtadv" to just after the manual
GUA configuration.
- Add an example of $ipv6_prefix_IF.
marcel [Sun, 23 Oct 2011 02:51:23 +0000 (02:51 +0000)]
Add support for Boot Camp. The support is defined as follows:
o Detect when Boot Camp is enabled (i.e. the MBR mirrors the GPT).
o When Boot Camp is enabled, update the MBR whenever we write the GPT.
o Creation of a Boot Camp enabled GPT is not supported.
o Automatically disable Boot Camp when the GPT has been changed so that
there's either no EFI partition or no HFS+ partition.
o The first 4 partitions (by index) get mirrored in the MBR.
Requested by, discussed with and tested by: kris@pcbsd.org
MFC after: 1 week
dim [Sat, 22 Oct 2011 14:08:43 +0000 (14:08 +0000)]
Upgrade our copy of llvm/clang to r142614, from upstream's release_30
branch. This brings us very close to the 3.0 release, which is expected
in a week or two.
glebius [Fri, 21 Oct 2011 22:28:15 +0000 (22:28 +0000)]
Fix a race: we should update sc_len before dropping the pf lock, otherwise a
number of packets can be queued on sc, while we are in ip_output(), and then
we wipe the accumulated sc_len. On next pfsync_sendout() that would lead to
writing beyond our mbuf cluster.
glebius [Fri, 21 Oct 2011 13:54:17 +0000 (13:54 +0000)]
Note that it is still not possible to guard special kind of allocations, those
that have special relationships with uma(9). Currently only mbuf clusters.
pjd [Fri, 21 Oct 2011 13:44:26 +0000 (13:44 +0000)]
Because ZFS boot code was very fragile in the past and real PITA to debug,
introduce zfsboottest.sh script that will verify if it will be possible to boot
from the given pool.
# zfsboottest.sh system
Where "system" is pool name of the pool we want to boot from.
What is being verified by the script:
- Does the pool exist?
- Does it have bootfs property configured?
- Is mountpoint property of the boot dataset set to 'legacy'?
Dataset configured in bootfs property has to be mounted to perform more
checks:
- Does the /boot directory in boot dataset exist?
- Is this dataset configured as root file system in /etc/fstab or set
in vfs.root.mountfrom variable in /boot/loader.conf?
By using zfsboottest tool the script will read all the files in /boot
directory using ZFS boot code and calculate their checksums.
Then, it will walk /boot directory using find(1) though regular file sytem
and also read all the files in /boot directory and calculate their checksums.
If any of the files cannot be looked up, read or checksum is invalid it will
be reported and booting off of this pool is probably not possible.
Some additional checks may be interesting as well. For example if the disks
contain proper pmbr and gptzfsboot code or if all expected files in /boot/
are present.
When upgrading FreeBSD, one should snapshot datasets that contain operating
system, upgrade (install new world and kernel) and use zfsboottest.sh to verify
if it will be possible to boot from new configuration. If all is good one
should upgrade boot blocks, by eg.:
- Instead of printing file's content calculate MD5 hash of the file,
so it can be easly compared to the hash calculated via file system.
- Some other minor improvements.
ed [Fri, 21 Oct 2011 12:58:34 +0000 (12:58 +0000)]
Add missing #includes.
According to POSIX, these two header files should be able to be included
by themselves, not depending on other headers. The <net/if.h> header
uses struct sockaddr when __BSD_VISIBLE=1, while <netinet/tcp.h> uses
integer datatypes (u_int32_t, u_short, etc).
des [Fri, 21 Oct 2011 11:08:25 +0000 (11:08 +0000)]
It turns out that truss also used kdump's mkioctls script, and expected
ioctlname() to return a pointer to the name rather than print it. This did
not show up in testing because truss had its own prototype for ioctlname(),
so it would build fine and run fine as long as the program being traced did
not issue an ioctl.
Teach mkioctls to generate different versions of ioctlname() based on its
first command-line argument.
Pointed out by: Garrett Cooper <yanegomi@gmail.com>
das [Fri, 21 Oct 2011 06:41:46 +0000 (06:41 +0000)]
People porting FreeBSD to new architectures ought not have to
implement a deprecated FPU control interface in addition to the
standard one. To make this clearer, further deprecate ieeefp.h
by not declaring the function prototypes except on architectures
that implement them already.
Currently i386 and amd64 implement the ieeefp.h interface for
compatibility, and for fp[gs]etprec(), which doesn't exist on
most other hardware. Powerpc, sparc64, and ia64 partially implement
it and probably shouldn't, and other architectures don't implement it
at all.
das [Fri, 21 Oct 2011 06:40:36 +0000 (06:40 +0000)]
Replace a proliferation of buggy MD implementations of modf() with a
working MI one. The MI one only needs to be overridden on machines
with non-IEEE754 arithmetic. (The last supported one was the VAX.)
It can also be overridden if someone comes up with a faster one that
actually passes the regression tests -- but this is harder than it sounds.
das [Fri, 21 Oct 2011 06:32:54 +0000 (06:32 +0000)]
Tests for cancellation in fma(). Also include more tests for 128-bit
long doubles. Thanks for clusteradm (simon) for making the needed
hardware available.
das [Fri, 21 Oct 2011 06:29:32 +0000 (06:29 +0000)]
Improved handling of large x in ccosh{,f}():
- Handle cases where exp(x) would overflow, but ccosh(x) ~= exp(x) / 2
shouldn't.
- Use the ccosh(x) ~= exp(x) / 2 approximation to simplify the calculation
when x is large.
Similarly for csinh(). Also fixed the return value of csinh(-Inf +- 0i).
das [Fri, 21 Oct 2011 06:27:56 +0000 (06:27 +0000)]
The cexp() and {,c}{cos,sin}h functions all need to be able to compute
exp(x) scaled down by some factor, and the challenge is doing this
accurately when exp(x) would overflow. This change replaces all of
the tricks we've been using with common __ldexp_exp() and
__ldexp_cexp() routines that handle all the scaling.
bde plans to improve on this further by moving the guts of exp() into
k_exp.c and handling the scaling in a more direct manner. But the
current approach is simple and adequate for now.
pjd [Thu, 20 Oct 2011 15:42:38 +0000 (15:42 +0000)]
- Correctly read gang header from raidz.
- Decompress assembled gang block data if compressed.
- Verify checksum of a gang header.
- Verify checksum of assembled gang block data.
- Verify checksum of uber block.
pjd [Wed, 19 Oct 2011 23:44:38 +0000 (23:44 +0000)]
Always pass data size for checksum verification function, as using
physical block size declared in bp may not always be what we want.
For example in case of gang block header physical block size declared
in bp is much larger than SPA_GANGBLOCKSIZE (512 bytes) and checksum
calculation failed. This bug could lead to accessing unallocated
memory and resets/failures during boot.
pjd [Wed, 19 Oct 2011 23:40:37 +0000 (23:40 +0000)]
Never pass NULL block pointer when reading. This is neither expected nor
handled by lower layers like vdev_raidz, which uses bp for checksum
verification. This bug could lead to NULL pointer reference and resets
during boot.
kensmith [Wed, 19 Oct 2011 21:55:20 +0000 (21:55 +0000)]
Add a warning about why sbp(4) is commented out so that curious folks
are forewarned they might wind up with a hole in their foot if they
decide to give it a try.
des [Wed, 19 Oct 2011 15:35:41 +0000 (15:35 +0000)]
If ls was invoked with -i but neither -l nor -s, blocksize was used in
display() to calculate column widths, but was not initialized in
main(). This resulted in a division by zero.
Noticed by: Michael Butler <imb@protected-networks.net>
bz [Wed, 19 Oct 2011 13:13:56 +0000 (13:13 +0000)]
Fix recursive pf locking leading to panics. Splatter PF_LOCK_ASSERT()s
to document where we are expecting to be called with a lock held to
more easily catch unnoticed code paths.
This does not neccessarily improve locking in pfsync, it just tries
to avoid the panics reported.
PR: kern/159390, kern/158873
Submitted by: pluknet (at least something that partly resembles
my patch ignoring other cleanup, which I only saw
too late on the 2nd PR)
MFC After: 3 days
bz [Wed, 19 Oct 2011 10:04:24 +0000 (10:04 +0000)]
Pseudo interfaces should go at SI_SUB_PSEUDO. However at least
pfsync also depends on pf to be initialized already so pf goes at
FIRST and the interfaces go at ANY.
Then the (VNET_)SYSINIT startups for pf stays at SI_SUB_PROTO_BEGIN
and for pfsync we move to the later SI_SUB_PROTO_IF.
This is not ideal either but at least an order that should work for
the moment and can be re-fined with the VIMAGE merge, once this will
actually work with more than one network stack.
mckusick [Tue, 18 Oct 2011 18:42:26 +0000 (18:42 +0000)]
The current /etc/dumpdates file restricts device names to 32 characters.
With the addition of various GEOM layers some device names now exceed
this length, for example /dev/mirror/encrypted.elig.journal. This
change expands the field to 53 bytes which brings the /etc/dumpdates
lines to 80 characters. Exceeding 80 characters makes the /etc/dumpdates
file much less human readable. A test is added to dump so that it
verifies that the device name will fit in the 53 character field
failing the dump if it is too long.
This change has been checked to verify that its /etc/dumpdates file
is compatible with older versions of dump.
dim [Tue, 18 Oct 2011 17:37:18 +0000 (17:37 +0000)]
Fix the way clang retrieves the major FreeBSD release number from the
target triple, so that the __FreeBSD__ and __FreeBSD_cc_version builtin
macros return the expected results.
jchandra [Tue, 18 Oct 2011 16:37:28 +0000 (16:37 +0000)]
Fix wakeup latency when sleeping with 'wait'
If we handle an interrupt just before the 'wait' and the interrupt
schedules some work, we need to skip the 'wait' call. The simple solution
of calling sched_runnable() with interrupts disabled immediately before
wait still leaves a window after the call and before 'wait' in which
the same issue can occur.
The solution implemented is to check the EPC in the interrupt handler, and
if it is in a region before the 'wait' call, to fix up the EPC to skip the
wait call.
Reported/analysed by: adrian
Fix suggested by: kib
fabient [Tue, 18 Oct 2011 15:25:43 +0000 (15:25 +0000)]
Add a flush of the current PMC log buffer before displaying the next top.
As the underlying block is 4KB if the PMC throughput is low the measurement
will be reported on the next tick. pmcstat(8) use the modified flush API to
reclaim current buffer before displaying next top.
kensmith [Tue, 18 Oct 2011 13:45:16 +0000 (13:45 +0000)]
Comment out the sbp(4) driver for architectures that support it.
As part of the 8.0-RELEASE cycle this was done in stable/8 (r199112)
but was left alone in head so people could work on fixing an issue that
caused boot failure on some motherboards. Apparently nobody has worked
on it and we are getting reports of boot failure with the 9.0 test builds.
So this time I'll comment out the driver in head (still hoping someone
will work on it) and MFC to stable/9.
Submitted by: Alberto Villa <avilla at FreeBSD dot org>
kensmith [Tue, 18 Oct 2011 11:29:10 +0000 (11:29 +0000)]
Escape the newline so we get a proper line continuation. Without this
the text of the menu selections doesn't get displayed properly and it
makes the installer appear to lock up for no obvious reason.