From NetBSD christos Sat Jan 26 00:19:39 2013 +0000
make the buffer functions look exactly like the kernel ones and add other
cruft to make the kernel files compile.
ffs.c 1.54
ffs/buf.c 1.13
ffs/buf.h 1.3
ffs/ffs_alloc.c 1.21
ffs/ffs_balloc.c 1.15
Reviewed by: marcel, ngie
Obtained from: NetBSD
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D8404
The isp(4) driver was changing the tag type for REQUEST SENSE
commands to Head of Queue, when the CAM CCB flag
CAM_TAG_ACTION_VALID was NOT set. CAM_TAG_ACTION_VALID is set
when the tag action in the XPT_SCSI_IO is not CAM_TAG_ACTION_NONE
and when the target has tagged queueing turned on.
In most cases when CAM_TAG_ACTION_VALID is not set, it is because
the target is not doing tagged queueing. In those cases, trying to
send a Head of Queue tag may cause problems. Instead, default to
sending a simple tag.
IBM tape drives claim to support tagged queueing in their standard
Inquiry data, but have the DQue bit set in the control mode page
(mode page 10). CAM correctly detects that these drives do not
support tagged queueing, and clears the CAM_TAG_ACTION_VALID flag
on CCBs sent down to the drives.
This caused the isp(4) driver to go down the path of setting the
tag action to a default value, and for Request Sense commands only,
set the tag action to Head of Queue.
If an IBM tape drive does get a Head of Queue tag, it rejects it with
Invalid Message Error (0x49,0x00). (The Qlogic firmware translates that
to a Transport Error, which the driver translates to an Unrecoverable
HBA Error, or CAM_UNREC_HBA_ERROR.) So, by default, it wasn't possible
to get a good response from a REQUEST SENSE to an FC-attached IBM
tape drive with the isp(4) driver.
IBM tape drives (tested on an LTO-5 with G9N1 firmware and a TS1150
with 4470 firmware) also have a bug in that sending a command with a
non-simple tag attribute breaks the tape drive's Command Reference
Number (CRN) accounting and causes it to ignore all subsequent
commands because it and the initiator disagree about the next
expected CRN. The drives do reject the initial command with a head
of queue tag with an Invalid Message Error (0x49,0x00), but after that
they ignore any subsequent commands. IBM confirmed that it is a bug,
and sent me test firmware that fixes the bug. However tape drives in
the field will still exhibit the bug until they are upgraded.
Request Sense is not often sent to targets because most errors are
reported automatically through autosense in Fibre Channel and other
modern transports. ("Modern" meaning post SCSI-2.) So this is not
an error that would crop up frequently. But Request Sense is useful on
tape devices to report status information, aside from error reporting.
This problem is less serious without FC-Tape features turned on,
specifically precise delivery of commands (which enables Command
Reference Numbers), enabled on the target and initiator. Without
FC-Tape features turned on, the target would return an error and
things would continue on.
And it also does not cause problems for targets that do tagged
queueing, because in those cases the isp(4) driver just uses the
tag type that is specified in the CCB, assuming the
CAM_TAG_ACTION_VALID flag is set, and defaults to sending a Simple
tag action if it isn't an ordered or head of queue tag.
sys/dev/isp/isp.c:
In isp_start(), don't try to send Request Sense commands
with the Head of Queue tag attribute if the CCB doesn't
have a valid tag action. The tag action likely isn't valid
because the target doesn't support tagged queueing.
Sponsored by: Spectra Logic
MFC after: 3 days
Some recent changes to vm related to mmap(2) have broken the prot checks that
would result with an EINVAL with this case
I suspect r313352 is the root-cause the issue
PR: 216976
Sponsored by: Dell EMC Isilon
This information is less useful when the generated files are included in
source control along with the source. If needed it can be reconstructed
from the $FreeBSD$ tag in the generated file. Removing this information
from the generated output permits committing the generated files along
with the change to the system call master list without having inconsistent
metadata in the generated files.
Reviewed by: emaste, kib
MFC after: 1 month
Differential Revision: https://reviews.freebsd.org/D9497
ld.bfd generates two PT_LOAD segments, but certain linkers or linker
configurations generate three PT_LOAD segments (one additional for
RELRO).
PR: 216975
Reported by: Shawn Webb
MFC after: 1 week
Sponsored by: The FreeBSD Foundation
When using Blue-Flame, BF, the QPN overrides the VLAN, CV, and SV
fields in the WQE. Thus, BF may only be used for QPNs with bits 6,7
unset.
The current ethernet driver code reserves a TX QP range with 256b
alignment.
This is wrong because if there are more than 64 TX QPs in use, QPNs >=
base + 65 will have bits 6/7 set.
This problem is not specific for the Ethernet driver, any entity that
tries to reserve more than 64 BF-enabled QPs should fail. Also, using
ranges is not necessary here and is wasteful.
The new mechanism introduced here will support reservation for "Eth
QPs eligible for BF" for all drivers: bare-metal, multi-PF, and VFs
(when hypervisors support WC in VMs). The flow we use is:
1. In mlx4_en, allocate Tx QPs one by one instead of a range allocation,
and request "BF enabled QPs" if BF is supported for the function
2. In the ALLOC_RES FW command, change param1 to:
a. param1[23:0] - number of QPs
b. param1[31-24] - flags controlling QPs reservation
Bit 31 refers to Eth blueflame supported QPs. Those QPs must have bits
6 and 7 unset in order to be used in Ethernet.
Bits 24-30 of the flags are currently reserved.
When a function tries to allocate a QP, it states the required
attributes for this QP. Those attributes are considered "best-effort".
If an attribute, such as Ethernet BF enabled QP, is a must-have
attribute, the function has to check that attribute is supported
before trying to do the allocation.
In a lower layer of the code, mlx4_qp_reserve_range masks out the bits
which are unsupported. If SRIOV is used, the PF validates those
attributes and masks out unsupported attributes as well. In order to
notify VFs which attributes are supported, the VF uses QUERY_FUNC_CAP
command. This command's mailbox is filled by the PF, which notifies
which QP allocation attributes it supports.
Obtained from: Linux (dual BSD/GPLv2 licensed)
Submitted by: Dexuan Cui @ microsoft . com
Differential Revision: https://reviews.freebsd.org/D8868
MFC after: 2 weeks
Sponsored by: Mellanox Technologies
Previously, the mlx4 driver queried the firmware in order to get the
number of supported EQs. Under SRIOV, since this was done before the
driver notified the firmware how many VFs it actually needs, the
firmware had to take into account a worst case scenario and always
allocated four EQs per VF, where one was used for events while the
others were used for completions. Now, when the firmware supports the
asymmetric allocation scheme, denoted by exposing num_sys_eqs > 0 (-->
MLX4_DEV_CAP_FLAG2_SYS_EQS), we use the QUERY_FUNC command to query
the firmware before enabling SRIOV. Thus we can get more EQs and MSI-X
vectors per function. Moreover, when running in the new
firmware/driver mode, the limitation that the number of EQs should be
a power of two is lifted.
Obtained from: Linux (dual BSD/GPLv2 licensed)
Submitted by: Dexuan Cui @ microsoft . com
Differential Revision: https://reviews.freebsd.org/D8867
MFC after: 2 weeks
Sponsored by: Mellanox Technologies
The hpt27xx(4), hptnr(4), and hptrr(4) drivers declare MIN() and MAX()
internally which match the macros from sys/param.h.
MIN() is not used, MAX is only used once and can be replaced with the
max() version in libkern.h which operates on u_ints.
MFC after: 2 weeks
The file type DTYPE_VNODE can be assigned as a fallback if VOP_OPEN()
did not initialized file type. This is a typical code path used by
normal file systems.
Also, change error returned for inappropriate file type used for
O_EXLOCK to EOPNOTSUPP, as declared in the open(2) man page.
Reported by: cy, dhw, Iblis Lin <iblis@hs.ntnu.edu.tw>
Tested by: dhw
Sponsored by: The FreeBSD Foundation
MFC after: 13 days
These examples show expected behavior of indent(1). They are meant to be used
together with a regression test mechanism, either Kyua, a Makefile or perhaps
something else. The mechanism should in essence do this:
indent -P${test}.pro < ${test}.0 > ${test}.0.run
and compare ${test}.0.stdout to ${test}.0.run. If the files differ or the exit
status isn't 0, the test failed.
* ${test}.pro is an indent(1) profile: a list of options passed through a file.
The program doesn't complain if the file doesn't exist.
* ${test}.0 is a C source file which acts as input for indent(1). It doesn't
have to have any particular formatting, since it's the output that matters.
* ${test}.0.stdout contains expected output. It doesn't have to be formatted in
Kernel Normal Form as the point of the tests is to check for regressions in
the program and not to check that it always produces KNF.
Reviewed by: ngie
Approved by: pfg (mentor)
Differential Revision: https://reviews.freebsd.org/D9007
Unfortunately they will have different integer value due to Linux value being already assigned in FreeBSD.
The patch is similar to IP_RECVDSTADDR but also provides the destination port value to the application.
This allows/improves implementation of transparent proxies on UDP sockets due to having the whole information on forwarded packets.
Sponsored-by: rsync.net
Differential Revision: D9235
Reviewed-by: adrian
Aliases are normally given names that include a key that's unique for each
input object file. This, for example, ensures that aliases for identically
named local symbols in different object files don't conflict. However, in
some cases the static linker will leave an undefined alias after merging
identical weak symbols, resulting in a link error. A non-unique name allows
the aliases to be merged as well.
PR: 216871
X-MFC With: r313262
Refresh upstream driver before impending conversion to iflib.
Major new features:
- Support for Fortville-based 25G adapters
- Support for I2C reads/writes
(To prevent getting or sending corrupt data, you should set
dev.ixl.0.debug.disable_fw_link_management=1 when using I2C
[this will disable link!], then set it to 0 when done. The driver implements
the SIOCGI2C ioctl, so ifconfig -v works for reading I2C data,
but there are read_i2c and write_i2c sysctls under the .debug sysctl tree
[the latter being useful for upper page support in QSFP+]).
- Addition of an iWARP client interface (so the future iWARP driver for
X722 devices can communicate with the base driver).
- Compiling this option in is enabled by default, with "options IXL_IW" in
GENERIC.
Differential Revision: https://reviews.freebsd.org/D9227
Reviewed by: sbruno
MFC after: 2 weeks
Sponsored by: Intel Corporation
If a file opened over a vnode has an advisory lock set at close,
vn_closefile() acquires additional vnode use reference to prevent
freeing the vnode in vn_close(). Side effect is that for device
vnodes, devfs_close() sees that vnode reference count is greater than
one and refuses to call d_close(). Create internal version of
vn_close() which can avoid dropping the vnode reference if needed, and
use this to execute VOP_CLOSE() without acquiring a new reference.
Note that any parallel reference to the vnode would still prevent
d_close call, if the reference is not from an opened file, e.g. due to
stat(2).
Tested by: pho
Sponsored by: The FreeBSD Foundation
MFC after: 2 weeks
for files which do not have DTYPE_VNODE type.
Both flock(2) and fcntl(2) syscalls refuse to acquire advisory lock on
a file which type is not DTYPE_VNODE. Do the same when lock is
requested from open(2).
Restructure the block in vn_open_vnode() which handles O_EXLOCK and
O_SHLOCK open flags to make it easier to quit its execution earlier
with an error.
Tested by: pho (previous version)
Sponsored by: The FreeBSD Foundation
MFC after: 2 weeks
Protected symbol reference in GOT of the defining object must be
resolved to itself, same as -Bsymbolic globally.
Discussed with: emaste
Sponsored by: The FreeBSD Foundation
MFC after: 2 weeks
Differential revision: https://reviews.freebsd.org/D9317
This implements hardware assisted quiet IE support. Quiet time is
an optional interval on DFS channels (but doesn't have to be DFS
only channels! sigh) where the station and AP can be quiet in order
to allow for channel utilisation measurements. Typically that's
stuff like radar detection, spectral scan, other-BSS frame sniffing,
checking how busy the air is, etc.
The hardware implements it as one of the generic timers, which is
supplied a period, offset from the trigger period and duration
to stay quiet. The AP can announce quiet time configurations which
change, and so this code also tracks that.
Implementation details:
* track the current quiet time IE
* compare the new one against the previous one - if only the TBTT
counter changes, don't update things
* If tbttcount=1 then program it into the hardware - that is when
it is easiest to program the correct starting offset (one TBTT +
configured offset).
* .. later on check to see if it can be done on any tbttcount
* If the IE goes away then remove the quiet timer and clear the
config
* Upon reset, state change, new beacon - clear quiet time IE
and just let it resync from the next beacon.
History:
This was work done initially by sibridgetech.com in 2011/2012/2013
as part of some FreeBSD wifi DFS contracting work they had for a
third party. They implemented the net80211 quiet time IE pieces
and had some test code for the station side which didn't entirely
use the timers correctly.
I figured out how to use the timers correctly without stopping/starting
the transmit DMA engine each time. When done correctly, the timer
just needs to be programmed once and left alone until the next
configuration change.
So, thanks to Himali Patel and Parthiv Shah for their work way
back then. I finally figured it out and finished it!
TODO:
* Now, I'd rather net80211 did the quiet time IE tracking and parsing,
pushing configurations into the driver is needed. I'll look at
doing that in a subsequent update.
* This doesn't handle multiple quiet time IEs, which will currently
just mess things up. I'll look into supporting that in the future
(at least by only obeying "one" of them, and then ignoring
subsequent IEs in a beacon/probe frame.)
* This also implements the STA side and not the AP side - the AP
side will come later, and involves taking various other intervals
into account (eg the beacon offset for multi-VAP modes, the
SWBA time, etc, etc) as well as obtaining the configuration when
a beacon is configured/generated rather than "hearing" an IE.
* .. investigate supporting quiet IE in mesh, tdma, ibss modes
* .. investigate supporting quiet IE for non-DFS channels
(so this can be done for say, 2GHz channels.)
* Chances are i should commit NULL methods for the ar5210, ar5211 HALs..
Tested:
* AR9380, STA mode - announcing quiet, removing quiet, changing quite
time config, whilst doing iperf testing;
* AR9380, AP mode.
sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c
* In zfs_freebsd_setattr, if the caller wants to set the birthtime,
set the bits that zfs_settattr expects
* In zfs_setattr, if XAT_CREATETIME is set, set xoa_createtime,
expected by zfs_xvattr_set. The two levels of indirection seem
excessive, but it minimizes diffs vs OpenZFS.
* In zfs_setattr, check for overflow of va_birthtime (from delphij)
* Remove red herring in zfs_getattr
sys/cddl/contrib/opensolaris/uts/common/sys/vnode.h
* Un-booby-trap some macros
New tests are under review at https://github.com/pjd/pjdfstest/pull/6
Reviewed by: avg
MFC after: 3 weeks
Sponsored by: Spectra Logic Corp
Differential Revision: https://reviews.freebsd.org/D9353
* 'blackhole' and 'reject' are mutually exclusive, replace printf() by errx()
when both are selected.
* 'trail' option is no longer supported since first import of arp from 4.4BSD.
XXX message was added 13 years ago in r128192. I believe it's time to remove
it.
* Use warnx() to print some informative messages instead of printf()
* Replace strncmp() by strcmp() when validating parameters and exit when invalid
parameter is found
Reviewed by: allanjude, vangyzen, cem
Approved by: allanjude
MFC after: 1 week
Sponsored by: Rubicon Communications (Netgate)
Differential Revision: https://reviews.freebsd.org/D9504
Update comments to note these functions are reachable if lockstat is
enabled.
Check if the lock has any bits set before attempting unlock, which saves
an unnecessary atomic operation.
Some U-Boot versions do not initialize MT7620's Frame Engine.
Then it is not possible to receive packets from the network.
Setting GDMA1 Frames Destination Port to Port 0 (CPU) in GDM Forwarding
Configuration register solves this issue.
Submitted by: Hiroki Mori (yamori813@yahoo.co.jp)
Reviewed by: adrian mizhka (previous version)
Differential Revision: https://reviews.freebsd.org/D9301
* on the station side, only call the quiet time IE method if we have a
quiet IE - otherwise call the NULL method once, and then don't waste
time calling NULL
* on the beacon generation side - force a beacon regeneration each time
quiet time is enabled/disabled. Without this, enabling/disabling quiet
time IE would cause the beacon contents to be corrupted since none of
the "move contents around" logic (like for CSA and TIM handling) is implemented.
This changes the size of ieee80211_node so it requires a kernel recompile,
but no userland recompile.
Tested:
* AR9380, AP mode, enabling/disabling quiet time IE
* AR9380, STA mode, with upcoming driver changes.
According to the specification, CIE code alignment factor is an
arbitrary unsigned LEB128 encoded value.
PR: 216908
Reported by: Wolfgang Meyer
Obtained from: Upstream LLD r277105
MFC after: 1 week
This improves singlethreaded throughput on my test machine from ~247 mln
ops/s to ~328 mln.
It is mostly about avoiding the setup cost of lockstat.
Reviewed by: jhb (previous version)
