even if there was non-zero number of restarts, we would unref/clear
all value references and start ipfw_link_table_values() once again
with (mostly) cleared "tei" buffer.
Additionally, ptei->ptv stores only to-be-added values, not existing ones.
This is a forgotten piece of previous value refconting implementation,
and now it is simply incorrect.
frames to 0
From IEEE Std. 802.11-2012, 8.3.2.1 "Data frame format", p. 415 (513):
"The Sequence Control field for QoS (+)Null frames is ignored by the receiver
upon reception."
At this moment, any <mode>_input() function interprets them as regular QoS data
frames with TID = 0. As a result, stations, that use another TX sequence for
QoS Null frames (e.g. wpi(4), where (QoS) Null frames are generated by the
firmware), may experience significant packet loss with any other NIC in hostap
mode.
Tested:
* wpi(4) (author)
* iwn(4) - Intel 5100, STA mode (me)
PR: kern/200128
Submitted by: Andriy Voskoboinyk <s3erios@gmail.com>
The aml8726-m3 SoC is identified as a Cortex A9-r2 rev 4 CPU and
it hangs sometimes during the boot when WFI is used by the kernel.
Differential Revision: https://reviews.freebsd.org/D2473
Submitted by: John Wehle
Suggested by: ian@
packets on tunnel interfaces. Add support of these ioctls to gre(4),
gif(4) and me(4) interfaces. For incoming packets M_SETFIB() should use
if_fib value from ifnet structure, use proper value in gre(4) and me(4).
Differential Revision: https://reviews.freebsd.org/D2462
No objection from: #network
MFC after: 2 weeks
Sponsored by: Yandex LLC
because a link where looped back NS messages are permanently observed
does not work with either NDP or ARP for IPv4.
- draft-ietf-6man-enhanced-dad is now RFC 7527.
Discussed with: hiren
MFC after: 3 days
Summary:
The Freescale PCIe Root Complex shows up as a Processor class device, PowerPC
subclass, so the generic PCI code ignores it for a bridge. This adds support
for it.
As part of this, update the Freescale PCI hostbridge driver, to allow probing
beyond the root complex, instead of only allowing "proper" PCI-PCI bridges.
Reviewers: #powerpc, marcel, nwhitehorn
Reviewed By: nwhitehorn
Subscribers: imp
Differential Revision: https://reviews.freebsd.org/D2442
Relnotes: yes
because the i386 pmap on which the new armv6 pmap is based had it, and in
r281707 pmap_lazyfix() was removed from the i386 pmap.
Discussed with: kib
Submitted by: Michal Meloun (via Svatopluk Kraus)
main ARMv6 target, the Raspberry Pi, doesn't support Thumb-2.
This as been tested with a Thumb-2 userland, however building one is
currently unsupported as there are known toolchain issues breaking some
binaries. Further work will also be needed to decide on the method of
selecting which instruction set to build for, and to benchmark both to
find how building everything as Thumb-2 will affect performance.
Relnotes: yes
This allows to ensure that we do not write to a file that was opened
for reading only or vice versa.
Also, use the correct capability in in zfs_ioc_send_new().
Differential Revision: https://reviews.freebsd.org/D2382
Reviewed by: delphij
MFC after: 17 days
Sponsored by: ClusterHQ
positive value since it adds the current tick to its result. This differs
from the behaviour in Linux, whose implementation does not add the extra
tick, so subtract the extra tick in the OFED compat layer implementation.
This addresses some incorrect handling of IB MAD timeouts, since some IB
code depends on msecs_to_jiffies(0) returning 0.
MFC after: 1 week
Sponsored by: EMC / Isilon Storage Division
results.
Right now the scan infrastructure assumes the channel is under net80211
control, and that when receiving beacon frames for scanning, the
current channel is indeed what ic_curchan is set to.
But firmware NICs with firmware scan support need more than this -
they can do background scans whilst hiding the off-channel behaviour
from net80211. Ie, net80211 still thinks everything is associated
and on the main channel, but it's getting scan results from all the
background traffic.
However sta_add() pays attention to ic_curchan and discards scan
results that aren't on the right channel. CCK beacon frames can be
decoded from adjacent channels so the receive path and sta_add
discard these as appropriate. This is fine for software scanning
like for ath(4), but not for firmware NICs. So with those, the
whole concept of background firmware scanning won't work without
major hacks (eg, overriding ic_curchan before calling the beacon
input / scan add.)
As part of my scan overhaul, modify sta_add() and the scan_add()
APIs to take an explicit current channel. The normal RX path
will set it to ic_curchan so it's a no-op. However, drivers may
decide to (eventually!) override the scan method to set the
"right" current channel based on what the firmware reports the
scan state is.
So for example, iwn, rsu and other NICs will eventually do this:
* driver issues scan start firmware command;
* firmware sends a "scan start on channel X" notify;
* firmware sends a bunch of beacon RX's as part of
the scan results;
* .. and the driver will replace scan_add() curchan with channel X,
so scan results are correct.
* firmware sends a "scan start on channel Y" notify;
* firmware sends more beacons...
* .. the driver replaces scan_add() curchan with channel Y.
Note:
* Eventually, net80211 should eventually grow the idea of a per-packet
current channel. It's possible in various modes (eg WAVE, P2P, etc)
that individual frames can come in from different channels and that
is under firmware control rather than driver/net80211 control, so
we should support that.
lies within the last block of the bit set and no bits are set beyond the
offset, terminate the search immediately instead of continuing as though
there are further blocks in the set and subsequently returning an incorrect
result.
MFC after: 1 week
Sponsored by: EMC / Isilon Storage Division
Several improvements to the Synaptics driver to support
semi-multitouch trackpads and some other fixes:
- Two finger scrolling support for "semi-MT" touchpads. Those include
many of the older Synaptics touchpads before "true" multitouch support
(indicated by capMultiFinger). Semi-MT touchpads can report a second
finger position, but the X or Y coordinate may be swapped with some
coordinate of the first finger. This is a result of how the hardware
works internally. Therefore, all that can be reliably extracted is the
bounding box of the two finger positions. Semi-MT touchpads can be
recognized by the capAdvancedGestures capability bit. After setting the
mode byte, advanced gestures mode has to be enabled. Then, data packets
compatible with the capMultiFinger format are sent, so the same two
finger scrolling code can be leveraged. Enabling advanced gestures mode
on true multitouch touchpads should be harmless. Linux seems to always
enable advanced gestures mode.
- Put mode setting logic into own functions synaptics_preferred_mode()
and synaptics_set_mode() to have this in one place.
synaptics_passthrough_on() and synaptics_passthrough_off() currently
always use 0xc1 as the mode byte, which may be wrong for touchpads that
don't have capExtended.
- Expose X and Y resolution of touchpad to userland. Also expose minimum
and maximum X and Y coordinates. This is useful for programs in
userspace that read raw PSM packets (with PSM_LEVEL_NATIVE enabled) and
need to interpret the coordinates.
- Also send "extended w mode" packets (see section 3.2.9 of
511-000275-01_RevB.pdf) to userspace if PSM_LEVEL_NATIVE is enabled.
This is useful for userspace programs/drivers such as
xf86-input-synaptics that can handle these packets.
- Fix parsing of nExtendedQueries, and request extended/continued
capability bits depending on this value.
- capReportsMax, capClearPad, capAdvancedGestures and capCoveredPad must
be extracted from status[0] and not status[2], I think.
Submitted by: Jan Kokemüller jan.kokemueller at gmail.com
static-linked to run at a fixed position, is still installed to maintain
compatibility with existing configurations. The makefile now also creates
and installs ubldr.bin, a stripped binary (no elf headers) with an entry
point offset of 0 that can be loaded by u-boot at any address and launched
with "go ${loadaddr}".
To use ubldr.bin, U-Boot must still be built with the CONFIG_API option,
but no longer needs the CONFIG_ELF option.
return a value.
Despite what I said in my prior commit, it turns out this one platform
was checking the return value from the old self-reloc code (which returned
a hard-coded 0).
The function was defined as taking 4 parameters and returning EFI_STATUS,
but all existing callers (in asm code) passed only two parameters and don't
use the return value. The function signature now matches that usage, and
doesn't refer to efi-specific types.
Parameters and variables now use the cannonical typenames set up by elf.h
(Elf_Word, Elf_Addr, etc) instead of raw C types. Hopefully this will
prevent suprises as new platforms come along and use this code.
The function was renamed from _reloc() to self_reloc() to emphasize its
difference from the other elf relocation code found in boot/common.
Differential Revision: https://reviews.freebsd.org/D2490
allocated from exec_map. If many threads try to perform execve(2) in
parallel, the exec map is exhausted and some threads sleep
uninterruptible waiting for the map space. Then, the thread which won
the race for the space allocation, cannot single-thread the process,
causing deadlock.
Reported and tested by: pho (previous version)
Sponsored by: The FreeBSD Foundation
MFC after: 2 weeks
It turns out that ieee80211_start_scan_locked() is only ever called by
the swscan code and it won't likely be required by firmware scanning
implementations.
So, don't bother keeping it in ieee80211_scan.c and it likely won't
become an API call.
Tested:
* Intel 5100, STA mode
* AR5416, STA mode
to us. Instead, advertise what we can do based on what the AP says and what
we're capped at by the VAP settings.
For non-STA modes we still advertise what our VAP settings are.
It may be that I've over-complicated this and instead of capping things
we can just always announce what we're capable of. But this should at least
stop the blatantly wrong handling of A-MPDU parameters.
(I'll happily simplify things if someone can dig up a replacement, better
compliant behaviour.)
PR: kern/176201
bus_alloc_resource(), bus_release_resource() and bus_set_resource()
(bus_generic_rl_alloc_resource(), bus_generic_rl_release_resource() and
bus_generic_rl_set_resource() respectively).
Do not print the resources for nomatch devices.
Use the inherited method for bus_get_resource_list() on ofw_iicbus.c.
Submitted by: jhb and Michal Meloun (D2033)
Of note:
- This commit adds native FreeBSD/arm release build support without
requiring out-of-tree utilities.
- Part of this merge removes the WANDBOARD-{SOLO,DUAL,QUAD} kernel
configuration files, for which the IMX6 kernel configuration file
should be used instead.
- The resulting images have a 'freebsd' user (password 'freebsd'),
to allow ssh(1) access when console access is not available (VGA
or serial). The default 'root' user password is set to 'root'.
- The /etc/ttys file for arm images now enable both ttyv0 and ttyu0
by default.
Help from: many (boot testing, feedback, etc.)
Sponsored by: The FreeBSD Foundation
