containing the jailid, path, hostname, ip and the command used to start
the jail.
PR: misc/89883
Submitted by: L. Jason Godsey <lannygodsey -at- yahoo.com>
Reviewed by: phk
MFC after: 1 week
the bridge (PCI bus A or B) we are attaching to rather than registering
both handlers at once when attaching to the first half we encounter.
This is a bit cleaner as it corresponds to which PCI bus error interrupt
actually is assigned to the respective half by the OFW and allows to
collapse both PCI bus error interrupt handlers into one function easily.
- Use the actual RID of the respective interrupt resource as index into
sc_irq_res and also use it when allocating the resource. For now this
is a bit cleaner and will be mandatory later on.
- According to OpenSolaris the spare hardware interrupt is used as the
over-temperature interrupt in systems with Psycho bridges. Unlike as
with the SBus-based workstations I didn't manage to trigger it when
covering the fan outlets of an U60 but better be safe than sorry and
register a handler anyway.
MFC after: 1 month
bug by explaining what the problem is and how the workaround works.
- Fix some cosmetics nits, mainly properly terminate sentences in comments,
which I missed when backporting the style changes to psycho(4) in psycho.c
rev. 1.54 due to lack of corresponding code.
- The "USIIe version of the Sabre bridge" actually is termed "Hummingbird";
name it as such in comments and messages.
according to the highest nonzero bit in a denormal was missing.
fdlibm ilogbf() and ilogb() have always had the adjustment, but only
use a small part of their method for handling denormals; use the
normalization method in log[f]() for the main part.
It was lost in rev.1.9. The log message for rev.1.9 says that the
special case of +-0 is handled twice, but it was only handled once,
so it became unhandled, and this happened to break half of the cases
that return +-0:
- round-towards-minus-infinity: 0 < x < 1: result was -0 not 0
- round-to-nearest: -0.5 <= x < 0: result was 0 not -0
- round-towards-plus-infinity: -1 < x < 0: result was 0 not -0
- round-towards-zero: -1 < x < 0: result was 0 not -0
TWO52[sx] to trick gcc into correctly converting TWO52[sx]+x to double
on assignment to "double w", force a correct assignment by assigning
to *(double *)&w. This is cleaner and avoids the double rounding
problem on machines that evaluate double expressions in double
precision. It is not necessary to convert w-TWO52[sx] to double
precision on return as implied in the comment in rev.1.3, since
the difference is exact.
(1) In round-to-nearest mode, on all machines, fdlibm rint() never
worked for |x| = n+0.75 where n is an even integer between 262144
and 524286 inclusive (2*131072 cases). To avoid double rounding
on some machines, we begin by adjusting x to a value with the 0.25
bit not set, essentially by moving the 0.25 bit to a lower bit
where it works well enough as a guard, but we botched the adjustment
when log2(|x|) == 18 (2*2**52 cases) and ended up just clearing
the 0.25 bit then. Most subcases still worked accidentally since
another lower bit serves as a guard. The case of odd n worked
accidentally because the rounding goes the right way then. However,
for even n, after mangling n+0.75 to 0.5, rounding gives n but the
correct result is n+1.
(2) In round-towards-minus-infinity mode, on all machines, fdlibm rint()
never for x = n+0.25 where n is any integer between -524287 and
-262144 inclusive (262144 cases). In these cases, after mangling
n+0.25 to n, rounding gives n but the correct result is n-1.
(3) In round-towards-plus-infinity mode, on all machines, fdlibm rint()
never for x = n+0.25 where n is any integer between 262144 and
524287 inclusive (262144 cases). In these cases, after mangling
n+0.25 to n, rounding gives n but the correct result is n+1.
A variant of this bug was fixed for the float case in rev.1.9 of s_rintf.c,
but the analysis there is incomplete (it only mentions (1)) and the fix
is buggy.
Example of the problem with double rounding: rint(1.375) on a machine
which evaluates double expressions with just 1 bit of extra precision
and is in round-to-nearest mode. We evaluate the result using
(double)(2**52 + 1.375) - 2**52. Evaluating 2**52 + 1.375 in (53+1) bit
prcision gives 2**52 + 1.5 (first rounding). (Second) rounding of this
to double gives 2**52 + 2.0. Subtracting 2**52 from this gives 2.0 but
we want 1.0. Evaluating 2**52 + 1.375 in double precision would have
given the desired intermediate result of 2**52 + 1.0.
The double rounding problem is relatively rare, so the botched adjustment
can be fixed for most machines by removing the entire adjustment. This
would be a wrong fix (using it is 1 of the bugs in rev.1.9 of s_rintf.c)
since fdlibm is supposed to be generic, but it works in the following cases:
- on all machines that evaluate double expressions in double precision,
provided either long double has the same precision as double (alpha,
and i386's with precision forced to double) or my earlier fix to use
a long double 2**52 is modified to avoid using long double precision.
- on all machines that evaluate double expressions in many more than 11
bits of extra precision. The 1 bit of extra precision in the example
is the worst case. With N bits of extra precision, it sufices to
adjust the bit N bits below the 0.5 bit. For N >= about 52 there is
no such bit so the adjustment is both impossible and unnecessary. The
fix in rev.1.9 of s_rintf.c apparently depends on corresponding magic
in float precision: on all supported machines N is either 0 or >= 24,
so double rounding doesn't occur in practice.
- on all machines that don't use fdlibm rint*() (i386's).
So under FreeBSD, the double rounding problem only affects amd64 now, but
should only affect i386 in future (when double expressions are evaluated
in long double precision).
Switch strncpy to strlcpy suggested by gad and issue found by pjd.
Add to uname(3) man page describing:
UNAME_s
UNAME_r
UNAME_v
UNAME_m
Add to getosreldate(3) man page describing:
OSVERSION
Submitted by: ru, pjd/gad
Reviewed by: ru (man pages)
and some fixes from Motomichi Matsuzaki. Testing involved many people, but the
final, successful testing was from rwatson who endured several rounds of "it
crashes at XYZ stage" "oh, please correct this typo and try again." The Linux
driver, and to a small extent the limited specs, were both used as a reference
for how to program the chipset.
PR: kern/80396
Submitted by: Martin Mersberger
is only present for fstab(5) compatibility, and is
otherwise ignored by mount(8) (not passed to mount_*
programs, and not passed to nmount(2)).
"-u -o rw" worked with an old mount(8) with mount_ufs.c
because "-o rw" was stripped and simple "-u" caused an
update of UFS from read-only to read-write, due to
inability of mount(2) to track changes in options
(MNT_RDONLY is either set or not).
"-u" no longer causes the transition from RO to RW,
now that mount(8) was converted to use nmount(2), so
an explicit change to RW is required. Keep up with
this change, and use "-uw" to mount root read-write.
the base rcorder. This is accomplished by running rcorder twice,
first to get all the disks mounted (through mountcritremote),
then again to include the local_startup directories.
This dramatically changes the behavior of rc.d/localpkg, as
all "local" scripts that have the new rc.d semantics are now
run in the base rcorder, so only scripts that have not been
converted yet will run in rc.d/localpkg.
Make a similar change in rc.shutdown, and add some functions in
rc.subr to support these changes.
Bump __FreeBSD_version to reflect this change.
revision 1.179 to correctly set/clear execute permission on the mapping
it creates. Thus, mmap(2)ing a memory resident file will not result in
the file being mapped with execute permission when execute permission was
not requested.
Eliminate an unneeded Instruction Memory Barrier (IMB) in
pmap_enter_quick(). Since there was no previous (instruction) mapping
for the given virtual address prior to pmap_enter_quick(), there can be
no instructions from the given virtual address in the pipeline that need
flushing.
MFC after: 1 week
- in round-towards-minus-infinity mode, on all machines, roundf(x) never
worked for 0 < |x| < 0.5 (2*0x3effffff cases in all, or almost half of
float space). It was -0 for 0 < x < 0.5 and 0 for -0.5 < x < 0, but
should be 0 and -0, respectively. This is because t = ceilf(|x|) = 1
for these args, and when we adjust t from 1 to 0 by subtracting 1, we
get -0 in this rounding mode, but we want and expected to get 0.
- in round-towards-minus-infinity, round towards zero and round-to-nearest
modes, on machines that evaluate float expressions in float precision
(most machines except i386's), roundf(x) never worked for |x| =
<float value immediately below 0.5> (2 cases in all). It was +-1 but
should have been +-0. This is because t = ceilf(|x|) = 1 for these
args, and when we try to classify |x| by subtracting it from 1 we
get an unexpected rounding error -- the result is 0.5 after rounding
to float in all 3 rounding modes, so we we have forgotten the
difference between |x| and 0.5 and end up returning the same value
as for +-0.5.
The fix is to use floorf() instead of ceilf() and to add 1 instead of
-1 in the adjustment. With floorf() all the expressions used are
always evaluated exactly so there are no rounding problems, and with
adjustments of +1 we don't go near -0 when adjusting.
Attempted to fix round() and roundl() by cloning the fix for roundf().
This has only been tested for round(), only on args representable as
floats. Double expressions are evaluated in double precision even on
i386's, so round(0.5-epsilon) was broken even on i386's. roundl()
must be completely broken on i386's since long double precision is not
really supported. There seem to be no other dependencies on the
precision.
Update Intel MatrixRAID support to be able to pick up RAID0+1 (RAID10)
and RAID5 arrays without panic'ing.
This has the side effect of now also supporting multiple volumes on
MatrixRAID's now I have the metadata better understood..
HW sponsored by: Mullet Scandinavia AB
