- 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.
ASMedia ASM1062 AHCI chips with some fancy firmware handling PMP inside
seems sometimes forgeting to set bits in PxIS, causing command timeouts.
Removal of this check fixes the issue by the theoretical cost of slightly
higher CPU usage in some odd cases, but this is what Linux does too.
MFC after: 1 month
This was being done in the pre-AR9380 case, but not for AR9380 and later.
When powersave in STA mode is enabled, this may have lead to the transmit
completion code doing this:
* call the task, which doesn't wake up the hardware
* complete the frames, which doesn't touch the hardware
* schedule pending frames on the hardware queue, which DOES touch the
hardware, and this will be ignored
This would show up in the logs like this:
(with debugging enabled):
Nov 27 23:03:56 lovelace kernel: Q1[ 0] (nseg=1) (DS.V:0xfffffe011bd57300 DS.P:0x49b57300) I: 168cc117 L:00000000 F:0005
...
(in general, doesn't require debugging enabled):
Nov 27 23:03:56 lovelace kernel: ath_hal_reg_write: reg=0x00000804, val=0x49b57300, pm=2
That register is a EDMA TX FIFO register (queue 1), and the val is the descriptor
being written.
Whilst here, make sure the software queue gets kicked here.
Tested;
* AR9485, STA mode + powersave
Since hypervisor does not respond CHOPEN to a revoked channel.
MFC after: 1 week
Sponsored by: Microsoft
Differential Revision: https://reviews.freebsd.org/D8636
Just in case that no chimney sending buffer can be used.
MFC after: 1 week
Sponsored by: Microsoft
Differential Revision: https://reviews.freebsd.org/D8619
