bde [Tue, 13 Dec 2005 20:17:23 +0000 (20:17 +0000)]
Optimize by not doing excessive conversions for handling the sign bit.
This gives an optimization of between 9 and 22% on Athlons (largest
for cbrt() on amd64 -- from 205 to 159 cycles).
We extracted the sign bit and worked with |x|, and restored the sign
bit as the last step. We avoided branches to a fault by using accesses
to FP values as bits to clear and restore the sign bit. Avoiding
branches is usually good, but the bit access macros are not so good
(especially for setting FP values), and here they always caused pipeline
stalls on Athlons. Even using branches would be faster except on args
that give perfect branch misprediction, since only mispredicted branches
cause stalls, but it possible to avoid touching the sign bit in FP
values at all (except to preserve it in conversions from bits to FP
not related to the sign bit). Do this. The results are identical
except in 2 of the 3 unsupported rounding modes, since all the
approximations use odd rational functions so they work right on strictly
negative values, and the special case of -0 doesn't use an approximation.
jhb [Tue, 13 Dec 2005 18:29:10 +0000 (18:29 +0000)]
Revert previous commit. The BIOS braindamage is even worse than I
originally thought. The BIOS that cleared CPUID_APIC actually managed
to disable the local APIC entirely and even Windows 64 doesn't boot on
it.
delphij [Tue, 13 Dec 2005 15:32:52 +0000 (15:32 +0000)]
In Linux, kernel parameters passed to ioctl are by value, while in FreeBSD
they are passed by reference. Handle the difference within the
linux_ioctl_termio on the LINUX_TCFLSH path.
Submitted by: Jaroslav Drzik <jaro_AT_coop-voz_dot_sk>
jhb [Tue, 13 Dec 2005 15:09:40 +0000 (15:09 +0000)]
Don't check the CPUID_APIC bit in the cpu_features flags field to determine
if the boot CPU has a local APIC because some BIOS vendors are not
competent enough to set this bit. Instead, just assume that we always have
a local APIC on amd64. For i386 the check is a bit more subtle. FreeBSD
requires either an MP Table or an ACPI MADT table to enumerate APICs. The
only systems that have one of those tables that don't have local APICs are
some presumably rare (and old) SMP 486 systems using external APICs. Thus,
instead of checking the CPUID_APIC flag, check the CPU class and abort if
we are running on a 486.
phk [Tue, 13 Dec 2005 13:23:27 +0000 (13:23 +0000)]
/* You're not supposed to hit this problem */
For some denormalized long double values, a bug in __hldtoa() (called
from *printf()'s %A format) results in a base 16 digit being rounded
up from 0xf to 0x10.
When this digit is subsequently converted to string format, an index
of 10 reaches past the end of the uppper-case hex/char array, picking
up whatever the code segment happen to contain at that address.
This mostly seem to be some character from the upper half of the
byte range.
When using the %a format instead of %A, the first character past
the end of the lowercase hex/char table happens to be index 0 in
the uppercase hex/char table hextable and therefore the string
representation features a '0', which is supposedly correct.
This leads me to belive that the proper fix _may_ be as simple as
masking all but the lower four bits off after incrementing a hex-digit
in libc/gdtoa/_hdtoa.c:roundup(). I worry however that the upper
bit in 0x10 indicates a carry not carried.
Until das@ or bde@ finds time to visit this issue, extend the
hexdigit arrays with a 17th index containing '?' so that we get a
invalid but consistent and printable output in both %a and %A formats
whenever this bug strikes.
This unmasks the bug in the %a format therefore solving the real
issue may both become easier and more urgent.
glebius [Tue, 13 Dec 2005 12:16:03 +0000 (12:16 +0000)]
Add a new feature for optimizining ipfw rulesets - substitution of the
action argument with the value obtained from table lookup. The feature
is now applicable only to "pipe", "queue", "divert", "tee", "netgraph"
and "ngtee" rules.
An example usage:
ipfw pipe 1000 config bw 1000Kbyte/s
ipfw pipe 4000 config bw 4000Kbyte/s
ipfw table 1 add x.x.x.x 1000
ipfw table 1 add x.x.x.y 4000
ipfw pipe tablearg ip from table(1) to any
In the example above the rule will throw different packets to different pipes.
TODO:
- Support "skipto" action, but without searching all rules.
- Improve parser, so that it warns about bad rules. These are:
- "tablearg" argument to action, but no "table" in the rule. All
traffic will be blocked.
- "tablearg" argument to action, but "table" searches for entry with
a specific value. All traffic will be blocked.
- "tablearg" argument to action, and two "table" looks - for src and
for dst. The last lookup will match.
marcel [Tue, 13 Dec 2005 06:14:14 +0000 (06:14 +0000)]
In bge_link_upd(), rewrite the logic so that status is assigned
on the code path it is used in a way that GCC understands. This
avoids breakage due to higher optimization levels.
peter [Mon, 12 Dec 2005 22:27:07 +0000 (22:27 +0000)]
For the amd64 platform, we can depend on the TSC being present. This patch
changes DELAY to use the TSC once it has been calibrated. This does NOT
use the TSC for long-term timekeeping. It only uses it to bound the
DELAY() spinloop. This should not be affected by the Athlon64 X2 TSC
quirks because the cpu is not halted while we use DELAY().
imp [Mon, 12 Dec 2005 21:00:58 +0000 (21:00 +0000)]
Make uart_getenv() not be ns8250 dependent. This will allow, in the future,
compilation of kernels without ns8250 support but using the uart framework.
These kernels will be for machines where size matters more, so including code
that can never be executed is undesriable...
sam [Mon, 12 Dec 2005 18:42:20 +0000 (18:42 +0000)]
Bandaid ieee80211_set_chan to handle a channel parameter of "any";
this can happen under certain conditions when scanning. This logic
will eventually go away with the new scanning code.
sam [Mon, 12 Dec 2005 18:04:44 +0000 (18:04 +0000)]
Add ieee80211_beacon_miss for processing sta mode beacon miss events
in the 802.11 layer: we send a directed probe request frame to the
current ap bmiss_max times (w/o answer) before scanning for a new ap.
bz [Mon, 12 Dec 2005 06:23:43 +0000 (06:23 +0000)]
Make nve(4) work for people with nf3/nf4 who never got it
working at all and only saw "nve0: device timeout (N)" messages.
- Setup PHY before handing control to NVidia API setting
speed, duplex, enabling interrupts, etc.
- Add restriction of MAXADDR_32BIT for high address to contigmalloc
to make the driver work on machines with 4+GB of memory.
PR: kern/85583, kern/88045
Tested by: scottl, others earlier version
MFC after: 10 days
rodrigc [Mon, 12 Dec 2005 00:02:22 +0000 (00:02 +0000)]
Contributions from XFS for FreeBSD project:
- Implement cv_wait_unlock() method which has semantics compatible
with the sv_wait() method in IRIX. For cv_wait_unlock(), the lock
must be held before entering the function, but is not held when the
function is exited.
- Implement the existing cv_wait() function in terms of cv_wait_unlock().
Submitted by: kan
Feedback from: jhb, trhodes, Christoph Hellwig <hch at infradead dot org>
sam [Sun, 11 Dec 2005 23:13:54 +0000 (23:13 +0000)]
o move programs to separate directories and use stock Makefiles;
this simplifies including them in crunchgen images
o rename 80211* programs to wlan* as was originally intended
bde [Sun, 11 Dec 2005 17:58:14 +0000 (17:58 +0000)]
Fixed the unexpectedly large maximum error after the previous commit.
It was because I forgot to translate the part of the double precision
algorithm that chops t so that t*t is exact. Now the maximum error
is the same as for double precision (almost exactly 2.0/3 ulps).
bde [Sun, 11 Dec 2005 13:22:01 +0000 (13:22 +0000)]
Fixed all 502518670 errors of more than 1 ulp for cbrtf() on amd64.
The maximum error was 3.56 ulps.
The bug was another translation error. The double precision version
has a comment saying "new cbrt to 23 bits, may be implemented in
precision". This means exactly what it says -- that the 23 bit second
approximation for the double precision cbrt() may be implemented in
single (i.e., float) precision. It doesn't mean what the translation
assumed -- that this approximation, when implemented in float precision,
is good enough for the the final approximation in float precision.
First, float precision needs a 24 bit approximation. The "23 bit"
approximation is actually good to 24 bits on float precision args, but
only if it is evaluated in double precision. Second, the algorithm
requires a cleanup step to ensure its error bound.
In float precision, any reasonable algorithm works for the cleanup
step. Use the same algorithm as for double precision, although this
is much more than enough and is a significant pessimization, and don't
optimize or simplify anything using double precision to implement the
float case, so that the whole double precision algorithm can be verified
in float precision. A maximum error of 0.667 ulps is claimed for cbrt()
and the max for cbrtf() using the same algorithm shouldn't be different,
but the actual max for cbrtf() on amd64 is now 0.9834 ulps. (On i386
-O1 the max is 0.5006 (down from < 0.7) due to extra precision.)
bde [Sun, 11 Dec 2005 11:40:55 +0000 (11:40 +0000)]
Fixed some magic numbers.
The threshold for not being tiny was too small. Use the usual 2**-12
threshold. As for sinhf, use a different method (now the same as for
sinhf) to set the inexact flag for tiny nonzero x so that the larger
threshold works, although this method is imperfect. As for sinhf,
this change is not just an optimization, since the general code that
we fell into has accuracy problems even for tiny x. On amd64, avoiding
it fixes tanhf on 2*13495596 args with errors of between 1 and 1.3
ulps and thus reduces the total number of args with errors of >= 1 ulp
from 37533748 to 5271278; the maximum error is unchanged at 2.2 ulps.
The magic number 22 is log(DBL_MAX)/2 plus slop. This is bogus for
float precision. Use 9 (log(FLT_MAX)/2 plus less slop than for
double precision). Unlike for coshf and tanhf, this is just an
optimization, and MAX isn't misspelled EPSILON in the commit log.
I started testing with nonstandard rounding modes, and verified that
the chosen thresholds work for all modes modulo problems not related
to thresholds. The best thresholds are not very dependent on the mode,
at least for tanhf.
dougb [Sat, 10 Dec 2005 20:21:46 +0000 (20:21 +0000)]
Remove rcconf.sh from /etc/rc.d, and instead load the configuration
as part of rc. Doing this, and the sourcing of rc.subr after we have
determined if we are booting diskless (and correspondingly run
rc.initdiskless if necessary) are safe, and actually allow fewer files
to be needed on the diskless box. This also allows variables from
the configuration to be available to rc itself, such as ...
Add a variable to rc.conf, early_late_divider, which designates the
script which separates the early and late stages of the boot process.
Default this to mountcritlocal, and add text to etc/defaults/rc.conf,
rc.conf(5) and diskless(8) which describes how and why one might want
to change this.
brooks [Sat, 10 Dec 2005 03:46:14 +0000 (03:46 +0000)]
When we get a bogus hostname in an option, drop the option rather than
refusing the lease. This allow obtaining leases on misadministered
networks that use host names with underscores in them.
njl [Fri, 9 Dec 2005 14:27:03 +0000 (14:27 +0000)]
Really fix the relative timestamp bug. It was only incorrect for the ALQ
case. It seems entries are in reverse order when read from the kernel
memory but in the right order when read from a file (i.e. ALQ). Handle
both cases.
davidxu [Fri, 9 Dec 2005 08:29:29 +0000 (08:29 +0000)]
Add a sysctl to force a process to sigexit if a trap signal is
being hold by current thread or ignored by current process,
otherwise, it is very possible the thread will enter an infinite loop
and lead to an administrator's nightmare.
projects / FreeBSD / FreeBSD.git / log