| created | 2021-07-25T04:09:10Z |
|---|---|
| begin | 2021-07-18T00:00:00Z |
| end | 2021-07-19T00:00:00Z |
| path | src/sys |
| commits | 11 |
| date | 2021-07-18T05:02:08Z | |||
|---|---|---|---|---|
| author | jsg | |||
| files | src/sys/dev/pci/pcidevs | log | diff | annotate |
| message | add devices from ASUS ROG Strix G513QY and Alienware Aurora R10 | |||
| date | 2021-07-18T05:02:37Z | |||
|---|---|---|---|---|
| author | jsg | |||
| files | src/sys/dev/pci/pcidevs.h | log | diff | annotate |
| src/sys/dev/pci/pcidevs_data.h | log | diff | annotate | |
| message | regen | |||
| date | 2021-07-18T10:20:06Z | |||
|---|---|---|---|---|
| author | jsg | |||
| files | src/sys/dev/pci/drm/i915/gem/i915_gem_context.c | log | diff | annotate |
| message |
make the printf on skipping reset with gen7/gen8 debug only With the 5.10 drm on vlv/ivb/hsw/bdw inteldrm has been known to reset the chip when a gpu hang is falsely detected. This appears to be related to the workarounds for cleaning up after switching hardware contexts. intel_gt_reset *NOTICE* [drm] Resetting chip for context closure in glsl-uniform-int<99177> mark_guilty *NOTICE* [drm] glsl-uniform-int[97885] context reset due to GPU hang A local change skips the reset (which kills Xorg) on gen7/gen8. The printf is in that path. |
|||
| date | 2021-07-18T11:40:31Z | |||
|---|---|---|---|---|
| author | stsp | |||
| files | src/sys/dev/pci/if_iwx.c | log | diff | annotate |
| message |
Fix iwx(4) PHY context updates for newer firmware versions. Firmware which advertises the BINDING_CDB_SUPPORT capability needs a remove+add dance when the channel band has changed. See Linux commit 730a18912bcbde0b94ae7f1b554a9908b3424a22 and Linux commit 91109f42d0ad0c0c282d1fa1257a1548977aa895 The same fix was applied to iwm(4) in CVS commit uQ0WjqRUp03vxHg1 |
|||
| date | 2021-07-18T11:56:11Z | |||
|---|---|---|---|---|
| author | stsp | |||
| files | src/sys/dev/pci/if_iwx.c | log | diff | annotate |
| message |
Fix wrong usage of iwx_lookup_cmd_ver() in iwx_send_soc_conf(). Callers are supposed to check whether iwx_lookup_cmd_ver() returns CMD_VER_UNKNOWN, and this check was missing here. Fortunately, the buggy check was part of a condition which also requires the low_latency_xtal constant to be set. We do not yet support devices where low_latency_xtal is non-zero, so the bug never triggered. |
|||
| date | 2021-07-18T12:03:57Z | |||
|---|---|---|---|---|
| author | stsp | |||
| files | src/sys/dev/pci/if_iwx.c | log | diff | annotate |
| message |
Newer iwx(4) firmware doesn't like the DQA command anymore. Check whether firmware advertises DQA support before sending the DQA command during device initialization. Newer firmware will raise a fatal error otherwise. The Tx queue API has been redesigned yet again. |
|||
| date | 2021-07-18T12:21:49Z | |||
|---|---|---|---|---|
| author | stsp | |||
| files | src/sys/dev/pci/if_iwx.c | log | diff | annotate |
| message |
Set MIMO-related flags in the iwx(4) ADD_STA command. Not sure how we ended up missing these. MIMO apparently works without the flags set, and setting them doesn't seem to have any immediately visible effect on firmware. But let's be consistent with iwm(4) and iwlwifi. |
|||
| date | 2021-07-18T12:39:16Z | |||
|---|---|---|---|---|
| author | stsp | |||
| files | src/sys/dev/pci/if_iwx.c | log | diff | annotate |
| message |
Clear the "persistence bit" on iwx(4) devices during hardware init. According to iwlwifi commit messages this fixes an edge case where devices fail to resume after system suspend. See Linux commit 8954e1eb2270fa2effffd031b4839253952c76f2 Same fix was made for iwm(4) in CVS commit x0XTNdEmudy5oBR4 |
|||
| date | 2021-07-18T13:07:13Z | |||
|---|---|---|---|---|
| author | stsp | |||
| files | src/sys/dev/pci/if_iwx.c | log | diff | annotate |
| message |
Do not ask iwx(4) firmware to send probe requests on passive channels. This seems to fix a problem where firmware becomes unresponsive after association and eventually raises a fatal error. iwx(4) already has a workaround in place for this: We always ask firmware to perform a passive scan, on any channel. This change is a better fix from iwm(4) CVS commit jJFMeXcos9GOqFQz. However, the current workaround will stay in place for now, until we have evidence that active scanning is working on iwx(4) devices. I will try to organize an out-of-tree round of testing for this. |
|||
| date | 2021-07-18T14:38:20Z | |||
|---|---|---|---|---|
| author | bluhm | |||
| files | src/sys/netinet/ip_ah.c | log | diff | annotate |
| src/sys/netinet/ip_esp.c | log | diff | annotate | |
| src/sys/netinet/ip_ipsp.h | log | diff | annotate | |
| message |
The IPsec authentication before decryption used a different replay counter than after decryption. This could result in "esp_input_cb: authentication failed for packet in SA" errors. As we run crypto operations async, thousands of packets are stored in the crypto task. During the queueing the replay counter of the tdb can change. Then the higher 32 bits may increment although the lower 32 bits did not wrap. checkreplaywindow() must be called twice per packet with the same replay counter. Store the value in struct tdb_crypto while dangling in the task queue and doing crypto operations. tested by Hrvoje Popovski; joint work with tobhe@ |
|||
| date | 2021-07-18T18:19:22Z | |||
|---|---|---|---|---|
| author | mvs | |||
| files | src/sys/netinet/ip_ipsp.c | log | diff | annotate |
| src/sys/netinet/ip_ipsp.h | log | diff | annotate | |
| message |
Introduce and use garbage collector for 'ipsec_ids' struct entities destruction instead of using per-entity timeout. This fixes the races between ipsp_ids_insert(), ipsp_ids_free() and ipsp_ids_timeout(). ipsp_ids_insert() can't stop ipsp_ids_timeout() timeout handler which is already running and awaiting netlock to be released, so reused `ids' will be silently removed in this case. ipsp_ids_free() can't determine is ipsp_ids_timeout() timeout handler running because timeout_del(9) called by ipsp_ids_insert() clears it's triggered state. So ipsp_ids_timeout() could be scheduled to run twice in this case. Also hrvoje@ reported about ipsec(4) throughput increased with this diff so it seems we caught significant count of ipsp_ids_insert() races. tests and feedback by hrvoje@ ok bluhm@ |
|||