- In case the parent is bge(4), don't set the Jumbo frame settings unless
the MAC actually is Jumbo capable as otherwise the PHY might not have the
corresponding registers implemented. This is also in line with what the
Linux tg3 driver does.
PR: 165032
Submitted by: Alexander Milanov
Obtained from: OpenBSD
MFC after: 3 days
hold the lock.
This is part of my series of work to try and capture when net80211
locking isn't.
ObNote: it'd be nice to be able to mark a lock as "assert if the lock
is dropped", so I could capture functions which decide that dropping
and reacquiring the lock is a good idea (without re-checking the
sanity of the state protected by the lock.)
devices that are unplugged via QEMU.
sys/dev/xen/blkback/blkback.c:
Toolstack initiated closures change the frontend's state
to Closing. The backend must change to Closing as well,
even if we can't actually close yet, in order for the
frontend to notice and start the closing process.
MFC after: 3 days
- remove the KEVENT code, which was incomplete and not compiled anyways;
- change some while() loops into for()
- adjust indentation
- remove extra whitespace
MFC after: 1 week
struct ccb_pathinq from sys/cam/cam_ccb.h wasn't added to stable/7 at all
and didn't appear in stable/8 until svn R195534. Since __FreeBSD_version
did not get bumped until svn R195634, assume that maxio is valid at 800102
or higher.
Obtained from: Yahoo! Inc.
MFC after: 0 days
with RX/TX halting.
* Always disable/enable interrupts during a channel change, just to simply
things.
* Ensure that the ath taskqueue has completed and is paused before
continuing.
This dramatically reduces the instances of overlapping RX and reset
conditions.
PR: kern/165220
The previous code did not limit the I/O request size based on
the maximum number of segments supported by the back-end. In
current practice, since the only back-end supporting chained
requests is the FreeBSD implementation, this limit was never
exceeded.
sys/dev/xen/blkfront/block.h:
Add two macros, XBF_SEGS_TO_SIZE() and XBF_SIZE_TO_SEGS(),
to centralize the logic of reserving a segment to deal with
non-page-aligned I/Os.
sys/dev/xen/blkfront/blkfront.c:
o When negotiating transfer parameters, limit the
max_request_size we use and publish, if it is greater
than the maximum, unaligned, I/O we can support with
the number of segments advertised by the backend.
o Don't unilaterally reduce the I/O size published to
the disk layer by a single page. max_request_size
is already properly limited in the transfer parameter
negotiation code.
o Fix typos in printf strings:
"max_requests_segments" -> "max_request_segments"
"specificed" -> "specified"
MFC after: 1 day
Introduce some functions to map NIC ring indexes into netmap ring
indexes and vice versa. This way we can implement the bound
checks only in one place (and hopefully in a correct way).
On passing, make the code and comments more uniform across the
various drivers.
FreeBSD's front and back Xen blkif interface drivers.
sys/dev/xen/blkfront/block.h:
sys/dev/xen/blkfront/blkfront.c:
sys/dev/xen/blkback/blkback.c:
Replace FreeBSD specific multi-page ring impelementation with
support for both the Citrix and Amazon/RedHat versions of this
extension.
sys/dev/xen/blkfront/blkfront.c:
o Add a per-instance sysctl tree that exposes all negotiated
transport parameters (ring pages, max number of requests,
max request size, max number of segments).
o In blkfront_vdevice_to_unit() add a missing return statement
so that we properly identify the unit number for high numbered
xvd devices.
sys/dev/xen/blkback/blkback.c:
o Add static dtrace probes for several events in this driver.
o Defer connection shutdown processing until the front-end
enters the closed state. This avoids prematurely tearing
down the connection when buggy front-ends transition to the
closing state, even though the device is open and they
veto the close request from the tool stack.
o Add nodes for maximum request size and the number of active
ring pages to the exising, per-instance, sysctl tree.
o Miscelaneous style cleanup.
sys/xen/interface/io/blkif.h:
o Add extensive documentation of the XenStore nodes used to
implement the blkif interface.
o Document the startup sequence between a front and back driver.
o Add structures and documenatation for the "discard" feature
(AKA Trim).
o Cleanup some definitions related to FreeBSD's request
number/size/segment-limit extension.
sys/dev/xen/blkfront/blkfront.c:
sys/dev/xen/blkback/blkback.c:
sys/xen/xenbus/xenbusvar.h:
Add the convenience function xenbus_get_otherend_state() and
use it to simplify some logic in both block-front and block-back.
MFC after: 1 day
This allows LUNs greater than 0 to be probed. It can be increased later if
need be.
This brings back SVN rev 224973, which was inadvertently removed with the
import of the LSI driver.
Reported by: dwhite
MFC after: 3 days
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.
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.
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
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)
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.
If an IPv6 packet has extension headers the kernel needs to deal with it
itself. For the rest it can set various CSUM_XXX flags and the driver
will act on them.
with clang. Also fix a number of warnings uncovered when building with
clang around some implicit enum conversions.
Sponsored by: Intel
Approved by: scottl
