hhook_{add|remove}_hook_lookup() so that khelp (and other potential API
consumers) do not have to care when they attempt to (un)hook a particular hook
point identified by id and type.
Reviewed by: scottl
MFC after: 1 week
QEMU 1.4 made the descriptor requirement stricter - the size of buffer
descriptor must exactly match the number of MAC addresses provided.
PR: kern/178955
MFC after: 5 days
Move FreeBSD from interface version 0x00030204 to 0x00030208.
Updates are required to our grant table implementation before we
can bump this further.
sys/xen/hvm.h:
Replace the implementation of hvm_get_parameter(), formerly located
in sys/xen/interface/hvm/params.h. Linux has a similar file which
primarily stores this function.
sys/xen/xenstore/xenstore.c:
Include new xen/hvm.h header file to get hvm_get_parameter().
sys/amd64/include/xen/xen-os.h:
sys/i386/include/xen/xen-os.h:
Correctly protect function definition and variables from being
included into assembly files in xen-os.h
Xen memory barriers are now prefixed with "xen_" to avoid conflicts
with OS native primatives. Define Xen memory barriers in terms of
the native FreeBSD primatives.
Sponsored by: Spectra Logic Corporation
Reviewed by: Roger Pau Monné
Tested by: Roger Pau Monné
Obtained from: Roger Pau Monné (bug fixes)
Run hierarchy with WORLDTMP in the path so it works when it is invoked
directly. Such use is nearly alwasy wrong but appears to be common.[1]
PR: conf/178209 [0], conf/178547 [1]
Submitted by: Garrett Cooper <yaneurabeya@gmail.com> [0]
MFC after: 5 days
[ms-inline asm] Fix a crasher when we fail on a direct match.
The issue was that the MatchingInlineAsm and VariantID args to the
MatchInstructionImpl function weren't being set properly. Specifically, when
parsing intel syntax, the parser thought it was parsing inline assembly in the
at&t dialect; that will never be the case.
The crash was caused when the emitter tried to emit the instruction, but the
operands weren't set. When parsing inline assembly we only set the opcode, not
the operands, which is used to lookup the instruction descriptor.
rdar://13854391 and PR15945
Also, this commit reverts r176036. Now that we're correctly parsing the intel
syntax the pushad/popad don't match properly. I've reimplemented that fix using
a MnemonicAlias.
Pull in r183907 from llvm trunk:
X86: Make the cmov aliases work with intel syntax too.
These commits make a number of Intel-style inline assembly mnemonics
aliases (occurring in several ports) work properly, which could cause
assertions otherwise.
Reported by: kwm, bapt
should be processed. De-select each package as we "process" (actual
processing still pending) each package so that if we get an error, we can
return to an accurate state of selected packages.
KASSERT during TCP hhook registration at boot. Virtualised hook points only
require extra housekeeping and sanity checking when "options VIMAGE" is present.
Reported by: bdrewery,jh,dhw
Tested by: dhw
MFC after: 1 week
X-MFC with: 251732
scheme for defining inline command queuing functions.
Prefer enums to #defines.
sys/dev/xen/blkfront/block.h
Replace inline function generation performed by the
XBDQ_COMMAND_QUEUE() macro with single instances of each
inline function (init, enqueue, dequeue, remove). This was
made possible by using queue indexes instead of bit flags
in the command structure, and passing the index enum as
an argument to the functions.
Improve panic/assert messages in the queue functions.
Combine queue data and stats into a single data structure
and declare an array of them instead of each queue individually.
Convert command flags, softc state, and softc flags to enums.
sys/dev/xen/blkfront/blkfront.c
Mechanical adjustments for new queue api.
Sponsored by: Spectra Logic Corporation
MFC after: 1 week
so that job token pipe is passed to them.
To avoid surprising anyone, only add .MAKE to ${TGTS} when -n
has not been specified (at least for Makefile).
Reviewed by: obrien
But we don't want to set it to + for bmake since it breaks make -N
which is used to supress the normal handling of targets marked with .MAKE
(which seems broken in fmake and might be why _+_ was introduced).
Add some comments to explain what's gong on.
Reviewed by: obrien
- remove return statements from void function [1]
- include missing header
- use O_CLOEXEC instead of separate fcntl() calls
PR: docs/179459 [1]
MFC after: 1 week
This hasn't yet been tested as unfortunately the AR3012 I have doesn't
have the "real" firmware on it; it shipped with the cut down HCI firmware
that only understands enough to accept a new firmware image.
* Linux ath9k (GPIO constants)
NICs which have bluetooth coexistence enabled.
The WB225 NIC has the common antenna switch configuration set to 0x0 which
disables all external switch bit setting. This obviously won't work when
doing coexistence.
This value is a magic value from the windows .inf files. It _looks_ right
but I haven't yet verified it - unfortunately my AR9285+AR3012 BT combo
has an earlier BT device which doesn't actually _have_ firmware on it.
So I have to fix ath3kfw to handle loading in firmware into the newer
NICs before I can finish testing this.
This may not hold true for CUS198, which is another custom AR9485 board.
The bluetooth setup code actually does a channel lookup during setup,
even though we haven't yet programmed in a channel. Sigh.
Tested:
* WB225 (AR9485) + bluetooth
generic mii_phy_reset().
- Return the result of mii_mediachg() rather than blindly returning 0.
- on smsc(4), driver lock should be held to get current
mii_media_active/mii_media_status value.
Reviewed by: yongari
type and id, as compared to virtualised hook points which are now uniquely
identified by type, id and a vid (which for vimage is the pointer to the vnet
that the hhook resides in).
All hhook_head structs for both virtualised and non-virtualised hook points
coexist in hhook_head_list, and a separate list is maintained for hhook points
within each vnet to simplify some vimage-related housekeeping.
Reviewed by: scottl
MFC after: 1 week
* Add the LNA configuration table entries for AR933x/AR9485
* Add a chip-dependent LNA signal level delta in the startup path
* Add a TODO list for the stuff I haven't yet ported over but
I haven't.
Tested:
* AR9462 with LNA diversity enabled
In netif_free(), call ifmedia_removeall() after ether_ifdetach()
so that bpf listeners are detached, any link state processing
is completed, and there is no chance for external reference to media
information.
Suggested by: yongari
MFC after: 1 week
exact same (subsystem) device and vendor IDs. However, the reference
design for the OXu16PCI954 uses a 14.7456 MHz clock (as does the EXSYS
EX-41098-2 equipped with these), while at least the OX16PCI954 defaults
to a 1.8432 MHz one. According to the datasheets of these chips, the
only difference in PCI configuration space is that OXu16PCI954 have
a revision ID of 1 while the other two are at 0. So employ the latter
for determining the default clock rates of this family.
Note that one might think that the actual clock could be derived from
the Clock Prescaler Register (CPR) of these chips. Unfortunately, this
is not that case and its use and content are orthogonal to the frequency
of the crystal employed.
Tested with an EXSYS EX-41098-2, which identifies and attaches as:
pcib4@pci0:19:0:0: class=0x060400 card=0x02dd1014 chip=0x10801b21
rev=0x03 hdr=0x01
vendor = 'ASMedia Technology Inc.'
device = 'ASM1083/1085 PCIe to PCI Bridge'
class = bridge
subclass = PCI-PCI
puc0@pci0:20:4:0: class=0x070006 card=0x00001415 chip=0x95011415
rev=0x01 hdr=0x00
vendor = 'Oxford Semiconductor Ltd'
device = 'OX16PCI954 (Quad 16950 UART) function 0 (Uart)'
class = simple comms
subclass = UART
puc1@pci0:20:4:1: class=0x068000 card=0x00001415 chip=0x95111415
rev=0x01 hdr=0x00
vendor = 'Oxford Semiconductor Ltd'
device = 'OX16PCI954 (Quad 16950 UART) function 1 (8bit bus)'
class = bridge
puc2@pci0:20:8:0: class=0x070006 card=0x00001415 chip=0x95011415
rev=0x01 hdr=0x00
vendor = 'Oxford Semiconductor Ltd'
device = 'OX16PCI954 (Quad 16950 UART) function 0 (Uart)'
class = simple comms
subclass = UART
puc3@pci0:20:8:1: class=0x068000 card=0x00001415 chip=0x95111415
rev=0x01 hdr=0x00
vendor = 'Oxford Semiconductor Ltd'
device = 'OX16PCI954 (Quad 16950 UART) function 1 (8bit bus)'
class = bridge
pci20: <ACPI PCI bus> on pcib4
puc0: <Oxford Semiconductor OX16PCI954 UARTs> port 0x5000-0x501f,
0x5020-0x503f mem 0xc6000000-0xc6000fff,0xc6001000-0xc6001fff irq 16 at
device 4.0 on pci20
uart1: <16950 or compatible> at port 1 on puc0
uart2: <16950 or compatible> at port 2 on puc0
uart3: <16950 or compatible> at port 3 on puc0
uart4: <16950 or compatible> at port 4 on puc0
puc1: <Oxford Semiconductor OX9160/OX16PCI954 UARTs (function 1)> port
0x5040-0x505f,0x5060-0x507f mem 0xc6002000-0xc6002fff,0xc6003000-0xc6003fff
irq 16 at device 4.1 on pci20
puc2: <Oxford Semiconductor OX16PCI954 UARTs> port 0x5080-0x509f,
0x50a0-0x50bf mem 0xc6004000-0xc6004fff,0xc6005000-0xc6005fff irq 16 at
device 8.0 on pci20
uart5: <16950 or compatible> at port 1 on puc2
uart6: <16950 or compatible> at port 2 on puc2
uart7: <16950 or compatible> at port 3 on puc2
uart8: <16950 or compatible> at port 4 on puc2
puc3: <Oxford Semiconductor OX9160/OX16PCI954 UARTs (function 1)> port
0x50c0-0x50df,0x50e0-0x50ff mem 0xc6006000-0xc6006fff,0xc6007000-0xc6007fff
irq 16 at device 8.1 on pci20
MFC after: 2 weeks
check which variant we are on, and if it is a VFPv3 or v4, and has 32
double registers we save these. This fixes VFP support on Raspberry Pi.
While here clean fmrx and fmxr up to use the register names from vfp.h
as opposed to the raw register names.
bitmap using sys/bitset. This is much simpler, has lower space
overhead and is cheaper in most cases.
- Use a second bitmap for invariants asserts and improve the quality of
the asserts as well as the number of erroneous conditions that we will
catch.
- Drastically simplify sizing code. Special case refcnt zones since they
will be going away.
- Update stale comments.
Sponsored by: EMC / Isilon Storage Division
Basically the situation is as follows:
- When using Clang + armv6, we should not need any intrinsics. It should
support it, even though due to a target misconfiguration it does not.
We should fix this in Clang.
- When using Clang + noarmv6, provide __atomic_* functions that disable
interrupts.
- When using GCC + armv6, we can provide __sync_* intrinsics, similar to
what we did for MIPS. As ARM and MIPS are quite similar, simply base
this implementation on the one I did for MIPS.
- When using GCC + noarmv6, disable the interrupts, like we do for
Clang.
This implementation still lacks functions for noarmv6 userspace. To be
done.
- Define __SYNC_ATOMICS in case we're using the __sync_*() API. This is
not used by <stdatomic.h> itself, but may be useful for some of the
intrinsics code to determine whether it should build the
machine-dependent intrinsic functions.
- Make is_lock_free() work in kernelspace. For now, assume atomics in
kernelspace are always lock free. This is a quite reasonable
assumption, as we surely shouldn't implement the atomic fallbacks for
arbitrary sizes.
- When looping, check for the pending suspension. Otherwise, other
usermode thread which races with the looping one, could try to
prevent the process from stopping or exiting.
- Add missed checks for the faults from casuword*(). The code is
structured in a way which makes the loops exit if the specified
address is invalid, since both fuword() and casuword() return -1 on
the fault. But if the address is mapped readonly, the typical value
read by fuword() is different from -1, while casuword() returns -1.
Absent the checks for casuword() faults, this is interpreted as the
race with other thread and causes non-interruptible spinning in the
kernel.
Reported and tested by: pho
Sponsored by: The FreeBSD Foundation
MFC after: 2 weeks
Before this change state creating sequence was:
1) lock wire key hash
2) link state's wire key
3) unlock wire key hash
4) lock stack key hash
5) link state's stack key
6) unlock stack key hash
7) lock ID hash
8) link into ID hash
9) unlock ID hash
What could happen here is that other thread finds the state via key
hash lookup after 6), locks ID hash and does some processing of the
state. When the thread creating state unblocks, it finds the state
it was inserting already non-virgin.
Now we perform proper interlocking between key hash locks and ID hash
lock:
1) lock wire & stack hashes
2) link state's keys
3) lock ID hash
4) unlock wire & stack hashes
5) link into ID hash
6) unlock ID hash
To achieve that, the following hacking was performed in pf_state_key_attach():
- Key hash mutex is marked with MTX_DUPOK.
- To avoid deadlock on 2 key hash mutexes, we lock them in order determined
by their address value.
- pf_state_key_attach() had a magic to reuse a > FIN_WAIT_2 state. It unlinked
the conflicting state synchronously. In theory this could require locking
a third key hash, which we can't do now.
Now we do not remove the state immediately, instead we leave this task to
the purge thread. To avoid conflicts in a short period before state is
purged, we push to the very end of the TAILQ.
- On success, before dropping key hash locks, pf_state_key_attach() locks
ID hash and returns.
Tested by: Ian FREISLICH <ianf clue.co.za>
