| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
| | |
| | |
| | |
| | |
| | | |
to illumos-gate 13921:9d721847e469
(illumos zfs issue #3035 LZ4 compression support in ZFS and GRUB)
|
| | |
| | |
| | |
| | | |
(illumos zfs issues #3397 #3398)
|
| | |
| | |
| | |
| | |
| | | |
to illumos-gate 13889:a67716f16746
(illumos zfs issue #3254)
|
| | |
| | |
| | |
| | |
| | | |
to illumos-gate 13887:196932ec9e6a
(illumos zfs issue #3236)
|
| | |
| | |
| | |
| | |
| | | |
to illumos-gate 13886:e3261d03efbf
(illumos zfs issue #3349)
|
| | |
| | |
| | |
| | |
| | | |
to illumos-gate 13871:a9c12c2c1647
(zfs changes, illumos issues #3306, #3321)
|
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
to illumos-gate 13869:921a99998bb4
(illumos ZFS issue #3246 ZFS I/O deadman thread)
Note: illumos disables deadman logic by default on vmware and sparc
|
| | |
| | |
| | |
| | |
| | | |
to illumos-gate 13849:3468a95b27cd
(illumos ZFS issues #3145, #3212, #3258)
|
| | |
| | |
| | |
| | |
| | | |
to illumos-gate 13836:37bf491c434c
(illumos ZFS issues #2678, #2811, #3139, #3189, #3208)
|
| | |
| | |
| | |
| | | |
(zfs, illumos issue #3064)
|
| | |
| | |
| | |
| | | |
(zfs changes, illumos issue #3098)
|
| | |
| | |
| | |
| | |
| | | |
to illumos-gate 13805:e3a9ae14a119
(zfs changes, illumos issues #1884, #3006)
|
| | |
| | |
| | |
| | | |
(dtrace changes only, illumos issue #3021)
|
| | |
| | |
| | |
| | |
| | |
| | | |
to illumos-gate revision 13794:7c5e0e746b2c
Obtained from: ssh://anonhg@hg.illumos.org/illumos-gate
|
| | |
| | |
| | |
| | | |
(dtrace changes, illumos issue #3123)
|
| | |
| | |
| | |
| | |
| | |
| | | |
to illumos-gate revision 13782:8f78aae28a63
Obtained from: ssh://anonhg@hg.illumos.org/illumos-gate
|
| | |
| | |
| | |
| | | |
Obtained from: ssh://anonhg@hg.illumos.org/illumos-gate
|
| | |
| | |
| | |
| | | |
Obtained from: ssh://anonhg@hg.illumos.org/illumos-gate
|
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
References:
https://www.illumos.org/issues/2399 (zfs manual page)
Obtained from: ssh://anonhg@hg.illumos.org/illumos-gate
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
References:
https://www.illumos.org/issues/3021
https://www.illumos.org/issues/3022
https://www.illumos.org/issues/3023
https://www.illumos.org/issues/3024
https://www.illumos.org/issues/3025
https://www.illumos.org/issues/3026
Obtained from: ssh://anonhg@hg.illumos.org/illumos-gate
|
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
References:
https://www.illumos.org/issues/2978
Obtained from: ssh://anonhg@hg.illumos.org/illumos-gate
|
| | |
| | |
| | |
| | | |
Obtained from: ssh://anonhg@hg.illumos.org/illumos-gate
|
| | |
| | |
| | |
| | |
| | |
| | | |
(non-zfs part)
Obtained from: ssh://anonhg@hg.illumos.org/illumos-gate
|
| | | |
|
| | | |
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
that could never be reached in vm_radix_insert(). (If the pointer being
checked by the panic call were ever NULL, the immmediately preceding loop
would have already crashed on a NULL pointer dereference.)
Reviewed by: attilio (an earlier version)
Sponsored by: EMC / Isilon Storage Division
|
| | | |
|
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
compile tested with clang on i386, amd64
compile tested with gcc on i386, amd64, sparc64
Submitted by: delphij
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Use destroy_dev_sched_cb() to not wait for device destruction while holding
GEOM topology lock (that actually caused deadlock). Use request counting
protected by mutex to properly wait for outstanding requests completion in
cases of device closing and geom destruction. Unlike r227009, this code
does not block taskqueue thread for indefinite time, waiting for completion.
|
| | |
| | |
| | |
| | | |
Obtained from: Qualcomm Atheros
|
| | |
| | |
| | |
| | | |
link pointer check.
|
| | |
| | |
| | |
| | |
| | |
| | | |
Tested:
* AR9580, STA mode
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
more topology change done that may require its attention. Add few missing
g_do_wither() calls in respective places to signal it.
This fixes potential infinite loop here when some provider is withered, but
still opened or connected for some reason and so can not be destroyed. For
example, see r227009 and r227510.
|
| | |
| | |
| | |
| | |
| | | |
Submitted by: db
Reviewed by: gjb
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
on signed integer overflow wrapping. Otherwise mktime(3) and timegm(3)
can hang, in case the timestamp passed in struct tm is not representable
in a time_t. Specifically, any timestamp after 2038-01-19 03:14:07, in
combination with a 32-bit time_t.
Note that it would be better to change the code to not rely on undefined
behaviour, but it is contributed code, and it is not entirely trivial to
fix the issue properly.
MFC after: 3 days
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
related issues.
Moving the TX locking under one lock made things easier to progress on
but it had one important side-effect - it increased the latency when
handling CABQ setup when sending beacons.
This commit introduces a bunch of new changes and a few unrelated changs
that are just easier to lump in here.
The aim is to have the CABQ locking separate from other locking.
The CABQ transmit path in the beacon process thus doesn't have to grab
the general TX lock, reducing lock contention/latency and making it
more likely that we'll make the beacon TX timing.
The second half of this commit is the CABQ related setup changes needed
for sane looking EDMA CABQ support. Right now the EDMA TX code naively
assumes that only one frame (MPDU or A-MPDU) is being pushed into each
FIFO slot. For the CABQ this isn't true - a whole list of frames is
being pushed in - and thus CABQ handling breaks very quickly.
The aim here is to setup the CABQ list and then push _that list_ to
the hardware for transmission. I can then extend the EDMA TX code
to stamp that list as being "one" FIFO entry (likely by tagging the
last buffer in that list as "FIFO END") so the EDMA TX completion code
correctly tracks things.
Major:
* Migrate the per-TXQ add/removal locking back to per-TXQ, rather than
a single lock.
* Leave the software queue side of things under the ATH_TX_LOCK lock,
(continuing) to serialise things as they are.
* Add a new function which is called whenever there's a beacon miss,
to print out some debugging. This is primarily designed to help
me figure out if the beacon miss events are due to a noisy environment,
issues with the PHY/MAC, or other.
* Move the CABQ setup/enable to occur _after_ all the VAPs have been
looked at. This means that for multiple VAPS in bursted mode, the
CABQ gets primed once all VAPs are checked, rather than being primed
on the first VAP and then having frames appended after this.
Minor:
* Add a (disabled) twiddle to let me enable/disable cabq traffic.
It's primarily there to let me easily debug what's going on with beacon
and CABQ setup/traffic; there's some DMA engine hangs which I'm finally
trying to trace down.
* Clear bf_next when flushing frames; it should quieten some warnings
that show up when a node goes away.
Tested:
* AR9280, STA/hostap, up to 4 vaps (staggered)
* AR5416, STA/hostap, up to 4 vaps (staggered)
TODO:
* (Lots) more AR9380 and later testing, as I may have missed something here.
* Leverage this to fix CABQ hanling for AR9380 and later chips.
* Force bursted beaconing on the chips that default to staggered beacons and
ensure the CABQ stuff is all sane (eg, the MORE bits that aren't being
correctly set when chaining descriptors.)
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
to stuck beacons.
* Set the cabq readytime (ie, how long to burst for) to 50% of the total
beacon interval time
* fix the cabq adjustment calculation based on how the beacon offset is
calculated (the SWBA/DBA time offset.)
This is all still a bit magic voodoo but it does seem to have further
quietened issues with missed/stuck beacons under my local testing.
In any case, it better matches what the reference HAL implements.
Obtained from: Qualcomm Atheros
|
| | | |
|
| | | |
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
held. The ttm_buffer_object_transfer() does not need the mutex locked
at all, except for the call to the driver sync_obj_ref() method.
Reported and tested by: dumbbell
MFC after: 2 weeks
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Limit write requests to at most INT_MAX.
This prevents a certain common programming error (passing -1 to write)
from leading to other problems deeper in the library.
References:
https://github.com/libarchive/libarchive/commit/22531545514043e0
Reported by: Xin Li <delphij@FreeBSD.org>
Obtained from: libarchive (master branch)
|
| | | |
|
| | | |
|
| | |
| | |
| | |
| | | |
Submitted by: Bjoern A. Zeeb <bz@FreeBSD.org>
|
| | |
| | |
| | |
| | | |
Build verified by: Glen Barber (gjb@)
|
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
This fixes memory leaks in the radeonkms driver.
Reviewed by: Konstantin Belousov (kib@)
Tested by: J.R. Oldroyd <jr@opal.com>
|
| | |
| | |
| | |
| | |
| | |
| | | |
used..
Submitted by: deeptech71 at gmail dot com
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
With some recent busdma refactoring, sometimes it happens that a sync
op gets called when bus_dmamap_load() never got called, which results
in a spurious warning about a map mismatch when no sync operations will
actually happen anyway. Now the check is done only if a sync operation
is actually performed, and the result of the check is a panic, not just
a printf.
Reviewed by: cognet (who prevented me from donning a point hat)
|
| | |
| | |
| | |
| | | |
Reviewed by: ken (mentor)
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
This particular scenario was easily reproduced using a NFS export. When the
first 'zfs unmount' occurred, it returned EBUSY via this path, while
vflush() had flushed references on the filesystem's root vnode, which in
turn caused its v_interlock to be destroyed. The next time 'zfs unmount'
was called, vflush() tried to obtain this lock, which caused this panic.
Since vflush() on FreeBSD is a definitive call, there is no need to check
vfsp->vfs_count after it completes. Simply #ifdef sun this check.
Submitted by: avg
Reviewed by: avg
Approved by: ken (mentor)
MFC after: 1 month
|