| Age | Commit message (Collapse) | Author |
|---|
|
|
|
to SYNOPSIS and usage(), which i missed in previous;
|
|
|
|
(if perhaps not quite correct yet);
|
|
|
|
|
|
type, from Patrick Wildt.
|
|
half configured control pipe, from Patrick Wildt.
|
|
and a basis for support of mtime and atime values in pax-format extended
header records.
ok millert@
|
|
from Patrick Wildt
|
|
|
|
code didn't adjust len after stripping blanks so even if a month
*did* start with a blank we'd end up copying garbage at the end.
Also convert a malloc + memcpy to strdup and fix a memory leak in
the wide char version if mbstowcs() fails. From Andre Smagin
|
|
|
|
when adding route entries with the -link option.
This prevent the ARP layer to take the name of your interface for an
Ethernet address. If you still want to add stupid content to your
routing table, please write your own tool.
Thanks to Henk Jan Agteresch for reporting the original issue and
testing this diff.
ok mikeb@, deraadt@, benno@, claudio@
|
|
|
|
|
|
|
|
lower VM_MIN_KERNEL_ADDRESS, since these systems are not crippled by the
Sun-4 MMU hole and have the real 4GB of address space.
Kernels running on Sun-4 MMU are not affected and will still be restricted
to the existing 128MB of kernel space, with 1GB - 128MB of user space.
Kernels running on SRMMU will now provide the low 3GB of address space to
userland, and use the top 1GB for the kernel, except when compiled with
option SMALL_KERNEL, in which case they will keep Sun-4 style the layout
(this is temporary to allow for people to boot bsd.rd to upgrade even when
not running 2.10 boot blocks, and will be removed eventually)
A consequence of this is that the top of the userland stack is no longer at
0xf0000000. But since nothing in userland uses USRSTACK anymore, this should
not be an issue.
Tested on sun4c and various sun4m, with physical memory sizes ranging from 32
to 448MB.
|
|
|
|
the kernel image or not. No functional change (yet).
|
|
ok deraadt@
|
|
number of spurious zs interrupts I am seeing on sun4c, albeit not completely.
|
|
no concerns from schwarze@
|
|
|
|
the original spirit of those sentences.
ok jasper@
|
|
|
|
|
|
|
|
Based on http://www.intel.com/content/dam/www/public/us/en/documents/datasheets/atom-e3800-family-datasheet.pdf
|
|
|
|
|
|
increased memory use is minimal.
ok deraadt logan
|
|
make the initial mbr that tt pointed at a global that can be directly
accessed in the couple of places it is needed.
Fewer parameters, less confusion, no functional change.
|
|
|
|
This should make mpii(4) work on i386 again, apparently.
Problem identified and a slightly different fix proposed
by Christiano F. Haesbaert and Pedro Martelletto of Bitrig.
Huge thanks for tracking this down, guys!
|
|
its only used for the ip and ip6 network stack input queues, so it
seems unfair that every instance of ifqueue has to carry a pointer
around for this specific use case.
this moves the congestion marker to a kernel global. if we detect
that we're congested, we assume the whole system is busy and punish
all input queues.
marking a system as congested is done by setting the global to the
current value of ticks. as the system moves away from that value,
it moves away from being congested until the comparison fails.
written at s2k15
ok henning@ beck@ bluhm@ claudio@
|
|
written at s2k15, but considered too risky before release.
|
|
|
|
|
|
|
|
routines on hppa, the cause for sha512-parisc subtly misbehaving has been
found: despite having fallback pa1.1 code when running on a 32-bit cpu, the
shift constants used in the sigma computations in sha512 are >= 32 and are
silently truncated to 5 bits by the assembler, so there is no chance of
getting this code to work on a non-pa2.0 processor.
However, the pa1.1 fallback code for sha256 is safe, as it never attempts to
shift by more than 31, so reenable it again.
|
|
from around call
|
|
skipping the wccp 2 header. Tested with Cisco ASA.
"looks correct" claudio
ok yasuoka
|
|
Just use the offset recorded/parsed in the struct mbr being used.
Can still traverse/edit extended MBRs so offset really wasn't needed.
Fewer parameters, less confusion, no functional change.
|
|
that should never have been installed.
|
|
of text larger, and puts bootxx past the 7680 bytes limit.
Since bootxx only needs printf for very simple panic() message involving %s
and %d format specifiers only, compile a -DSTRIPPED version of printf.c for
the use of bootxx. This makes bootxx return to a manageable size (it is even
8 bytes shorter now).
|
|
|
|
min, otherwise the constraint cannot be satisfied; ok deraadt@ okan@
|
|
enforce that and remove the options.
Mostly mechanical diff from unifdef with bonus removal of comments that no
longer have any relevance.
ok florian@
|
|
|
