- Add 'hyperv' module into build;
- Allow building Hyper-V support as part of the kernel;
- Hook Hyper-V build into NOTES.
This is intended for MFC if re@ permits.
MFC after: 3 days
- Add support to 40Gbps devices;
- Add support to control adaptive interrupt coalescing (AIC)
via sysctl;
- Improve support of BE3 devices;
Many thanks to Emulex for their continued support of FreeBSD.
Submitted by: Venkata Duvvuru <VenkatKumar.Duvvuru Emulex Com>
MFC after: 3 days
According to online documentation [1], Ext4 has two new "special"
inodes so add the new exclude and replica inodes.
Reference:
[1] https://ext4.wiki.kernel.org/index.php/Ext4_Disk_Layout
Reported by: Mike Ma
MFC after: 3 weeks
defaults to PANIC_REBOOT_WAIT_TIME (a long-existing kernel config
setting). Use this now-variable value in place of the defined constant
to control how long the system waits after a panic before rebooting.
scheduling classes in the chip and to bind tx queue(s) to a scheduling
class respectively. These can be used for various kinds of tx traffic
throttling (to force selected tx queues to drain at a fixed Kbps rate,
or a % of the port's total bandwidth, or at a fixed pps rate, etc.).
Obtained from: Chelsio
by SCHED_PRI_TICKS should be SCHED_PRI_RANGE - 1 so that the resulting
priority value (before nice adjustment) is between SCHED_PRI_MIN and
SCHED_PRI_MAX, inclusive.
Submitted by: kib
Reported by: pho
MFC after: 1 week
has outgrown its original name. Originally this function simply sent an IPI
to the host cpu that a vcpu was executing on but now it does a lot more than
just that.
Reviewed by: grehan@
This is to support LOCK_LOG_* functionality effectively in debugging
environments but it is overkill because really LOCK_DEBUG should be on
only if (KTR_COMPILE & KTR_LOCK) is true.
Fix this by applying the correct logic.
In this process, move the KTR classes to its own header to reduce
namespace pollution.
Sponsored by: EMC / Isilon storage division
Reviewed by: jhb
for these chipsets.
* Correctly set the active/passive flag in the scan request - this is
NOT a "is the channel active|passive"; it's to do with whether we
have an SSID to actively scan for or not. The firmware takes care
of the active/passive setup of the channel.
* Calculate the active/passive dwell time based on the beacon interval
and the channel mode, rather than using a hard coded value.
* For now, hardcode the scan service_time. It's defined as:
31:22 - number of beacon intervals to come back onto the home channel
for;
0:21 - time (microseconds) to come back onto the home channel for.
When doing an active scan when the NIC is active (whether we're associated
or not - it only matters if we've setup the NIC to a destination or not)
this determines how much time to stay on the home channel for when
scanning. We can tune this based on the amount of active traffic.
For now it's 4 beacon intervals and 100 microseconds.
* Fix the "good crc threshold" setting. It differs based on the NIC
firmware. Some older firmware required a workaround; the later
firmware instead treats the field as a flag.
* Enforce that we are not sending a scan command if one is already
pending. Any time this is done is a bug and it absolutely needs
to be fixed - so be very loud.
* Add the SCAN flag to a few debug messages that are scan related but
only occuring under STATE.
Now, this does get noisy when you're scanning in an actively busy 2GHz
network as the firmware (for reason I don't quite yet understand) seems
hell bent on staying on some passive channels longer than it should.
However, it should eventually recover and complete the scan.
This is a work in progress; please let me know if things get stuck or
if things improve!
Tested:
* intel centrino 2200
* intel centrino 2230
* intel 6200
* intel 5100
* intel 4965 (gets upset, but that's a known issue)
Obtained from: linux iwlwifi
TX ring according to what the firmware requires.
The firmware requires A-MPDU sub-frames to be at a very specific ring
offset - that is, the ring slot offset should be (seqno % 256.)
This holds for every NIC I've tested thus far except the 4965,
which starts erroring out here shortly before the firmware panics.
Which is good, it's doing what it's supposed to (read: capture that
we've screwed up somewhere.)
The specifics about getting this stuff right:
* the initial seqno allocation should match up with the ringid.
* .. yes, this means we can start at a ring offset that isn't zero.
* .. because we program the start seqno in the firmware message
to setup the AC.
* The initial seqno allocation may be non-zero _and_ frames may be
being transmitted during a-mpdu negotiation. I faced similar
issues on ath(4) and had to software queue frames to that node+TID
during A-MPDU negotiation.
* seqno allocation should be in lockstep with ring increments.
* If we fail to transmit some segment, no, we shouldn't reuse that
ring slot. We should just transmit a BAR (which we aren't yet
doing, sigh) and move onto the next seqno.
* In theory there shouldn't be any holes in the seqno space when
we are transmitting frames.
Tested:
* 4965 (throws problems, so yes we have to fix this);
* 5100 (seems ok);
* 6200 (seems ok);
* 2200 (seems ok);
* 2230 (seems ok).
The directory sys/dev/drm2/i915 is apperently contributed code.
Revert to the broken version of this file to make future imports easier.
Requested by: kib
- The remote host sends a FIN
- in an ACK for a sequence number for which an ACK has already
been received
- There is still unacked data on route to the remote host
- The packet does not contain a window update
The packet may be dropped without processing the FIN flag.
PR: kern/99188
Submitted by: Staffan Ulfberg <staffan@ulfberg.se>
Discussed with: andre
MFC after: never
MACHINE_ARCH values whose binaries this kernel can run. This patch provides
a feature requested for implementing pkgng ABI identifiers in a robust
way.
The list is designed to indicate whether, say, an i386 package can be run on
the current system. If kern.supported_abis contains "i386", then the answer
is yes. Otherwise, the answer is no.
At the moment, this only supports MACHINE_ARCH and MACHINE_ARCH32. As we
gain support for more interesting combinations, this needs to become more
flexible, possibily through the sysent framework, along with the
hw.machine_arch emulation immediately preceding this code in kern_mib.c.
Reviewed by: imp
MFC after: 3 days
Open Firmware-centric:
- Keep the static list of regions in platform.c instead of ofw_machdep.c
- Move various merging and sorting operations to platform.c as well
- Move apple_hacks code out of ofw_machdep.c and into platform_powermac.c,
where it belongs
- Move CHRP-specific dynamic-reconfiguration memory parsing into
platform_chrp.c instead of pretending it is shared code
in /chosen, be ihandles. The ePAPR spec makes those cross-reference phandles,
since FDT has no concept of ihandles. Have the OF FDT CI module interpret
queries about ihandles as cross-reference phandles.
We had previously tried to flush all MKDIR_PARENT dependencies (and
all the NEWBLOCK pagedeps) by calling ffs_update(). However this will
only resolve these dependencies in direct blocks. So very large
directories with MKDIR_PARENT dependencies in indirect blocks had
not yet gotten flushed. As the directory is in the midst of doing a
complete sync, we simply defer the checking of the MKDIR_PARENT
dependencies until the indirect blocks have been sync'ed.
Reported by: Shawn Wallbridge of imaginaryforces.com
Tested by: John-Mark Gurney <jmg@funkthat.com>
PR: 183424
MFC after: 2 weeks
for extending and reusing it.
The sendfile_sync wrapper is mostly just a "mbuf transaction" wrapper,
used to indicate that the backing store for a group of mbufs has completed.
It's only being used by sendfile for now and it's only implementing a
sleep/wakeup rendezvous. However, there are other potential signaling
paths (kqueue) and other potential uses (socket zero-copy write) where the
same mechanism would also be useful.
So, with that in mind:
* extract the sendfile_sync code out into sf_sync_*() methods
* teach the sf_sync_alloc method about the current config flag -
it will eventually know about kqueue.
* move the sendfile_sync code out of do_sendfile() - the only thing
it now knows about is the sfs pointer. The guts of the sync
rendezvous (setup, rendezvous/wait, free) is now done in the
syscall wrapper.
* .. and teach the 32-bit compat sendfile call the same.
This should be a no-op. It's primarily preparation work for teaching
the sendfile_sync about kqueue notification.
Tested:
* Peter Holm's sendfile stress / regression scripts
Sponsored by: Netflix, Inc.
