created | 2019-11-02T14:56:36Z |
---|---|
begin | 2019-10-31T00:00:00Z |
end | 2019-11-01T00:00:00Z |
path | src/sys |
commits | 2 |
date | 2019-10-31T11:03:43Z | |||
---|---|---|---|---|
author | stsp | |||
files | src/sys/net80211/ieee80211_node.c | log | diff | annotate |
src/sys/net80211/ieee80211_var.h | log | diff | annotate | |
message |
Make background scans less frequent if we keep choosing the same AP. This helps a bit in situations where a single AP is used and background scans are causing packet loss, as seen with Jesper Wellin's Broadcom-based AP and my Android phone in hotspot mode. This is not a proper fix but our background scan frequency against a single AP was much higher than needed anyway. Tested by jan, job, benno, Tracey Emery, Jesper Wallin |
date | 2019-10-31T22:28:26Z | |||
---|---|---|---|---|
author | patrick | |||
files | src/sys/arch/arm/arm/cpufunc_asm_armv7.S | log | diff | annotate |
message |
In 2013, when OpenBSD/armv7 was still rather early, improvements for that platform have been trickling in bit by bit. One of those changes unfortunately introduced a regression in cache flushes. The check for the length in the cache-flush-loop was changed from the instruction bpl to bhi. This has the effect that it does not branch on zero anymore. Due to the length decrement at the beginning of the function, which was not removed, a length of (n * cacheline) + 1 means that the loop misses one run! This means it is possible that the last byte of a DMA transfer was incorrect, as one could see on network packets often enough. Remove that instruction, which makes it even more similar to the OpenBSD/arm64 code. ok deraadt@ |