The lang/gcc* ports patch headers where they think something is
non-standard. These patched headers override the system headers which means
you have to rebuild these ports whenever you do installworld to make sure
they contain the latest changes.
- Address performance regressions encountered by das@ by caching per-thread
data in TLS where available.
- Add a __NO_TLS flag to cdefs.h to indicate where not available.
- Reorganise the xlocale.h definitions into xlocale/*.h so that they can be
included from multiple places.
- Export the POSIX2008 subset of xlocale when POSIX2008 says it should be
exported, independently of whether xlocale.h is included.
- Fix the bug where programs using ctype functions always assumed ASCII unless
recompiled.
- Fix some style(9) violations.
Reviewed by: brooks (mentor)
Approved by: dim (mentor)
to a deadlock of an association when an IPv6 socket was used to
communcate with IPv4 and an ICMPv4 fragmentation needed message
was received.
While there, simplify the code a bit.
MFC after: 3 days.
MOD_SHUTDOWN is not an end of existence, and there is a life after it.
In particular, code previously called on MOD_SHUTDOWN grabbed lock and
deallocated unit numbering. That caused infinite wait loop if snd_uaudio
tried to destroy its PCM device after that point.
MFC after: 3 days
through by VMware so blacklist their PCI-PCI bridge for MSI/MSI-X here.
Note that besides currently there not being a quirk type that disables
MSI-X only and there's no evidence that MSI doesn't work with the VMware
pass-through, it's really questionable whether MSI generally works in
that setup as VMware only mention three know working devices [1, p. 4].
Also not that this quirk entry currently doesn't affect the devices
emulated by VMware in any way as these don't claim support MSI/MSI-X to
begin with. [2]
While at it, make the PCI quirk table const and static.
- Remove some duplicated empty lines.
- Use DEVMETHOD_END.
PR: 163812, http://forums.freebsd.org/showthread.php?t=27899 [2]
Reviewed by: jhb
MFC after: 3 days
txsync() and rxsync() callbacks, removing some variables made
useless by this change;
- add generic lock and irq handling routines. These can be useful
in case there are no driver locks that we can reuse;
- add a few macros to reduce differences with the Linux version.
Some older firmware versions have issues that can be worked around by
avoiding certain operations. Add a sysctl dev.aac.#.firmware_build to
make it easy for scripts or userland tools to detect the firmware
version.
* Change the mesh IE size to be IEEE80211_MESH_CONF_SZ rather than the
size of the structure;
* conf_cap is now a uint8_t rather than a uint16_t (uint16_t in D3.0,
uint8_t in the amendment spec);
* Update mesh config capability bits - earlier bits were from draft X,
current is amendment spec;
* Update the following to be an enum rather than #define and added
a VENDOR entry too from the amendment spec;
IEEE80211_MESHCONF_PATH_*
IEEE80211_MESHCONF_METRIC_*
IEEE80211_MESHCONF_CC_*
IEEE80211_MESHCONF_SYNC_*
IEEE80211_MESHCONF_AUTH_*
* Kept IEEE80211_MESHCONF_FORM_* and IEEE80211_MESHCONF_CAP_* as
defines because they are defined in a way that we need to mask in/out
information;
* In IEEE80211_MESHCONF_CAP_* IEEE80211_MESHCONF_CAP_TBTTA is removed
and 0x80 is made reserved as defined in the amendment spec.
Submitted by: monthadar@gmail.com
Reviewed by: rpaulo
When performing a firmware upgrade via atacontrol[1] the subsequent
command may time out producing the error message above. When this
happens the callout could still be active, and the system would then
panic due to a destroyed semaphore.
Instead, ensure that the callout is done first, via callout_drain.
Note that this fix applies to the "old" ata(4) and so isn't applicable
to the default configuration in HEAD. It is still applicable to
stable/8.
[1] http://lists.freebsd.org/pipermail/freebsd-current/2012-January/031122.html
Submitted by: Nima Misaghian
Reviewed by: rstone, attilio, mav
Obtained from: SVOS
MFC after: 3 days
There are unfortunately a number of situations where vap->iv_bss is changed
or freed by some code in net80211. Because multiple threads can concurrently
be doing work (and the vap->iv_bss access isn't at all done behind any kind
of lock), it's quite possible that:
* a change will occur in one thread - eg, by a call through
ieee80211_sta_join1();
* a state change occurs in another thread - eg an RX is scheduled
in the ath tasklet and it calls ieee80211_input_mimo_all(), which
does dereference vap->iv_bss;
* these two executing concurrently, causing things to explode.
Another instance is ath_beacon_alloc() which takes an ieee80211_node *.
It's called with the vap->iv_bss node from ath_newstate(). If the node has
changed in the meantime (say it's been freed elsewhere) the reference
that it grabbed _before_ refcounting it may be stale.
I would _prefer_ that these sorts of things were serialised somewhere but
that may be a bit much to ask. Instead, the best we can (currently) hope
is that the underlying bss node is still (somewhat) valid.
There is a related PR (kern/164382) described by the first case above.
That should be fixed by properly serialising the RX path and reset path
so an RX can't occur at the same time as the vap free/shutdown path.
This is inspired by some related fixes in r212127.
PR: kern/165060
for a shared mapping and marking the entry for inheritance.
Other thread might execute vmspace_fork() in between (e.g. by fork(2)),
resulting in the mapping becoming private.
Noted and reviewed by: alc
MFC after: 1 week
be the same chip):
- The I/O port resource may not be available with these. However, given
that we actually only need this resource for some controllers that
require their firmware to be up- and downloaded (which excludes the
SAS1078{,DE}) just handle failure to allocate this resource gracefully
when possible. While at it, generally put non-fatal resource allocation
failures under bootverbose.
- SAS1078{,DE} use a different hard reset protocol.
- Add workarounds for the 36GB physical address limitation of scatter/
gather elements of these controllers.
Tested by: Slawa Olhovchenkov
PR: 149220 (remaining part)
on extended and extensible structs if_msghdrl and ifa_msghdrl. This
will allow us to extend both the msghdrl structs and eventually if_data
in the future without breaking the ABI.
Bump __FreeBSD_version to allow ports to more easily detect the new API.
Reviewed by: glebius, brooks
MFC after: 3 days
both 64bit and 32bit binaries, not for 64bit only.
The set of the flag is not neccessary there, because the only current
user of the cpu_set_user_tls() is create_thread(), which calls
cpu_set_upcall() before and cpu_set_upcall() itself sets PCB_FULL_IRET.
Change the function for consistency and preserve existing KPI for now.
MFC after: 1 week
Code should just use the devtoname() function to obtain the name of a
character device. Also add const keywords to pieces of code that need it
to build properly.
MFC after: 2 weeks
overridden at attach time.
Some 802.11n NICs may only have one physical antenna connected.
The radios will be very upset if you try enabling radios which aren't
connected to antennas.
This allows hints to override the TX and RX chainmask.
These hints are:
hint.ath.X.rx_chainmask
hint.ath.X.tx_chainmask
They can be set at either boot time or in kenv before the module is loaded.
This and the previous HAL commit were sponsored in late 2011 by Hobnob, Inc.
Sponsored by: Hobnob, Inc.
by capabilities.
Add an ar5416SetCapability() function, which contains logic to override
the chainmask and update the relevant stream.
This is designed to be called after the attach function, which presets
the TX/RX chainmask and stream.
TODO: check the chainmask against the hardware chainmask so non-existing
chains aren't enabled.
