| Age | Commit message (Collapse) | Author |
|---|
|
Tested:
ax200: jmc, phessler, kevlo, hrvoje, sdk, fkr, stsp, Mark Patruck
ax201: jcs, stsp, Fredrik Engberg, Eric Auge
|
|
ic_bss->ni_bssid has already been overwritten once we enter
iwx_newstate_task() to perform the state transitions necessary
for roaming to our new access point (RUN->AUTH->ASSOC->RUN).
We do however use the BSSID in commands sent to firmware.
Cache our BSSID in struct iwx_node such that firmware commands
keep using the old BSSID while we are still tearing things down.
Switch to the new BSSID only once we start back up in iwx_auth().
This should be consistent from the firmware's point of view.
Same fix as committed for iwm(4) recently.
|
|
This is similar to a recent fix committed to iwm(4).
Unlike iwm(4) we do not need to disable Tx aggregation queues in iwx(4).
Attempting to do so would cause fatal firmware errors.
Tested by jmc@ and myself.
|
|
Tested with cc-a0-63 and QuZ-a0-hr-b0-63 firmware by myself.
Tested with Qu-c0-hr-b0-63 firmware by Fredrik Engberg.
|
|
AUTH->AUTH state transitions happen if the access point uses band-steering.
This was originally implemented to fix interop with some Aruba APs, and
was probably broken by my recent CVS commit XeKkqPoaUCklmgtC ("prevent
attempts to transition towards the same state").
ok mpi@
|
|
work that is already handled by state transitions involving AUTH or RUN.
|
|
Uncomfortable bug found the hard way by deraadt@
|
|
in cases where this would result in a redundant or illegal state transition.
jmc@ observed ASSOC -> ASSOC transitions which would result in a hang.
Such transitions are invalid and never intentionally triggered by net80211.
They imply a race between the Rx interrupt handler and the newstate task.
Tested by jmc@ on AX200 for a week and several known issues seem to be fixed.
|
|
When multiple frames are sent in a batch on a Tx aggregation queue our
current firmware version does not provide the IWX_TX_CMD notification.
Older versions used to provide this (as observed on iwm(4) devices),
but our current firmware only sends IWX_BA_NOTIF.
This means we need to reset the Tx timer upon BA_NOTIF in order to
avoid a bogus "device timeout" trigger from our watchdog handler.
Do this as soon as the BA notification has been validated.
|
|
Throughput goes up to 100 Mbit/s under ideal conditions.
This is mostly working and stable, however rare occasional hangs may occur
where the device stops giving us interrupts for reasons which are not yet
understood.
In such cases ifconfig down/up will recover the interface. Regardless, this
code seems to be stable enough for remaining issues to be resolved in-tree.
My working assumption is that the remaining issues were always present but
only trigger under increased load when firmware is driven with Tx agg enabled.
Feedback is welcome, especially if stability issues turn out to be worse than
expected! As usual, please enable "ifconfig iwx0 debug" when reporting issues.
Tests on ax200/ax201:
myself, dv, hrvoje, Stefan Hagen, kevlo, Eric Auge, mlarkin, jmc, Mark Patruck
Of which only me and jmc have reported seeing a small amount of hangs during
continuous usage over about 2 weeks.
|
|
This will hopefully prevent the device from ever writing to the former
DMA address of a buffer which has been taken off the Tx ring.
As far as I understand, the Linux driver unmaps (parts of) Tx descriptors
that are done. We use a static DMA mapping for the entire descriptor array,
so unmapping is not an option for us.
Tested by several as part of my Tx aggregation support patch.
|
|
Clear the byte-count for the correct frame while taking frames off the ring.
This should fix some 'fatal firmware errors' seen under load, and prevent
memory corruption: The device could access an mbuf we have freed, but which
is still marked as used in the byte count table and which still has a DMA
address in its Tx descriptor. Problem observed by mlarkin with NFS while
testing my patch for Tx aggregation support.
|
|
Suggested by deraadt@ during discussion at k2k21.
With additional input from mlarkin. And deraadt spotted some pointless
splnet() calls which this patch is removing.
Resume from S3 tested by me on an x250 thinkpad with a compatible
ax200 wifi card provided by mlarkin. Hibernate tested by deraadt.
Sync comments about the PCI retry timeout workaround with Linux while here.
ok mlarkin@
|
|
of iwx_ctxt_info_init() which should always free on error.
Also, free firmware paging DMA memory in case loading firmware has failed.
If we don't free paging on error we hit KASSERT(dram->paging == NULL)
in iwx_init_fw_sec() once we try to load firmware again. I have hit
this while debugging firmware load failures during suspend/resume.
ok mpi@
|
|
ok mpi@
|
|
Sleeping for 1 second matches what iwn(4) does. Fixes issues where loading
firmware failed for bogus reasons. I could trigger this failure on AX200
with suspend/resume but it was not inherently specific to suspend/resume.
The previous code was looping over tsleep(9) in steps of 100msec.
This could lead to a race where the firmware's alive interrupt fired between
the endtsleep() timeout handler, which marks the sleep timeout as expired,
and sleep_finish(), which reschedules the sleeping thread. The driver would
see EWOULDBLOCK and report an error even though loading firmware did succeed.
ok mpi@
|
|
In particular, this makes suspend/resume work on systems using msix.
Resume is not 100% reliable yet, though, failing about 1 in 20 times
to bring the interface back up.
Recovery with ifconfig down/up should be possible when things go wrong.
With help from gnezdo@ in diagnosing the issue and testing changes.
Tests:
8265: stsp
9260: florian
9560: kevlo, Uwe Werler
ax200: kevlo, Mark Patruck, beck
ax201: gnezdo
|
|
and will not do so during resume.
Tested by kevlo@ on iwx(4) and by myself on iwm(4).
|
|
with a fix from + ok kevlo@
|
|
family (discrete) not integrated.
ok stsp@
|
|
Found by mpi@ and gnezdo@
ok gnezdo@
|
|
This might help with troubleshooting "iwx0: acquiring device failed"
errors.
OK stsp@
|
|
to get ownership.
See Linux commit 501fd9895c1d7d8161ed56698ae2fccb10ef14f5
ok stsp@
|
|
Patch by zxystd from OpenIntelWireless.
|
|
interrupts. Move it to the right place.
|
|
work right during the resume path. To be revisited later.
|
|
deraadt@ pointed out that the resume code path only ran a small part
of the entire hardware init sequence which runs when the device is
first attached at boot time.
In particular, we didn't wait for device stabilization, and MSI-X
initialization was attempted too early, and the "persistence bit"
workaround was skipped (which, ironically, is supposed to address
a known hardware bug during resume).
Tested by jcs on AX201 and by myself on 8265 with no regressions seen.
|
|
These drivers will now report "fatal firmware error" on a single line
by default and provide the full trace when debugging has been enabled
with e.g. 'ifconfig iwm0 debug'.
ok sthen@ kevlo@
|
|
No need to access iwx_read_prph and could get the rid of the obsolete comment.
See Linux commit 4adfaf9b2de3a04a9ee9adff6e000e8dbb37bed5
ok stsp@
|
|
CID 1506261
|
|
This driver does not need to allocate a DMA segment for the Tx scheduler.
Instead this driver uses the scheduler byte count array which is allocated
per Tx ring. Remove sc->sched_dma and related code inherited from iwm(4).
Patch by zxystd from OpenIntelWireless.
|
|
Starting with major version 35 the Linux driver prints the minor version
number in hexadecimal.
Same change was made for iwm(4) in CVS commit LCM6R5u9jeF8bcXB
|
|
This allocation was left over from code inherited from iwm(4) where
it is used for transferring firmware code to the device. Devices
supported by iwx(4) use an entirely different mechanism for loading
firmware and don't need this allocation at all.
Based on a patch by zxystd from the OpenIntelWireless project.
|
|
These images contain fixes which address fragattacks vulnerabilities:
https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00473.html
Running fw_update(1) may be required before rebooting into a new kernel.
sysupgrade(8) will take care of this.
When reporting issues, please enable 'ifconfig iwx0 debug', reproduce the
error once more, and include the full dmesg in your bug report.
Tested:
ax200: stsp, kevlo, hrvoje, jmc, Mark Patruck, Ashton Fagg
ax201: kettenis, Fredrik Engberg, Eric Auge
ok kevlo@
|
|
New firmware will generate this notification when a block ack request is
received. Older firmware passed the block ack request frame to the driver.
ok kevlo@
|
|
ADD_STA command version >= 12 implies that firmware uses an internal AUX
station for scanning. We do not configure an AUX Tx queue in this case
and data queue indices assigned by firmware shift upwards accordingly.
ok kevlo@
|
|
This command was expanded by a 4 byte max_tx_op field. As far as I can tell
the Linux driver makes no use of this field, so just initialize it to zero.
New firmware panics when we try to initialize Tx rate scaling otherwise.
ok kevlo@
|
|
Required for having associations succeed with new firmware.
ok kevlo@
|
|
ok kevlo@
|
|
ok kevlo@
|
|
ok kevlo@
|
|
ADD_STA command version >= 12 implies that firmware uses an internal
AUX station for scanning, and firmware panics if we try to add one.
ok kevlo@
|
|
This is related to the previous commit which fixed "BAD COMMAND" firmware
errors. We can no longer use old-style "narrow" commands on the command
queue with new firmware, and our current -48 firmware images don't seem
to care either way. We can simplify this code and align it with iwlwifi.
ok kevlo@
|
|
Firmware API versions >= 50 reject old-style commands in group 0 with a
"BAD_COMMAND" firmware error. We must pretend that such commands were in
the LONG_GROUP instead in order for firmware to accept them.
ok kevlo@
|
|
ok kevlo@
|
|
firmware images. For now, we can simply ignore them while loading firmware.
ok kevlo@
|
|
ok kevlo@
|
|
and microcode sections. Required for loading new firmware images.
ok kevlo@
|
|
Stop decrementing ring->queued inside the if-statement which guards
maintenance of the OACTIVE flag. This is wrong and resulted in a negative
counter value (visible in firmware error traces). The counter is already
decremented in the loop above where frames are taken off the ring.
|
|
Generally, iwx_init() must either succeed or reset everything. In the case
I observed, the missing call to iwx_stop() left us with a non-zero refcount
for the newstate task which failed to perform the INIT -> SCAN transition.
The next ioctl request from userspace would then trigger a KASSERT in
iwx_init() which checks for old tasks that haven't run to completion.
This problem won't happen under normal conditions. It will happen if
the firmware crashes in response to a bad scan command, for instance.
I ran into this while working on support for newer iwx(4) firmware.
|
