Table to find if the hardware supports PSCI, and if so what method the
kernel should use to interact with it.
Obtained from: ABT Systems Ltd
Sponsored by: The FreeBSD Foundation
This makes booting on Hyper-V w/ small # of vCPUs work properly.
Reported by: Hongxiong Xian <v-hoxian microsoft com>, Hongjiang Zhang <honzhan microsoft com>
MFC after: 1 week
Sponsored by: Microsoft
If the bus number assigned to a Host-PCI bridge doesn't match the first
bus number in the associated producer range from _CRS, print a warning and
fail to attach rather than panicking due to an assertion failure.
At least one single-socket Dell machine leaves a "ghost" Host-PCI bridge
device in the ACPI namespace that seems to correspond to the I/O hub in
the second socket of a two-socket machine. However, the BIOS doesn't
configure the settings for this "ghost" bridge correctly, nor does it have
any PCI devices behind it.
Tested by: royger
MFC after: 2 weeks
This change includes firmware commands for key setup +
some additional checking via CAMREAD / CAMWRITE registers.
Nothing (except rsu_delete_key() for pairwise keys) is deferred;
to ensure that things are done in order rsu_set_key() will wait
until key deletion task will be finished.
Tested with Asus USB-N10 (all ciphers).
Differences from initial (reviewed) patch:
- Pause AC queues before disassociation - since CMD_DISCONNECT clears
crypto state all pending frames must be processed / dropped before it.
- Check sc_running flag before trying to set static keys.
- Clear key index from bitmap even when firmware command fails
(it will be invalidated via CAMWRITE anyway).
Reviewed by: adrian, kevlo
Tested by: kevlo
Differential Revision: https://reviews.freebsd.org/D8706
- Append RCR_APP_PHYSTS bit after firmware loading - otherwise
firmware will reset the register and this modification will be lost.
(without it Rx PHY descriptor section will contain garbage).
- Check if R92S_RXDW0_PHYST bit is set (like it is done in rtwn(4)) -
even if infosz is non-zero the section may not contain anything useful.
- In case, if descriptor is absent (A-MPDU?) use last calibrated RSSI
(rtwn(4) uses RSSI from the previous (sub)frame; probably, this
approach should be used here too).
Tested with Asus USB-N10, STA mode.
- Fill in Rx radiotap header correctly (for every packet in a chain;
not once per chain).
- Fix rate / flags fields in Rx radiotap.
- Add debug messages for discarded frames.
- Pass received control (< sizeof(struct ieee80211_frame)) frames
to net80211 (if allowed by device filter; cannot happen yet).
Tested with Asus USB-N10.
Differential Revision: https://reviews.freebsd.org/D5723
This is important in hostap, ibss, (11s at some magical future date, etc)
where different nodes may have smaller limits.
Oops!
MFC after: 1 week
Relnotes: Yes
it.
Remove bogus wrappers and use the kernel defaults.
While here, use DEVMETHOD_END.
Obtained from: pfSense
MFC after: 2 weeks
Sponsored by: Rubicon Communications, LLC (Netgate)
When handling a GPE ACPI interrupt object the EcSpaceHandler()
function can be called which checks the EC_EVENT_SCI bit and then
recurse on the EcGpeQueryHandler() function. If there are multiple GPE
events pending the EC_EVENT_SCI bit will be set at the next call to
EcSpaceHandler() causing it to recurse again via the
EcGpeQueryHandler() function. This leads to a slow never ending
recursion during boot which prevents proper system startup, because
the EC_EVENT_SCI bit never gets cleared in this scenario.
The behaviour is reproducible with the ALASKA AMI in combination with
a newer Skylake based mainboard in the following way:
Enter BIOS and adjust the clock one hour forward. Save and exit the
BIOS. System fails to boot due to the above mentioned bug in
EcGpeQueryHandler() which was observed recursing multiple times.
This patch adds a simple recursion guard to the EcGpeQueryHandler()
function and also also adds logic to detect if new GPE events occurred
during the execution of EcGpeQueryHandler() and then loop on this
function instead of recursing.
Reviewed by: jhb
MFC after: 2 weeks
If bufring is used for per-TX ring descs, don't update "available"
counter, which is only used to help debugging.
MFC after: 1 week
Sponsored by: Microsoft
Differential Revision: https://reviews.freebsd.org/D8674
Fix ioat_release to only set is_completion_pending if DMAs were actually
queued. Otherwise, the spurious flag could trigger an assert in the
reset path on INVARIANTS kernels.
Reviewed by: bdrewery, Suraj Raju @ Isilon
Sponsored by: Dell EMC Isilon
It was an experimental tunable, and is now deemed to be road blocker
for further changes. Time to retire it.
MFC after: 1 week
Sponsored by: Microsoft
Differential Revision: https://reviews.freebsd.org/D8654
Attempt to fix powerpc64 LINT kernel broken by r308000. Netmap's use of
a uint64_t wchan seems odd, but in the interest of minimizing this
change just cast through uintptr_t to silence the compiler warning.
Reviewed by: jhb
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D8669
passing it to firmware for all Gen3 controllers.
For Thunderbolt controller, keep the legacy behavior i.e. return the SYNCHRONIZE_CACHE command with success status from driver itself.
There is Sysctl parameter 'block_sync_cache' is provided to enable customers either to block/unblock these commands to facilitate
legacy behavior if there is a compatibility issue. Default value for module parameter is to unblock this command.
Submitted by: Sumit Saxena <sumit.saxena@broadcom.com>
Reviewed by: Kashyap Desai <Kashyap.Desai@broadcom.com>
MFC after: 3 days
Sponsored by: Broadcom Limited/AVAGO Technologies
and return without processing event in AEN thread, if controller reset is in progress.
Submitted by: Sumit Saxena <sumit.saxena@broadcom.com>
Reviewed by: Kashyap Desai <Kashyap.Desai@broadcom.com>
MFC after: 3 days
Sponsored by: Broadcom Limited/AVAGO Technologies
If a SCSI IO times out, then before initiating OCR, now the driver will try to send a
target reset to the particular target for which the IO is timed out. If that also fails,
then the driver will initiate OCR.
Submitted by: Sumit Saxena <sumit.saxena@broadcom.com>
Reviewed by: Kashyap Desai <Kashyap.Desai@broadcom.com>
MFC after: 3 days
Sponsored by: Broadcom Limited/AVAGO Technologies
Did the same by setting sc->aen_cmd = NULL when aborting AEN is successful.
Submitted by: Sumit Saxena <sumit.saxena@broadcom.com>
Reviewed by: Kashyap Desai <Kashyap.Desai@broadcom.com>
MFC after: 3 days
Sponsored by: Broadcom Limited/AVAGO Technologies
MFI linked list in megaraid_sas driver is used for mfi-mpt pass-through commands.
This list can be corrupted due to many possible race conditions in driver and
eventually we may see kernel panic.
One example -
MFI frame is freed from calling process as driver send command via polling method and interrupt
for that command comes after driver free mfi frame (actually even after some other context reuse
the mfi frame). When driver receive MPT frame in ISR, driver will be using the index of MFI and
access that MFI frame and finally in-used MFI frames list will be corrupted.
High level description of new solution -
Free MFI and MPT command from same context.
Free both the command either from process (from where mfi-mpt pass-through was called) or from
ISR context. Do not split freeing of MFI and MPT, because it creates the race condition which
will do MFI/MPT list.
Submitted by: Sumit Saxena <sumit.saxena@broadcom.com>
Reviewed by: Kashyap Desai <Kashyap.Desai@broadcom.com>
MFC after: 3 days
Sponsored by: Broadcom Limited/AVAGO Technologies
Clear the interrupt state before reading the input char from the
input FIFO. In the current code there is a window between the read
to the data register and the write to the the ICR, during which an
input char will not cause an interrupt.
This fixes the issue by which the serial port input on QEMU freezes
when using the emulated pl011 serial port.
This adds a workaround to incorrectly behaving APs (ie, FreeBSD APs) which
don't beacon out exactly when they should (at TBTT multiples of beacon
intervals.)
It forces the hardware awake (but leaves it in network-sleep so self
generated frames still state that the hardware is asleep!) and will
remain awake until the next sleep transition driven by net80211.
That way if the beacons are just at the wrong interval, we get a much
better chance of hearing more consecutive beacons before we go to sleep,
thus not constantly disconnecting.
Tested:
* AR9485, STA mode, against a misbehaving FreeBSD AP.
The 802.11-2012 spec talks about this - section 10.1.3.2 - Beacon Generation
in Infrastructure Networks. So yes, we should be expecting beacons to be
going out in multiples of intval.
Silly adrian.
So:
* fix the FreeBSD APs that are sending beacons at incorrect TBTTs (target
beacon transmit time); and
* yes indeed we will have to wake up out of network sleep until we sync
a beacon.
