of PCI-EBus-bridges actually match the BARs as specified in and
required by [1, p. 113 f.]. Doing so earlier would have simplified
diagnosing a bug in QEMU/OpenBIOS getting the mapping of child
addresses wrong, which still needs to be fixed there.
In theory, we could try to change the BARs accordingly if we hit
this problem. However, at least with real machines changing the
decoding likely won't work, especially if the PCI-EBus-bridge is
beneath an APB one. So implementing such functionality generally
is rather pointless.
- Actually change the allocation type of EBus resources if they
change from SYS_RES_MEMORY to SYS_RES_IOPORT when mapping them
to PCI ranges in ebus_alloc_resource() and passing them up to
bus_activate_resource(9). This may happen with the QEMU/OpenBIOS
PCI-EBus-bridge but not real ones. Still, this is only cleans up
the code and the result of resource allocation and activation is
unchanged.
- Change the remainder of printf(9) to device_printf(9) calls and
canonicalize their wording.
MFC after: 1 week
Peripheral Component Interconnect Input Output Controller,
Part No.: 802-7837-01, Sun Microelectronics, March 1997 [1]
The firmware in this NIC sends management frames. So far I'm not sure which
ones it handles and which ones it doesn't handle - but this is what openbsd
does.
The association messages are handled by the firmware; the key negotiation
for 802.1x and WPA are done as raw frames, not management frames.
This successfully allows it to associate to my home networks whereas it didn't
work beforehand.
Tested:
* RTL8712, cut 3, STA mode
TODO:
* The firmware does send a join response with a status code; that should be
logged in a more obvious way to assist with debugging. Ie, the firmware
is the thing that is saying "couldn't join, sorry!", not net80211.
to attach with the last version of this commit. This commit fixes
attach failures on "ICH8" class devices via modifications to
e1000_init_nvm_params_ich8lan()
- Fix compiler warning in 80003es2lan.c
- Add return value handler for e1000_*_kmrn_reg_80003es2lan
- Fix usage of DEBUGOUT
- Remove unnecessary variable initializations.
- Removed unused variables (complaints from gcc).
- Edit defines in 82571.h.
- Add workaround for igb hw errata.
- Shared code changes for Skylake/I219 support.
- Remove unused OBFF and LTR functions.
Tested by some of the folks that reported breakage in previous incarnation.
Thanks to AllanJude, gjb, gnn, tijl for tempting fate with their machines.
Submitted by: erj@freebsd.org
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D3162
to provide the TCPDEBUG functionality with pure DTrace.
Reviewed by: rwatson
MFC after: 2 weeks
Sponsored by: Limelight Networks
Differential Revision: D3530
updated
ZFS already supports storing the vdev FRU in a vdev property. There
is code in libzfs to work with this property, and there is code in
the zfs-retire FMA module that looks for that information. But there
is no code actually setting or updating the FRU.
To address this, ZFS is changed to send a handful of new events
whenever a vdev is added, attached, cleared, or onlined, as well
as when a pool is created or imported.
Note that syseventd is not currently available on FreeBSD and thus
some work is needed to actually support the new ZFS events (e.g. in
zfsd) to actually use this capability, this changeset is mostly a
diff reduction from upstream.
illumos/illumos-gate@1437283407
Illumos issues:
5997 FRU field not set during pool creation and never updated
https://www.illumos.org/issues/5997
* yes, when a "sta disconnect" message comes through we should, like,
disconnect things. We're not currently generating beacon miss messages,
and net80211 isn't disconnecting things via software beacon miss receive.
Tested:
* RTL8712, cut 3, STA mode
Formally pair store_rel(&smp_started) with load_acq(&smp_started).
Similarly to x86, this change is mostly a NOP due to the kernel
being run in total store order.
MFC after: 1 week
* use an ath/iwn style debug bitmap - it's still global rather than per-device,
but it's better than debug levels
* disable bgscan - it just makes things unstable/unpredictable for now.
Tested:
* if_rsu - RTL8712 cut 3, STA mode
drivers into the revived sys/sparc64/pci/ofw_pci.c, previously already
serving a similar purpose. This has been done with sun4v in mind, which
explains a) the otherwise not that obvious scheme employed and b) why
reusing sys/powerpc/ofw/ofw_pci.c was even lesser an option.
- Add a workaround for QEMU once again not emulating real machines, in
this case by not providing the OFW_PCI_CS_MEM64 range. [1]
Submitted by: jhb [1]
MFC after: 1 week
In r286570 (MFV of r277426) an unprotected write to b_flags to
set the compression mode was introduced. This would open a race
window where data is partially decompressed, modified, checksummed
and written to the pool, resulting in pool corruption due to the
partial decompression.
Prevent this by reintroducing b_compress
illumos/illumos-gate@d4cd038c92
Illumos issues:
6214 zpools going south
https://www.illumos.org/issues/6214
Rewrite the ZFS prefetch code to detect only forward, sequential
streams.
The following kstats have been added:
kstat.zfs.misc.arcstats.sync_wait_for_async
How many sync reads have waited for async read
to complete. (less is better)
kstat.zfs.misc.arcstats.demand_hit_predictive_prefetch
How many demand read didn't have to wait for I/O
because of predictive prefetch. (more is better)
zfetch kstats have been similified to hits, misses, and max_streams,
with max_streams representing times when we were not able to create
new stream because we already have the maximum number of sequences
for a file.
The sysctl variable/loader tunable vfs.zfs.zfetch.block_cap have been
replaced by vfs.zfs.zfetch.max_distance, which controls maximum bytes
to prefetch per stream.
illumos/illumos-gate@cf6106c8a0
Illumos ZFS issues:
5987 zfs prefetch code needs work
https://www.illumos.org/issues/5987
The pci bus driver handles the power state, it also manages
configuration state saving and restoring for its child devices. Thus a
PCI device driver does not have to worry about those things. In fact, I
observe a hard system hang when trying to suspend a system with active
radeonkms driver where both the bus driver and radeonkms driver try to
do the same thing. I suspect that it could be because of an access to a
PCI configuration register after the device is placed into D3 state.
Reviewed by: dumbbell, jhb
MFC after: 13 days
Differential Revision: https://reviews.freebsd.org/D3561
All requests arriving for processing after OFFLINE flag set are rejected
with BUSY status. Races around OFFLINE flag setting are closed by calling
taskqueue_drain_all().
in the routine, which queues an ERROR chunk, instead on relyinh
on the callers to do so. Since one caller missed this, this actially
fixes a bug.
MFC after: 1 week
