| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Add kern.racct.enable tunable and RACCT_DISABLED config option.
The point of this is to be able to add RACCT (with RACCT_DISABLED)
to GENERIC, to avoid having to rebuild the kernel to use rctl(8).
MFC r282901:
Build GENERIC with RACCT/RCTL support by default. Note that it still
needs to be enabled by adding "kern.racct.enable=1" to /boot/loader.conf.
Note those two are MFC-ed together, because the latter one changes the
name of RACCT_DISABLED option to RACCT_DEFAULT_TO_DISABLED. Should have
committed the renaming separately...
Relnotes: yes
Sponsored by: The FreeBSD Foundation
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
r277637, and r283149 (by emaste@).
r276485 is the real change here, the rest deal with the fallout of
mp_ring's reliance on 64b atomics.
Use the incorrectly spelled 'eigth' from struct pkthdr in this branch
instead of MFC'ing r261733, which would have renamed the field of a
public structure in a -STABLE branch.
---
r276480:
Temporarily unplug cxgbe(4) from !amd64 builds.
r276485:
cxgbe(4): major tx rework.
a) Front load as much work as possible in if_transmit, before any driver
lock or software queue has to get involved.
b) Replace buf_ring with a brand new mp_ring (multiproducer ring). This
is specifically for the tx multiqueue model where one of the if_transmit
producer threads becomes the consumer and other producers carry on as
usual. mp_ring is implemented as standalone code and it should be
possible to use it in any driver with tx multiqueue. It also has:
- the ability to enqueue/dequeue multiple items. This might become
significant if packet batching is ever implemented.
- an abdication mechanism to allow a thread to give up writing tx
descriptors and have another if_transmit thread take over. A thread
that's writing tx descriptors can end up doing so for an unbounded
time period if a) there are other if_transmit threads continuously
feeding the sofware queue, and b) the chip keeps up with whatever the
thread is throwing at it.
- accurate statistics about interesting events even when the stats come
at the expense of additional branches/conditional code.
The NIC txq lock is uncontested on the fast path at this point. I've
left it there for synchronization with the control events (interface
up/down, modload/unload).
c) Add support for "type 1" coalescing work request in the normal NIC tx
path. This work request is optimized for frames with a single item in
the DMA gather list. These are very common when forwarding packets.
Note that netmap tx in cxgbe already uses these "type 1" work requests.
d) Do not request automatic cidx updates every 32 descriptors. Instead,
request updates via bits in individual work requests (still every 32
descriptors approximately). Also, request an automatic final update
when the queue idles after activity. This means NIC tx reclaim is still
performed lazily but it will catch up quickly as soon as the queue
idles. This seems to be the best middle ground and I'll probably do
something similar for netmap tx as well.
e) Implement a faster tx path for WRQs (used by TOE tx and control
queues, _not_ by the normal NIC tx). Allow work requests to be written
directly to the hardware descriptor ring if room is available. I will
convert t4_tom and iw_cxgbe modules to this faster style gradually.
r276498:
cxgbe(4): remove buf_ring specific restriction on the txq size.
r277225:
Make cxgbe(4) buildable with the gcc in base.
r277226:
Allow cxgbe(4) to be built on i386. Driver attach will succeed only on
a subset of i386 systems.
r277227:
Plug cxgbe(4) back into !powerpc && !arm builds, instead of building it
on amd64 only.
r277230:
Build cxgbe(4) on powerpc64 too.
r277637:
Make sure the compiler flag to get cxgbe(4) to compile with gcc is used
only when gcc is being used. This is what r277225 should have been.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
r265871 (nwhitehorn):
Move the PS3 framebuffer console to use vt instead of syscons and
adjust GENERIC64 for PowerPC to use vt with it.
Much to my chagrin, PS3 support seems to have bitrotted somewhat since
the last time I tried it. ehci panics on attach and interrupt handling
seems to be faulty. This should be fixed soon...
r269783 (dumbbell):
Fix two files forgotten in r269783 (vt_generate_cons_palette)
r268895 (nwhitehorn):
Enable X11 via xf86-video-scfb on the Playstation 3. This commit made
from an xterm running for the first time on said Playstation.
Approved by: nwhitehorn
Relnotes: yes
|
|
|
|
|
|
| |
In kernel config files, it is supposed to be 'options<space><tab>' not
'options<tab><tab>', per long standing (but recently not so strictly
enforced) convention.
|
|
|
|
|
|
|
| |
Enable SCHED_ULE for ppc book-e.
Add driver for the ADT7460/ADT7467 fan controller found in
later PowerBooks and iBooks.
|
|
|
|
|
| |
Add driver for the ADT7460/ADT7467 fan controller found in later PowerBooks
and iBooks. Original work by andreast.
|
|
|
|
|
|
| |
Add driver for POWER hypervisor interpartition ethernet.
Approved by: re (glebius)
|
|
|
|
|
|
|
|
|
|
| |
- Enable MALLOC_PRODUCTION
- Default dumpdev=NO
- Remove UPDATING entry regarding debugging features
- Bump __FreeBSD_version to 1000500
Approved by: re (implicit)
Sponsored by: The FreeBSD Foundation
|
|
|
|
|
|
|
|
|
|
|
|
| |
Requirements) systems from the projects/pseries branch. This in principle
includes all IBM POWER hardware released in the last 15 years with the
exception of POWER3-based systems when run in 64-bit mode. The main
development target, however, has been the PAPR logical partition support
that is the default target in KVM on POWER and QEMU -- mileage may vary
on actual hardware at present. Much of the heavy lifting here was done
by Andreas Tobler.
Approved by: re (kib)
|
| |
|
|
|
|
|
|
|
|
|
| |
used by the tools in base systems and with sandboxing more and more tools
the usage should only increase.
Submitted by: Mariusz Zaborski <oshogbo@FreeBSD.org>
Sponsored by: Google Summer of Code 2013
MFC after: 1 month
|
|
|
|
|
|
|
|
| |
- update powerpc/GENERIC64 as well, suggested by mdf
- update comments so that they make sense after the change, suggested by
jhb
X-MFC after: never (change specific to head)
|
|
|
|
|
|
|
| |
KDB_TRACE is not an alternative to DDB/etc, they are complementary.
So I do not see any reason to not enable KDB_TRACE by default.
X-MFC after: never (change specific to head)
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* Make Yarrow an optional kernel component -- enabled by "YARROW_RNG" option.
The files sha2.c, hash.c, randomdev_soft.c and yarrow.c comprise yarrow.
* random(4) device doesn't really depend on rijndael-*. Yarrow, however, does.
* Add random_adaptors.[ch] which is basically a store of random_adaptor's.
random_adaptor is basically an adapter that plugs in to random(4).
random_adaptor can only be plugged in to random(4) very early in bootup.
Unplugging random_adaptor from random(4) is not supported, and is probably a
bad idea anyway, due to potential loss of entropy pools.
We currently have 3 random_adaptors:
+ yarrow
+ rdrand (ivy.c)
+ nehemeiah
* Remove platform dependent logic from probe.c, and move it into
corresponding registration routines of each random_adaptor provider.
probe.c doesn't do anything other than picking a specific random_adaptor
from a list of registered ones.
* If the kernel doesn't have any random_adaptor adapters present then the
creation of /dev/random is postponed until next random_adaptor is kldload'ed.
* Fix randomdev_soft.c to refer to its own random_adaptor, instead of a
system wide one.
Submitted by: arthurmesh@gmail.com, obrien
Obtained from: Juniper Networks
Reviewed by: obrien
|
| |
|
|
|
|
| |
Discussed with: nwhitehorn
|
|
|
|
|
|
|
|
|
| |
most kernels before FreeBSD 9.0. Remove such modules and respective kernel
options: atadisk, ataraid, atapicd, atapifd, atapist, atapicam. Remove the
atacontrol utility and some man pages. Remove useless now options ATA_CAM.
No objections: current@, stable@
MFC after: never
|
|
|
|
|
| |
Discussed with: mckusick
MFC after: 2 weeks
|
|
|
|
| |
GENERIC.
|
|
|
|
| |
MFC after: 1 month
|
|
|
|
| |
Submitted by: netchild
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
| |
Approved by: nwhitehorn (mentor)
MFC after: 9.1-RELEASE
|
|
|
|
|
| |
add them to GENERIC and GENERIC64. They are applicable to Apple H/W and not
at all for Book-E platforms.
|
|
|
|
|
|
|
| |
GENERIC config file.
MFC after: 3 days
Reqested by: nwhitehorn
|
|
|
|
| |
while I'm here. No functional change.
|
|
|
|
|
|
| |
sparc64 GENERIC config files.
MFC after: 3 days
|
|
|
|
|
|
|
|
|
|
|
|
| |
implementation specific vs. the common architecture definition.
Bring PPC4XX defines (PSL, SPR, TLB). Note the new definitions under
BOOKE_PPC4XX are not used in the code yet.
This change set is not supposed to affect existing E500 support, it's just
another reorg step before bringing support for E500mc, E5500 and PPC465.
Obtained from: AppliedMicro, Freescale, Semihalf
|
|
|
|
|
|
|
|
|
|
|
| |
As of FreeBSD 8, this driver should not be used. Applications that use
posix_openpt(2) and openpty(3) use the pts(4) that is built into the
kernel unconditionally. If it turns out high profile depend on the
pty(4) module anyway, I'd rather get those fixed. So please report any
issues to me.
The pty(4) module is still available as a kernel module of course, so a
simple `kldload pty' can be used to run old-style pseudo-terminals.
|
|
|
|
|
|
|
|
|
|
|
|
| |
platforms.
This will make every attempt to mount a non-mpsafe filesystem to the
kernel forbidden, unless it is expressely compiled with
VFS_ALLOW_NONMPSAFE option.
This patch is part of the effort of killing non-MPSAFE filesystems
from the tree.
No MFC is expected for this patch.
|
|
|
|
|
| |
Approved by: nwhitehorn (mentor)
MFC after: 1 week
|
|
|
|
| |
Tested on 32- and 64-bit PowerMac.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
configurations for various architectures in FreeBSD 10.x. This allows
basic Capsicum functionality to be used in the default FreeBSD
configuration on non-embedded architectures; process descriptors are not
yet enabled by default.
MFC after: 3 months
Sponsored by: Google, Inc
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
all the architectures.
The option allows to mount non-MPSAFE filesystem. Without it, the
kernel will refuse to mount a non-MPSAFE filesytem.
This patch is part of the effort of killing non-MPSAFE filesystems
from the tree.
No MFC is expected for this patch.
Tested by: gianni
Reviewed by: kib
|
|
|
|
|
|
|
|
| |
thing when changing the debugging options as part of head becoming a new
stable branch. It may also help people who for one reason or another want
to run head but don't want it slowed down by the debugging support.
Reviewed by: kib
|
|
|
|
|
|
|
| |
are forewarned they might wind up with a hole in their foot if they
decide to give it a try.
Suggested by: dougb
|
|
|
|
| |
Approved by: re (blanket)
|
|
|
|
|
| |
bug on PowerPC was resolved by r223485, and it appears to run stably at this
point.
|
|
|
|
| |
to PowerPC GENERIC (along with a small rearrangement).
|
|
|
|
|
|
| |
by Justin Hibbits.
Approved by: nwhitehorn (mentor)
|
|
|
|
|
|
| |
PowerMac's.
Approved by: nwhitehorn (mentor)
|
|
|
|
|
|
| |
UP and SMP hardware. Enable it in GENERIC.
MFC after: 2 weeks
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
NFS client (which I guess is no longer experimental). The fstype "newnfs"
is now "nfs" and the regular/old NFS client is now fstype "oldnfs".
Although mounts via fstype "nfs" will usually work without userland
changes, an updated mount_nfs(8) binary is needed for kernels built with
"options NFSCL" but not "options NFSCLIENT". Updated mount_nfs(8) and
mount(8) binaries are needed to do mounts for fstype "oldnfs".
The GENERIC kernel configs have been changed to use options
NFSCL and NFSD (the new client and server) instead of NFSCLIENT and NFSSERVER.
For kernels being used on diskless NFS root systems, "options NFSCL"
must be in the kernel config.
Discussed on freebsd-fs@.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
stack. It means that all legacy ATA drivers are disabled and replaced by
respective CAM drivers. If you are using ATA device names in /etc/fstab or
other places, make sure to update them respectively (adX -> adaY,
acdX -> cdY, afdX -> daY, astX -> saY, where 'Y's are the sequential
numbers for each type in order of detection, unless configured otherwise
with tunables, see cam(4)).
ataraid(4) functionality is now supported by the RAID GEOM class.
To use it you can load geom_raid kernel module and use graid(8) tool
for management. Instead of /dev/arX device names, use /dev/raid/rX.
|