12bb3886c5
62681 Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
Adrien Destugues
|
0a6ab6bbca |
Input preferences: some style fixes.
Problems found by running haiku-format and looking at the resulting files. Manually triaged to keep only the correct changes, currently haiku-format is making a lot of unwanted changes as well. Merging the correct changes allows us to see the incorrect ones more easily and continue working on fixing them. |
||
|
Jérôme Duval
|
b25103cc9c |
kernel: generic user_memcpy() should clear_ac after the fault handler returns
the AC flag in eflags/rflags, pushed in the iframe by the CPU, is kept intact after handling the exception, since the fault handler is run with the faulted iframe and does a simple jump. The AC flag would otherwise be set until the syscall returns to userland. Change-Id: I24f763032ab98029dd162fb411e1541586451606 Reviewed-on: https://review.haiku-os.org/c/haiku/+/4040 Reviewed-by: Adrien Destugues <pulkomandy@gmail.com> Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org> |
||
|
Adrien Destugues
|
4d0359955f |
gitignore: Add Visual Studio Code and IntelliJ IDEA configuration directories
Co-authored-by: Panagiotis Vasilopoulos <hello@alwayslivid.com> Change-Id: Ibed5c5be410bf61d36dc12dce74d9bc1706f2b0a Reviewed-on: https://review.haiku-os.org/c/haiku/+/4039 Reviewed-by: Adrien Destugues <pulkomandy@gmail.com> |
||
|
X512
|
af435dd1c9 |
libroot: remove delete_driver_settings
It is not present in BeOS R5 and it just call unload_driver_settings. Replace delete_driver_settings usages with unload_driver_settings. Keep the symbol on x86 for binary compatibility. Change-Id: I1382710e3a4cb5c65d1249ea0e5880891e6800e4 Reviewed-on: https://review.haiku-os.org/c/haiku/+/3485 Reviewed-by: Jérôme Duval <jerome.duval@gmail.com> |
||
|
X512
|
7806eafaa3 |
AutoLocker: add BHandler support
Change-Id: Ifaee00664eab78f0b6f67a8b716e3db8af710acd Reviewed-on: https://review.haiku-os.org/c/haiku/+/4008 Reviewed-by: Jérôme Duval <jerome.duval@gmail.com> |
||
|
X512
|
9d57225b8c |
libroot/posix: implement arch-specific parts for riscv64
Change-Id: Ia1eac32b383857724dd00b227a735174ff6f0a63 Reviewed-on: https://review.haiku-os.org/c/haiku/+/3984 Reviewed-by: X512 <danger_mail@list.ru> Reviewed-by: Adrien Destugues <pulkomandy@gmail.com> |
||
|
X512
|
178c7c5a98 |
runtime_loader: implement relocations for riscv64
Change-Id: I98f179fefd8bb732aa04b52aeb59c7b4d0620c05 Reviewed-on: https://review.haiku-os.org/c/haiku/+/3985 Reviewed-by: X512 <danger_mail@list.ru> Reviewed-by: Adrien Destugues <pulkomandy@gmail.com> |
||
|
X512
|
d00fc0e3e6 |
BTextView: fix Text field scripting
Change-Id: I2048d7f01fa3694d5687447cf7058fecf03ae15d Reviewed-on: https://review.haiku-os.org/c/haiku/+/4007 Reviewed-by: X512 <danger_mail@list.ru> Reviewed-by: John Scipione <jscipione@gmail.com> Reviewed-by: Jérôme Duval <jerome.duval@gmail.com> |
||
|
Autocomitter
|
8c039e20f2 | Update translations from Pootle | ||
|
Rudolf Cornelissen
|
c7d83a174c | Intel_extreme: fixed DPLL pgming (Sandy+), prevent black display by not killing PIPE (Ivy+). Chkd GMA(Q33G/Q45) OK. Added defines. | ||
|
Jérôme Duval
|
5cad57c43b |
Reapply "freebsd_wlan: apply net80211 commits from FreeBSD 13 except four commits"
Reason for reapply: ticket #16958 regression testing not conclusive Change-Id: Id8fb4c865db9107a31542d1db987db9a73140f9c Reviewed-on: https://review.haiku-os.org/c/haiku/+/4016 Reviewed-by: Jérôme Duval <jerome.duval@gmail.com> |
||
|
X512
|
0b4660ae5a |
BeBuild: add ALWAYS_INLINE macro
only available on gcc 4 and upper. Change-Id: Ifc059d5fedd15a5aeda1514312fbbf98a72d3128 Reviewed-on: https://review.haiku-os.org/c/haiku/+/4005 Reviewed-by: Jérôme Duval <jerome.duval@gmail.com> |
||
|
X512
|
a182bd6eb5 |
haiku_loader: initial support for RISC-V TinyEMU
Change-Id: Ie102f466725f45072db25a9629fa8e28526484eb Reviewed-on: https://review.haiku-os.org/c/haiku/+/3882 Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com> |
||
|
X512
|
44a8696dc5 |
add VirtIO header
Change-Id: I938e80fe156a0a1d49e0eef330cbfc0cf22f0995 Reviewed-on: https://review.haiku-os.org/c/haiku/+/4002 Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com> |
||
|
X512
|
b8b1ad6fc4 |
introduce RISC-V headers
Change-Id: I9a8b6a1011cbefd4bd173852e7111e92efd0c730 Reviewed-on: https://review.haiku-os.org/c/haiku/+/4003 Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com> |
||
|
X512
|
1b41be049b |
libroot: convert pthread_spinlock to C++
Change-Id: Ic65b624d343c2cdb4bbb138c94c0ea2f01f27139 Reviewed-on: https://review.haiku-os.org/c/haiku/+/4006 Reviewed-by: Adrien Destugues <pulkomandy@gmail.com> |
||
|
Pascal Abresch
|
29a109bd6c |
Framebuffer console: Add spleen font (12x24)
Use this larger font when the screen resolution is large (more than 1920x1080 in both directions). The usual font is too small and not easy to read on such high resolution displays. Change-Id: I14a40ecf6917d0c6c64ab5a8abe1affcb3839a74 Reviewed-on: https://review.haiku-os.org/c/haiku/+/3818 Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org> Reviewed-by: Adrien Destugues <pulkomandy@gmail.com> |
||
|
Fredrik Holmqvist
|
3b49957171 |
Fix ARM64 relocation function unused attrs
Similar to other architectures. |
||
|
X512
|
1542053775 |
video_mixer: fix build for non-x86
Change-Id: Id5701d472415fe68685c3d8126566b93443810bb Reviewed-on: https://review.haiku-os.org/c/haiku/+/3988 Reviewed-by: Jérôme Duval <jerome.duval@gmail.com> |
||
|
X512
|
5fcf71f504 |
Remove unneeded iostream includes
It cause adding new entry to executable init array for each translation unit. Change-Id: I1e2d7946da03c001de7721948bc9af8188e8b317 Reviewed-on: https://review.haiku-os.org/c/haiku/+/3981 Reviewed-by: X512 <danger_mail@list.ru> Reviewed-by: Adrien Destugues <pulkomandy@gmail.com> |
||
|
Alexander von Gluck IV
|
53d0323422 |
xhci: Check endpoint state before stop
* As per the spec, the only exit from an endpoint in a halt state is to issue a restart command. (restart puts the endpoint into a stop state.. it's named poorly) Change-Id: I4a1a556374ad7f564a562d995d1a2e29230a50c3 Reviewed-on: https://review.haiku-os.org/c/haiku/+/3959 Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com> |
||
|
Máximo Castañeda
|
bd6434b663 |
Revert "packagefs and IOCache: don't reread pages when we have them all."
This reverts commit
|
||
|
Jérôme Duval
|
00ba3fd01b |
Revert "freebsd_wlan: apply net80211 commits from FreeBSD 13 except four commits"
This reverts commit
|
||
|
Autocomitter
|
8516b308f8 | Update translations from Pootle | ||
|
Jérôme Duval
|
2b4bf3eef6 |
i2c_hid: driver for i2c-hid devices
This is getting more common in tablets and laptops. It replaces PS/2 for the internal keyboard and pointing devices. This is simpler and cheaper than using up USB ports, and also simpler than the old and quirky PS/2 protocol. The HID spec is the same no matter what transport is used (it is also applicable for Bluetooth). Ideally we could create a separate HID bus manager that would handle all these devices in a generic way, but that is a lot of work nad extra complications for uncertain gains. For now, just move the common files to a shared directory where both drivers can use them. As a result the files are compiled twice, which is what we want, because currently they hardcode some device paths that need to be different for each driver. Change-Id: I0327f6864dd0a4372b708f7b7ecf299aa86a6ea9 Reviewed-on: https://review.haiku-os.org/c/haiku/+/2466 Reviewed-by: Adrien Destugues <pulkomandy@gmail.com> Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org> |
||
|
Jérôme Duval
|
22c72a99f9 |
build: remove wavelanwifi from the default image
wi(4) was removed in FreeBSD 13 Change-Id: I4008dba521e6246c817668f49169db1559908824 Reviewed-on: https://review.haiku-os.org/c/haiku/+/3957 Reviewed-by: Rene Gollent <rene@gollent.com> |
||
|
Jérôme Duval
|
65f52a5f56 |
build: remove the firewire support from the default image
decommissioning. Change-Id: Ie7ccba705f7282193120241479d2ae83bd271b2c Reviewed-on: https://review.haiku-os.org/c/haiku/+/3956 Reviewed-by: Adrien Destugues <pulkomandy@gmail.com> Reviewed-by: Fredrik Holmqvist <fredrik.holmqvist@gmail.com> Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org> |
||
|
Panagiotis Vasilopoulos
|
39e2ee5186 |
Replaced and updated Docker images
Change-Id: I981a4a3416b3827a3d834f0103527b0432cbdb87 Reviewed-on: https://review.haiku-os.org/c/haiku/+/3915 Reviewed-by: Adrien Destugues <pulkomandy@gmail.com> |
||
|
Jérôme Duval
|
474e0be842 |
atheroswifi: apply commits from FreeBSD 13 except
654517304167bb4675aa14ada0a1dac9efe71c9b Convert to if_foreach_llmaddr() KPI.
5ab0c8434a7befeafbaf81e899fc23f660b64c9d ath(4) processing input packets in taskqueue.
6c3e93cb5a4aa4b8a2d8d4d326f2a7c34d3a4458 Use NET_TASK_INIT() and NET_GROUPTASK_INIT()
add extra ANI fields for the AR9300 HAL.
I'm trying to debug why reception upstairs here is so terrible and it
turns out ANI is buggy. (Which is no surprise, ANI is always buggy.)
Tested:
* Carambola2 (AR9331), STA/AP modes
ANI fixes and preparation for userland control.
* The ani function bitmap was being badly used when determining if a command
could be used. In hostap modes only a couple of the ANI control parameters
are enabled.
* The ani function bitmap was not being reset to HAL_ANI_ALL if transitioning
from AP -> STA.
* Change mrcCckOff to mrcCck - 1 == on, rather than 1 == off. This matches
the API used to set the value from userland via the diagnostic API.
* Handle OFDM/CCK noise immunity level commands in ar9300_ani_control().
These will only come from userland and it will go and program the rest of
the ANI control parameters with the values in the ANI table.
* Ensure all of the ANI parameters can be tweaked at runtime, even if they're
disabled.
Tested:
* carambola2 (AR9331), STA/AP modes
Fix return value check to not complain.
Compilers complain more about things, so let's keep them happy.
Extend the start PCU receive to handle resetting ANI.
One of the fun issues with scanning has been how the existing
ANI values were programmed into the hardware when channels were
changed. If you're on a really crappy channel and ANI has made
you deaf then when you scan you continue to be deaf on all channels.
This code passes in a flag to startpcureceive which in AR5416 and later
is also used to enable ANI. This allows it to know if it's a normal
operation or a scan operation.
This fixes my situation at home where a temporary spot of a device
going deaf due to interference starts scanning and .. can't hear
anything until I restart.
Now, this isn't the full fix - ideally:
(a) all the ANI config and per-channel information would be migrated
to the shared HAL stuff and enabled for all of the NICs;
(b) when a station reassociates and some other error conditions
(like missed beacons, NF calibration failures, etc) a knob
to reset ANI parameters would likely help recovery.
But hey, I'm committing bits of code again! woo!
Tested:
* AR9344 (2G), STA operation
Fix ANI calibration during non-ACTIVE states; start poking at rate control
These are some fun issues I've found with my upstairs wifi link at such a ridiculous
low signal level (like, < 5dB.)
* Add per-station tx/rx rssi statistics, in potential preparation to use that
in the RX rate control.
* Call the rate control on each received frame to let it potentially use
it as a hint for what rates to potentially use. It's a no-op right now.
* Do ANI calibration during scan as well. The ath_newstate() call was disabling the
ANI timer and only re-enabling it during transitions to _RUN. This has the
unfortunate side-effect that if ANI deafened the NIC because of interference
and it disassociated, it wouldn't be reset and the scan would never hear beacons.
The ANI configuration is stored at least globally on some HALs and per-channel
on others. Because of this a NIC reset wouldn't help; the ANI parameters would
simply be programmed back in.
Now, I have a feeling I also need to do this during AUTH/ASSOC too and maybe,
if I'm feeling clever, I need to reset the ANI parameters on a given channel
during a transition through INIT or if the VAP is destroyed/re-created.
However for now this gets me out of the immediate weeds with connectivity
upstairs (and thus I /can/ commit); I'll keep chipping away at tidying this
stuff up in subsequent commits.
Tested:
* AR9344 (Wasp), 2G STA mode
Have the final attempted rate in 11n modes to be the lowest one.
Right now ath_rate_sample has a fixed rate schedule, rather than the minstrel_ht
style "best, good, most reliable" triplet. So, if higher rates are tried then
it'll not fail back to a lower MCS rate in that transmission schedule.
This means that in low SNR situations it'll not easily drop to MCS0 unless enough
transmissions occur to allow rate control to eventually decide to drop; and if
it's TCP traffic it'll get slowed down because of packet loss.
It's worse for 2-stream and 3-stream rates; it doesn't ever fall back to lower
stream rates, and these higher stream rates required higher SNR to work.
So instead let's (for now?) have each of the 11n transmit rates use MCS0 as
the last attempt. ath_rate_sample will quickly see that rate succeeds more
and will move to it much quicker.
Testing:
* AR9344 (Wasp) - 2G STA mode
Fix queue bits a bit
Found by PVS Studio: duplicate assignment; add assignment of tqi_compBuf.
Submitted by: <mizhka@gmail.com>
Differential Revision: https://reviews.freebsd.org/D20431
ath_hal: fix typo in ath_hal_printf
Fix endian macros to work in and out of kernel tree.
Yes, people shouldn't use bitfields in C for structure parsing.
If someone ever wants a cleanup task then it'd be great to remove them
from this vendor code and other places in the ar9285/ar9287 HALs.
Alas, here we are.
AH_BYTE_ORDER wasn't defined and neither were the two values it could be.
So when compiling ath_ee_print_9300 it'd default to the big endian struct
layout and get a WHOLE lot of stuff wrong.
So:
* move AH_BYTE_ORDER into ath_hal/ah.h where it can be used by everyone.
* ensure that AH_BYTE_ORDER is actually defined before using it!
This should work on both big and little endian platforms.
Add some extra data into the rate control lookup.
Right now (well, since I did this in 2011/2012) the rate control code
makes some super bad choices for 11n aggregates/rates, and it tracks
statistics even more questionably.
It's been long enough and I'm now trying to use it again daily, so let's
start by:
* telling the rate control code if it's an aggregate or not;
* being clearer about the TID - yes it can be extracted from the
ath_buf but this way it can be overridden by the caller without
changing the TID itself.
(This is for doing experiments with voice/video QoS at some point..)
* Return an optional field to limit how long the aggregate is in
microseconds. Right now the rate control code supplies a rate table
and the ath aggr form code will look at the rate table and limit
the aggregate size to 4ms at the slowest rate. Yeah, this is pretty
terrible.
* Add some more TODO comments around handling txpower, rate and
handling filtered frames status so if I continue to have spoons for
this I can go poke at it.
Extend ath_rate_sample to better handle 11n rates and aggregates.
My initial rate control code was .. suboptimal. I wanted to at least get MCS
rates sent, but it didn't do anywhere near enough to handle low signal level links
or remotely keep accurate statistics.
So, 8 years later, here's what I should've done back then.
* Firstly, I wasn't at all tracking packet sizes other than the two buckets
(250 and 1600 bytes.) So, extend it to include 4096, 8192, 16384, 32768 and
65536. I may go add 2048 at some point if I find it's useful.
This is important for a few reasons. First, when forming A-MPDU or AMSDU
aggregates the frame sizes are larger, and thus the TX time calculation
is woefully, increasingly wrong. Secondly, the behaviour of 802.11 channels
isn't some fixed thing, both due to channel conditions and radios themselves.
Notably, there was some observations done a few years ago on 11n chipsets
which noticed longer aggregates showed an increase in failed A-MPDU sub-frame
reception as you got further along in the transmit time. It could be due to
a variety of things - transmitter linearity, channel conditions changing,
frequency/phase drift, etc - but the observation was to potentially form
shorter aggregates to improve BER.
* .. and then modify the ath TX path to report the length of the aggregate sent,
so as the statistics kept would line up with the correct bucket.
* Then on the rate control look-up side - i was also only using the first frame
length for an A-MPDU rate control lookup which isn't good enough here.
So, add a new method that walks the TID software queue for that node to
find out what the likely length of data available is. It isn't ALL of the
data in the queue because we'll only ever send enough data to fit inside the
block-ack window, so limit how many bytes we return to roughly what ath_tx_form_aggr()
would do.
* .. and cache that in the first ath_buf in the aggregate so it and the eventual
AMPDU length can be returned to the rate control code.
* THEN, modify the rate control code to look at them both when deciding which bucket
to attribute the sent frame on. I'm erring on the side of caution and using the
size bucket that the lookup is based on.
Ok, so now the rate lookups and statistics are "more correct". However, MCS rates
are not the same as 11abg rates in that they're not a monotonically incrementing
set of faster rates and you can't assume that just because a given MCS rate fails,
the next higher one wouldn't work better or be a lower average tx time.
So, I had to do a bunch of surgery to the best rate and sample rate math.
This is the bit that's a WIP.
* First, simplify the statistics updates (update_stats()) to do a single pass on
all rates.
* Next, make sure that each rate average tx time is updated based on /its/ failure/success.
Eg if you sent a frame with { MCS15, MCS12, MCS8 } and MCS8 succeeded, MCS15 and MCS
12 would have their average tx time updated for /their/ part of the transmission,
not the whole transmission.
* Next, EWMA wasn't being fully calculated based on the /failures/ in each of the
rate attempts. So, if MCS15, MCS12 failed above but MCS8 didn't, then ensure
that the statistics noted that /all/ subframes failed at those rates, rather than
the eventual set of transmitted/sent frames. This ensures the EWMA /and/ average
TX time are updated correctly.
* When picking a sample rate and initial rate, probe rates aroud the current MCS
but limit it to MCS0..7 /for all spatial streams/, rather than doing crazy things
like hitting MCS7 and then probing MCS8 - MCS8 is basically MCS0 but two spatial
streams. It's a /lot/ slower than MCS7. Also, the reverse is true - if we're at
MCS8 then don't probe MCS7 as part of it, it's not likely to succeed.
* Fix bugs in pick_best_rate() where I was /immediately/ choosing the highest MCS
rate if there weren't any frames yet transmitted. I was defaulting to 25% EWMA and
.. then each comparison would accept the higher rate. Just skip those; sampling
will fill in the details.
So, this seems to work a lot better. It's not perfect; I'm still seeing a lot of
instability around higher MCS rates because there are bursts of loss/retransmissions
that aren't /too/ bad. But i'll keep iterating over this and tidying up my hacks.
Ok, so why this still something I'm poking at? rather than porting minstrel_ht?
ath_rate_sample tries to minimise airtime, not maximise throughput. I have
extended it with an EWMA based on sub-frame success/failures - high MCS rates
that have partially successful receptions still show super short average frame
times, but a /lot/ of retransmits have to happen for that to work.
So for MCS rates I also track this EWMA and ensure that the rates I'm choosing
don't have super crappy packet failures. I don't mind not getting lower
peak throughput versus minstrel_ht; instead I want to see if I can make "minimise
airtime" work well.
Tested:
* AR9380, STA mode
* AR9344, STA mode
* AR9580, STA/AP mode
le oops, trim out an #if 1 that I didn't fully delete.
Cool, so now I know it's about 3 weeks between starting on freebsd coding
and breaking the build again. Queue dunce cap.
Fix logic for determining whether to bump up an MCS rate.
* Fix formatting, cause reasons;
* Put back the "and the chosen rate is within 90% of the current rate" logic;
* Ensure the best rate and the current rate aren't the same; this ...
* ... fixes the packets_since_switch[] tracking to actually conut how many
frames since the rate switched, so now I know how stable stuff is; and
* Ensure that MCS can go up to a higher MCS at this or any other spatial stream.
My previous quick hack attempt was doing > rather than >= so you had to go
to both a higher root MCS rate (0..7) and spatial stream. Eg, you couldn't
go from MCS0 (1ss) to MCS8 (2ss) this way.
The best rate and switching rate logic still have a bunch more work to do
because they're still quite touchy when it comes to average tx time but at least
now it's choosing higher rates correctly when it wants to try a higher rate.
Tested:
* AR9380, STA mode
Limit the tx schedules for A-MPDU ; don't take short retries into account and remove the requirement that the MCS rate is "higher" if we're considering a new rate.
Ok, another fun one.
* In order for reliable non-software retried higher MCS rates, the TX schedules
(inconsistently!) use hard-coded lower rates at the end of the schedule.
Now, hard-coded is a problem because (a) it means that aggregate formation
is limited by the SLOWEST rate, so I never formed large AMDU frames for
3 stream rates, and (b) if the AP disables lower rates as base rates, it
complains about "unknown rix" every frame you transmit at that rate.
So, for now just disable the third and fourth schedule entry for AMPDUs.
Now I'm forming 32k and 64k aggregates for the higher density MCS rates
much more reliably.
It would be much nicer if the rate schedule stuff wasn't fixed but instead
I'd just populate ath_rc_series[] when I fetch the rates. This is all a
holdover of ye olde pre-11n stuff and I really just need to nuke it.
But for now, ye hack.
* The check for "is this MCS rate better" based on MCS itself is just garbage.
It meant things like going MCS0->7 would be fine, and say 0->8->16 is fine,
(as they're equivalent encoding but 1,2,3 spatial streams), BUT it meant
going something like MCS7->11 would fail even though it's likely that
MCS11 would just be better, both for EWMA/BER and throughput.
So for now just use the average tx time. The "right" way for this comparison
would be to compare PHY bitrates rather than MCS / rate indexes, but I'm not
yet there. The bit rates ARE available in the PHY index, but honestly
I have a lot of other cleaning up to here before I think about that.
* Don't include the RTS/CTS retry count (and thus time) into the average tx time
caluation. It just makes temporarily failures make the rate look bad by
QUITE A LOT, as RTS/CTS exchanges are (a) long, and (b) mostly irrelevant
to the actual rate being tried. If we keep hitting RTS/CTS failures then
there's something ELSE wrong on the channel, not our selected rate.
Fix correct status when completing frames with short failures.
My preivous logic was a bit wrong. This caused transmissions that failed due
to a mix of short and long retries to count intermediate rates as OK if the
LONG retry count indicated some retries had made it to this intermediate rate,
but the SHORT retry count was the one that caused the whole transmit to fail.
Now status is passed in again - and this is the status for the whole transmission -
and then update_stats() does some quick math to see if the current transmission
series hit its long retry count or not before updating things as a success
or failure.
Obey the maximum frame length even when using static rates.
I wasn't enforcing the maximum packet length when using static rates
so although the driver was enforcing it itself OK, the statistics were
sometimes going into the wrong bin.
Tested:
* AR9380, STA mode
reset hardware if this particular mac bug is seen.
I have to dig into why I'm seeing it on chips as late as the AR9380 era
stuff (as it's marked as an AR5416 bug, but who knows!) but i'm seeing
aggregate TX frames complete with no blockack bit set. So, everything
should be treated as a failure and do a hardware reset for good measure.
Tested:
* AR9380, STA mode
* AR9580 (5GHz), AP mode
Hopefully recover better-er upon RX restart on AR9380.
This is all very long-standing bug stuff that is touchy and still poorly
documented. Ok, here goes.
The basic bug:
* deleting a VAP causes the RX path (and TX path too) to be restarted
without a full chip reset, which causes RX hangs on the AR9380 and later.
(ie, the ones with the newer DMA engine.)
The basic fix:
* do an RX flush when stopping RX in ath_vap_delete() to match what happens
when RX is stopped elsewhere. This ensures any pending frames are completed
and we restart at the right spot; it also ensures we don't push new RX buffers
into the hardware if we're stopping receive.
The other issues I found:
* Don't bother checking the RX packet ring in the deferred read taskqueue;
that's specifically supposed to be for completing frames rather than
just yanking them off the receive ring.
* Cancel/drain any pending deferred read taskqueue. This isn't done inside
any locks so we should be super careful here. This stops the hardware
being reprogrammed at the same time in another thread/CPU whilst we're
stopping RX.
* .. (yes, this should be better serialised, but that's for another day. maybe.)
* Add more debugging to trace what's going on here.
And the fun bit:
* Reinitialise the RX FIFO ONLY if we've been reset or stopped, rather than just
reset. I noticed that after all the above was done I was STILL seeing RXEOL.
RXEOL isn't enabled on the AR9380 so I'd only see it if I was sending TX frames
(ie a ping where it'd be transmitted but never received) so I was not being
spammed by RXEOL. So, as long as stuff is stopped, restart it.
This seems to be doing the right thing in both AP and STA modes.
What I should do next, if I ever get time:
* as I said above, serialise the receive stop/start to include taskqueues
* monitor RXEOL on the AR9380 and I keep seeing it spammed / lockups, just
go do a full chip reset to get things back on track. It sucks, but it
is better than nothing.
Tested:
* AR9380 AP/STA mode, adding/deleting a hostap VAP to trigger the TX/RX
queue stop/start; whilst also running an iperf through it. Lots of times.
Lots. Of.. Times.
Propagate the HAL_RESET_TYPE through to the chip reset; set it during ath_reset()
Although I added the reset type field to ath_hal_reset() years ago,
I never finished adding it both throughout the HALs and in if_ath.c.
This will eventually deprecate the ath_hal force_full_reset option
because it can be requested at the driver layer.
So:
* Teach ar5416ChipReset() and ar9300_chip_reset() about the HAL type
* Use it in ar5416Reset() and ar9300_reset() when doing a full chip reset
* Extend ath_reset() to include the HAL_RESET_TYPE parameter added in the above functions
* Use HAL_RESET_NORMAL in most calls to ath_reset()
* .. but use HAL_RESET_BBPANIC for the BB panics, and HAL_RESET_FORCE_COLD during fatal, beacon miss and other hardware related hangs.
This should be a glorified no-op outside of actual hardware issues.
I've tested things with ath_hal force_full_reset set to 1 for years now,
so I know that feature and a full reset works (albeit much slower than
a warm reset!) and it does unwedge hardware.
The eventual aim is to use this for all the places where the driver
detects a potential hang as well as if long calibration - ie, noise floor
calibration - fails to complete. That's one of the big hardware related
things that causes station mode operation to hang without easy recovery.
Differential Revision: https://reviews.freebsd.org/D24981
Update ath_rate_sample to use the same base type as ticks.
Until net80211 grows a specific ticks type that matches the system,
manually use the same type as the kernel/net80211 'ticks' type
(signed int.)
Tested:
* AR9380, STA mode
Don't re-program the beacon timers if we miss a beacon in software-beacon STA mode.
This is something I added a few years ago to handle resyncing the beacon if
we miss a beacon or need to sync after association/reassociation/powersave.
However, if we're doing STA+AP mode (eg DWDS) then we don't want
to reprogram the beacons here; this may upset normal AP operation.
I missed checking for the sc->sc_swbmiss flag so I was reinitialising
the beacon timers after every beacon miss / TSFOOR option, and
that isn't likely good.
This plus ensuring that STA's are created with "-beacon" to disable
BMISS/TSFOOR processing will hopefully quieten some of the issues
I've seen with missed beacons / TSFOOR (out of range) interrupts
coming in when operating in STA mode.
Tested:
* AR9380/AR9580, STA+AP modes
Don't update the beacon bits from beacon frames in hostapd mode.
This logic is running the beacon receive bits in STA+AP mode on both the
STA and AP side. The STA side sees its beacons from the BSS fine; the
AP side is seeing other beacons on the same channel but with the BSS
node for some odd reason. (I think it's a valid reason, but I currently
forget what that valid reason is.)
So, just to be cleaner about things, don't run the nexttbtt/etc bits
at all if we're in hostap mode. If I ever get mesh working then maybe
I'll make sure it works right on mesh+ap and mesh+sta modes.
Whilst here, log the VAP i'm being called on to make it clearer what
is going on. I may end up adding a VAP dprintf version of this at
some point.
Tested:
* AR9380, STA (DWDS client) + hostap on the same NIC
Add KeyMiss for AR5212/AR5416 series chips.
This is a flag from the MAC that says the received packet didn't match
a keycache slot. This isn't technically a problem as WEP keys don't
match keycache slots (they're "global" keys), but it could be useful
for tracking down CCMP decryption failures.
Right now it's a no-op - it mirrors what the AR9300 HAL does and it
just increments a counter. But, hey, maybe one day I'll use it for
diagnosing keycache/CCMP decrypt issues.
ath: clean up empty lines in .c and .h files
replace the hard-coded magic values in if_athioctl.h with constant defines
Replace some hard-coded magic values in the ioctl stats struct with
defines. I'm going to follow up with some more sanity checking in
the receive path that also use these values so we don't do bad
things if the hardware is (more) confused.
Don't use hard-coded values in the sanity check.
Don't use hard-coded values in the phy error and receive antenna
checks.
also remove the magic size value here for the transmit antenna statistics.
Change-Id: Ifebebef068d9abe7abfa61204dc900095bd6914c
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3921
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
|
||
|
Han Pengfei
|
cd9b0eed94 |
efi/dtb: Fix dtb malloc failed for kernel args
kernel_args_malloc should be used after heap_init, or it will failed when we new some region instance. Change-Id: I457057b1e0ff6d4def9e101485e38fec1848d8de Signed-off-by: Han Pengfei <pengphei@qq.com> Reviewed-on: https://review.haiku-os.org/c/haiku/+/3912 Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com> Reviewed-by: Adrien Destugues <pulkomandy@gmail.com> |
||
|
X512
|
4a6c01c33f |
glue: implement for riscv64
Change-Id: I0d701050e8ee008db68b54d458de07c653a370d7 Reviewed-on: https://review.haiku-os.org/c/haiku/+/3920 Reviewed-by: Adrien Destugues <pulkomandy@gmail.com> |
||
|
Andriy Voskoboinyk
|
0ba2e27fc4 |
wlan: apply iwn,bwi,mwl commits from FreeBSD 13
iwn(4): (partially) rewrite A-MPDU Tx path Generic Tx stats fixes: - do not try to parse "aggregation status" for single frames; send them to iwn_tx_done() instead; - try to attach mbuf / node reference pair to reported BA events; allows to fix reported status for ieee80211_tx_complete() and ifnet counters (previously all A-MPDU frames were counted as failed - see PR 210211); requires few more firmware bug workarounds; - preserve short / long retry counters for wlan_amrr(4) (disabled for now - causes significant performance degradation). - Add new IWN_DEBUG_AMPDU debug category. - Add one more check into iwn_tx_data() to prevent aggregation ring overflow. - Workaround 'seqno % 256' != 'current Tx slot' case (until D9195 is not in the tree). - Improve watchdog timer updates (previously watchdog check was omitted when at least one frame was transmitted). - Stop Tx when memory leak in currently used ring was detected (unlikely to happen). - Few other minor fixes. Was previously tested with: - Intel 6205, STA mode (Tx aggregation behaves much better now). - Intel 4965AGN, STA mode (still unstable). PR: 192641, 210211 Reviewed by: adrian, dhw MFC after: 1 month Differential Revision: https://reviews.freebsd.org/D10728 iwn(4): drop return code from iwn_*attach functions (they cannot fail) While here, add missing trace 'end' marker in iwn5000_attach(). MFC after: 1 week iwn(4): drop i_seq field initialization for A-MPDU frames. It is done by net80211 since r319460. MFC after: 24 days X-MFC-With: 343094 iwn(4): plug initialization path vs interrupt handler races There are few places in interrupt handler where the driver lock is dropped; ensure that device is still running before processing remaining ring entries. PR: 192641 MFC after: 5 days iwn: Set default ampdu parameters. These are from the linux iwlwifi driver ;the default use smaller maximum AMPDUs (8k) and a much smaller density (none.) The latter could cause stability issues. Tested: * Tested on Intel 6300, STA mode. Differential Revision: https://reviews.freebsd.org/D25113 bwi: clean up empty lines in .c and .h files mwl: clean up empty lines in .c and .h files Fix ieee80211_radiotap(9) usage in wireless drivers: - Alignment issues: * Add missing __packed attributes + padding across all drivers; in most places there was an assumption that padding will be always minimally suitable; in few places - e.g., in urtw(4) / rtwn(4) - padding was just missing. * Add __aligned(8) attribute for all Rx radiotap headers since they can contain 64-bit TSF timestamp; it cannot appear in Tx radiotap headers, so just drop the attribute here. Refresh ieee80211_radiotap(9) man page accordingly. - Since net80211 automatically updates channel frequency / flags in ieee80211_radiotap_chan_change() drop duplicate setup for these fields in drivers. Tested with Netgear WG111 v3 (urtw(4)), STA mode. MFC after: 2 weeks Change-Id: I7f194a3b78a058aa598634039cfab27e415a4894 Reviewed-on: https://review.haiku-os.org/c/haiku/+/3917 Reviewed-by: Adrien Destugues <pulkomandy@gmail.com> |
||
|
Adrien Destugues
|
ae0a10cad3 |
Update readme for docker images
There was some confusion about what they are and how they are used. Hopefully this clarifies things a bit. |
||
|
Adrien Destugues
|
bb76d2f16c |
Update AboutSystem credits
- Add madmax - Move rudolfc back to active contributors - Add Shubham and Suhel to contributors, as former GSoC students and as GSoC mentors Change-Id: I2c4c1d4795e54158b837510b5a9832881ae80c21 Reviewed-on: https://review.haiku-os.org/c/haiku/+/3909 Reviewed-by: Jérôme Duval <jerome.duval@gmail.com> |
||
|
Alexander G. M. Smith
|
b5efad4eae |
PackageKit: Remove hard coded first boot package processing scripts.
Once change 2342 is in place (running first boot scripts exported from packages), see https://review.haiku-os.org/c/haiku/+/2342, remove data/system/boot/post_install/add_catalog_entry_attributes.sh and related support infrastructure (magic files, launch_roster entries). The work this script did can in fact be done at image creation time instead of at first boot. Change-Id: I485e1a0a87c3e6a6ba3f882e65996f2327134d37 Reviewed-on: https://review.haiku-os.org/c/haiku/+/3751 Reviewed-by: Adrien Destugues <pulkomandy@gmail.com> |
||
|
Andriy Voskoboinyk
|
a4caca440c |
freebsd_wlan: apply net80211 commits from FreeBSD 13 except four commits
fb3bc59600e25268ed5750fdc351b1e9423a8fb4 Restructure mbuf send tags to provide stronger guarantees. 2b60ecf197e0e187ac028d66d279805e6bece77b Don't use if_maddr_rlock() in 802.11, use epoch(9) directly 998bd62c311425c8cebb4506d7d4a3a9d5ff7f9e [net80211] Print out a bad PN in both hex and decimal. 8bc0d2b8553e012412d03468f84588dc34dea4c4 Fix !DEBUGNET build after r362138 tested with idualwifi7260, iprowifi4965 and atheroswifi net80211: fix out-of-bounds read in ieee80211_amrr(9). ieee80211_alloc_node() does not initialize rateset tables; that's not expected by rate control modules and will result in array access at index -1 - where ni_essid[] array is located (zeroed at allocation, so there are no user-visible consequences). Just delay rate control initialization to the moment, when rateset tables are initiaziled; nothing will use rates here anyway. MFC after: 4 days net80211: fix duplicate sequence number bump for non-AMPDU QoS frames. This should be a part of r312972. MFC after: 4 days net80211: fix panic when device is removed during initialization if_dead() is called during device detach - check if interface is still exists before trying to refresh vap MAC address (IF_LLADDR will trigger page fault otherwise). MFC after: 5 days net80211: fix possible panic for some drivers after r342211 Check if rate control structures were allocated before trying to access them in various places; this was possible before on allocation failure (unlikely), but was revealed after r342211 where allocation was deferred. In case if driver uses wlan_amrr(4) and it is loaded it is possible to reproduce the panic via sysctl net.wlan.<number>.rate_stats (for wlan0 the number will be 0). Tested with: RTL8188EE, AP mode + RTL8188CUS, STA mode. MFC after: 3 days net80211: provide rate validation for injected frames. There may be various side effects (device timeout, firmware and / or kernel panic) when an invalid (or inapplicable - e.g., an MCS rate for 11g-only device) is set; check rates before sending the frame to the driver. How-to-reproduce: Set an MCS (real or bogus - with 0x80 bit set) rate in ibp_rate0 field for any device that uses ieee80211_isratevalid() for rate checks - rum(4), run(4), ural(4), bwi(4) or ral(4); if kernel is compiled with INVARIANTS the check will result in "rate %d is basic/mcs?" panic. Tested with WUSB54GC (rum(4)), AP mode. MFC after: 1 week Print more WPS attributes in verbose "list scan" output - Move WPS related defines to dedicated file - Add handlers for more WPS attributes PR: 217317 Submitted by: J.R. Oldroyd <fbsd@opal.com> MFC after: 3 weeks net80211: resolve ioctl <-> detach race for ieee80211com structure Since r287197 ieee80211com is a part of drivers softc; as a result, after detach all pointers to it (iv_ic, ni_ic) are invalid. Most possible users (tasks, interrupt handlers) are blocked / removed when device is stopped; however, ioctl handlers were not tracked and may crash if ieee80211com structure is accessed. Since ieee80211com pointer access from ieee80211vap structure is not protected by lock (constant after interface creation) and used in many other places just use reference counting for ioctl handlers; on detach set 'detached' flag and wait until reference counter goes to 0. For HEAD ieee80211vap size was changed (__FreeBSD_version bumped); however, in stable branches I'm going to split / reuse the last iv_spare field for KBI stability. Tested with: - rsu(4), SIOCSIFCAP (-rxcsum) ioctl; - rtwn_pci(4), SIOCG80211 / IEEE80211_IOC_HTPROTMODE ioctl. MFC after: 1 week net80211: fix channel list construction for non-auto operating mode. Change the way how channel list mode <-> desired mode match is done: - Match channel list mode for next non-auto desired modes: * 11b: 11g, 11ng, 11acg; * 11a: 11na, 11ac - Add pre-defined channels only when one of the next conditions met: * the desired channel mode is 'auto' or * the desired channel and selected channel list modes are exactly the same or * the previous rule (11g / 11n / 11ac promotion) applies. Before r275875 construction work properly for all except 11ng / 11na / 11acg / 11ac modes - these were broken at all (i.e., the scan list was empty); after r275875 all checks were removed, so scan table was populated by all device-compatible channels (desired mode was ignored). For example, if I will set 'ifconfig wlan0 mode 11ng' for RTL8821AU: - pre-r275875: nothing, scan will not work; - after r275875: both 11ng and 11na bands were scanned; also, since 11b channel list was used, 14th channel was scanned too. - after this change: only 11ng - 1-13 channels - are used for scanning. Tested with: * RTL8188EE, STA mode. * RTL8821AU, STA mode. MFC after: 5 days net80211: turn channel mode check into assertion. There is may be only 11b channel (since chanflags[] table maps MODE_AUTO to the corresponding 11b channel flags). Checked with RTL8812AU, STA mode. MFC after: 5 days net80211: reuse TICKS_2_MSEC / MSEC_2_TICKS macros from sys/time.h Replace in-place implementation with system-wide one; since it guarantees non-zero result drop all less-than-one checks from drivers and net80211. MFC after: 2 weeks Remove 2GHz channel list copies from wireless drivers. Wrap ieee80211_add_channel_list_2ghz into another function which supplies default (1-14) channel list to it and drop its copies from drivers. Checked with RTL8188EE, country US / JP / KR / UA. MFC after: 2 weeks Do not acquire IEEE80211_LOCK twice in cac_timeout(); reuse locked function instead. It is externally visible since r257065. MFC after: 5 days net80211(4): do not setup roaming parameters for unsupported modes. ifconfig(8) prints per-mode parameters if they are non-zero; since we have 13 possible modes with 3...5 typically supported this change should greatly reduce amount of information for 'ifconfig <wlan> list roam' command. While here ensure that sta_roam_check() will not use roaming parameters for unsupported modes (it should not). This change effectively reverts r188776. MFC after: 2 weeks net80211(4): fix rate check when 'roaming' ifconfig(8) option is set to 'auto' Do not try to clear 'basic rate' bit from roamRate; it cannot be here and, actually, this operation clears 'MCS rate' bit instead, breaking comparison for 11n / 11ac modes. Tested with RTL8188CUS, HOSTAP mode + RTL8821AU, STA mode. MFC after: 3 days net80211(4): do not setup Tx parameters for unsupported modes. That should shorten 'ifconfig <wlan> list txparam' output since unsupported modes will not be shown. Checked with RTL8188EE, STA mode. MFC after: 2 weeks net80211(4): validate supplied roam:rate values from ifconfig(8) MFC after: 4 days net80211(4): hide casts for 'i_seq' field offset calculation inside ieee80211_getqos() and reuse it in various places. Checked with RTL8188EE, HOSTAP mode + RTL8188CUS, STA mode. MFC after: 2 weeks Build fix for Haiku net80211: correct check for SMPS node flags updates Update node flags when driver supports SMPS, not when it is disabled or in dynamic mode ((iv_htcaps & HTCAP_SMPS) != 0). Checked with RTL8188EE (1T1R), STA mode - 'smps' word should disappear from 'ifconfig wlan0' output. MFC after: 2 weeks Enhance the comment ieee80211_add_channel() to avoid a misunderstanding that the function does not work additive when repeatedly called for diffferent bands. Reviewed by: avos (a few months ago) MFC after: 2 weeks net80211: Move rate printing in amrr_node_stats() to a separate method This makes amrr_node_stats() cleaner and allows the rate printing to be reusable. Submitted by: Neel Chauhan <neel at neelc.org> Reviewed by: adrian Differential Revision: https://reviews.freebsd.org/D22318 Mark more nodes as CTLFLAG_MPSAFE or CTLFLAG_NEEDGIANT (7 of many) r357614 added CTLFLAG_NEEDGIANT to make it easier to find nodes that are still not MPSAFE (or already are but aren’t properly marked). Use it in preparation for a general review of all nodes. This is non-functional change that adds annotations to SYSCTL_NODE and SYSCTL_PROC nodes using one of the soon-to-be-required flags. Mark all low hanging fruits as MPSAFE. Reviewed by: markj Approved by: kib (mentor, blanket) Differential Revision: https://reviews.freebsd.org/D23626 Haiku: added CTLFLAG_NEEDGIANT Fix -Wvoid-pointer-to-enum-cast warnings. This pattern is used in callbacks with void * data arguments and seems both relatively uncommon and relatively harmless. Silence the warning by casting through uintptr_t. This warning is on by default in Clang 11. Reviewed by: arichardson Obtained from: CheriBSD (partial) MFC after: 1 week Sponsored by: DARPA Differential Revision: https://reviews.freebsd.org/D24425 Don't indirect user pointers directly in two 802.11s ioctls. IEEE80211_MESH_RTCMD_ADD was invoking memcmp() to validate the supplied address directly on the user pointer rather than first doing a copyin() and validating the copied value. IEEE80211_MESH_RTCMD_DELETE was passing the user pointer directly to ieee80211_mesh_rt_del() rather than copying the user buffer into a temporary kernel buffer. Reviewed by: brooks, kib Obtained from: CheriBSD MFC after: 2 weeks Sponsored by: DARPA Differential Revision: https://reviews.freebsd.org/D24562 Use the unicast key when transmitting DWDS AP multicast frames. I'm still not sure whether this is the full solution, but here goes. I have a two node DWDS setup - a main AP with the ethernet bridge uplink and a satellite AP in the back of the house. They're both AR9344+AR9580 dual band 11n APs. The problem was that multicast frames was not going from the DWDS AP to the DWDS STA. Unicast frames are fine, and multicast frames from the DWDS STA to AP are fine. Now, multicast and unicast frames from the STA -> AP are just transmitted using the unicast key. That's fine. However, the AP -> STA multicast frames by default are transmitted using the current default / multicast key, the shared one between all STAs in a BSS. Now, the DWDS implementation ignores non WDS frames - it only allows about 4 address frames outside of management / EAPOL frames! - so the STA side ignores the normal multicast frames. Instead, the AP side uses ieee80211_dwds_mcast() to send multicast frames to each WDS VAP that was created as part of the "dynamic" part of DWDS. This should be queuing them individually to each node instead of using the normal multicast send path; and this is how they should get turned into 4-addr WDS frames. HOWEVER, ieee80211_encap() was trying to use the default TX key to queue them rather than the unicast key that's already setup. Since this synthetic node doesn't have the default TX key setup, transmission fails. Things would be fine in WEP and in open mode because in both cases you would have static keys (or no keys) setup. It just fails in WPA mode. This resolves the issue. AP DWDS multicast is now sent using the unicast key just like in STA mode and I'm pretty sure the STA mode side will stil work fine (as it's a STA VAP with a DWDS flag..) Tested: * TL-WDR3600/4300 APs net80211: post RTM_IFINFO notification after toggling IFF_DRV_RUNNING This is useful when a wireless driver is stopped or started in response to events like an RF Kill button press. Applications like wpa_supplicant depend on such events to have a correct view of interface state. Reviewed by: adrian, cy, melifaro MFC after: 1 week Differential Revision: https://reviews.freebsd.org/D24925 Fix interrupted scan logic and ticks comparison The scan task refactoring stuff circa 2014-2016 broke the blocking task into a taskqueue with some async bits, but it apparently broke scans being interrupted by traffic. Notably - the new "field" SCAN_PAUSE sets both SCAN_INTERRUPT and SCAN_CANCEL, and a bunch of existing code was checking for SCAN_CANCEL only and breaking the scan. Unfortunately it was then (a) cancelling the scan entirely and (b) not notifying userland that scan was done. So: * Update the calls to scan_end() to only pass in 1 (saying the scan is complete) if SCAN_CANCEL is set WITHOUT SCAN_INTERRUPT. If both are set then yes, the scan is interrupted, but it isn't canceled - it's just paused. * Update the "did the scan flags change whilst the driver was called" logic to check for canceled scans, not interrupted scans. * The "scan done" logic now explicitly checks for either interrupted or completed scans. This accounts for the situation where a scan is being aborted via traffic but it ALSO happens to have finished (ie the last channel was checked.) This doesn't ENTIRELY fix scanning as the resume function is broken due to incorrect ticks math. Thus, the second half of this patch changes the ieee80211_ticks_*() macros to use int instead of long, matching the logic that the TCP code does with ticks and handles wrapping / negative ticks values. If cast to long then the wrapping math wouldn't work right (ie, if ticks was actually negative, ie, after the system has been up for a while.) This allows contbgscan() to correctly calculate if a scan should continue based on ticks and ic->ic_lastdata . Reviewed by: bz Differential Revision: https://reviews.freebsd.org/D25031 Send a probe request after IBSS node discovery This sends a probe request after IBSS node discovery through beacon frames. This allows things like HT and VHT capabilities to be "negotiated" in adhoc mode. It is .. kinda fire and pray - this isn't retried after discovery so it's quite possible that nodes occasionally don't come up with HT/VHT rate upgrades. At some point it may be a fun side project to add support for retrying these probe requests/negotiations after IBSS node discovery. Tested: * tested with multiple ath(4) NICs in 11n mode. Differential Revision: https://reviews.freebsd.org/D24979 Add some more debugging during scanning I'm trying to chase down more weird "I am not doing an incremental scan when being asked" issues so these debugging statements help. Notably, I've added more debugging around reasons why the scan is skipped - eg because the cache is considered hot. This should be a no-op unless you care about the debugging output! Add field definition for A-MSDU inside A-MPDU. Now that I have A-MSDU and A-MPDU coexisting together, we need to actually announce if (a) it's permitted and (b) figure out if we should use it when transmitting. This just adds the field; it doesn't yet include it in ADDBA exchanges. Add some TODOs around A-MSDU in A-MPDU negotiation. net80211 currently doesn't negotiate A-MSDU in A-MPDU during ADDBA. I've added the field in net80211 and this commit: * Prints out the ADDBA field value during ADDBA; * Adds some comments around where I need to follow up with some negotiation logic. Right now we don't have a driver flag anywhere which controls whether A-MSDU in A-MPDU is allowed. I know it works (I have it manually turned on at home on a couple test APs, heh!) but I can't flip it on until we can negotiate it. Tested: * AR9380, STA/AP mode, printing out ADDBA requests Migrate short slot time configuration into per-vap and deferred taskqueue updates. The 11b/11g ERP and slot time update handling are two things which weren't migrated into the per-VAP state when Sam did the initial VAP work. That makes sense for a lot of setups where net80211 is driving radio state and the radio only cares about the shared state. However, as noted by a now deleted comment, the ERP and slot time updates aren't EXACTLY correct/accurate - they only take into account the most RECENTLY created VAP, and the state updates when one creates/destroys VAPs isn't exactly great. So: * track the short slot logic per VAP; * whenever the slot time configuration changes, just push it into a deferred task queue update so drivers don't have to serialise it themselves; * if a driver registers a per-VAP slot time handler then it'll just get the per VAP one; * .. if a driver registers a global one then the legacy behaviour is maintained - a single slot time is calculated and pushed out. Note that the calculated slot time is better than the existing logic - if ANY of the VAPs require long slot then it's disabled for all VAPs rather than whatever the last configured VAP did. Now, this isn't entirely complete - the rest of ERP tracking around short/long slot capable station tracking needs to be converted into per-VAP, as well as the preamble/barker flags. Luckily those also can be done in a similar fashion - keep per-VAP counters/flags and unify them before doing the driver update. I'll defer that work until later. All the existing drivers can keep doing what they're doing with the global slot time flags as that is maintained. One driver (iwi) used the per-VAP flags instead of the ic flags, so now that driver will work properly. This unblocks some ath10k porting work as the firmware takes the slot time configuration per-VAP rather than globally, and some firmware handles STA+AP and STA+STA (on same/different channels) configurations where the firmware will switch slot time as appropriate. Tested: * AR9380, STA/AP mode * AR9880 (ath10k), STA mode Add initial A-MSDU in A-MPDU negotation support. This is hopefully a big no-op unless you're running some extra patches to flip on A-MSDU options in a driver. 802.11n supports sending A-MSDU in A-MPDU. That lets you do things like pack small frames into an A-MSDU and stuff /those/ into an A-MPDU. It allows for much more efficient airtime because you're not wasting time sending small frames - which is still a problem when doing A-MPDU as there's still per-frame overhead and minimum A-MPDU density requirements. It, however, is optional for 802.11n. A lot of stuff doesn't advertise it (but does it, just wait!); and I know that ath10k does it and my ath(4) driver work supports it. Now, 802.11ac makes A-MSDU in A-MPDU something that can happen more frequently, because even though you can send very large A-MPDUs (like 1 megabyte and larger) you still have the small frame problem. So, 802.11ac NICs like ath10k and iwm will support A-MSDU in A-MPDU out of the box if it's enabled - and you can negotiate it. So, let's lay down the ground work to enable A-MSDU in A-MPDU. This will allow hardware like iwn(4) and ath(4) which supports software A-MSDU but hardware A-MPDU to be more efficient. Drivers that support A-MSDU in A-MPDU will set TX/RX htcap flags. Note this is separate from the software A-MSDU encap path; /that/ dictates whether net80211 is doing A-MSDU encapsulation or not. These HTC flags control negotiation, NOT encapsulation. Once this negotiation and driver bits are done, hardware like rtwn(4), run(4), and others will be able to use A-MSDU even without A-MPDU working; right now FF and A-MSDU aren't even attempted if you're an 11n node. It's a small hold-over from the initial A-MPDU work and I know how to fix it, but to flip it on properly I need to be able to negotiate or ignore A-MSDU in A-MPDU. Oh and the fun part - some 11ac APs I've tested will quite happily decap A-MSDU in A-MPDU even though they don't negotiate it when doing 802.11n. So hey, I know it works - I just want to properly handle things. :-) Tested: * AR9380, STA/AP mode print out node A-MSDU state. Now that the node AMSDU TX/RX flags are correctly set in ieee80211_ht.c, we can print out the AMSDU state here. Don't call ic_updateslot if it's not set. Turns out this isn't a required call. I didn't pick it up because my uncommitted changes involve new updateslot methods for cards I'm working on. Dunce hat to: adrian Fix typo. Oops! Fix this typo! I've just started using this macro in upcoming amsdu/ampdu/ff rework and yes, too many parens. Oops! Flip on A-MPDU, A-MSDU, A-MPDU+A-MSDU and Fast frames options. This updates the logic to allow: * A-MPDU if available; * A-MSDU if available and A-MPDU is off/NACKed; * A-MPDU+A-MSDU if it's available and negotiated; * Fast frames if the node is 11abg (and not HT/VHT.) This allows for things to fail back to A-MSDU or fast frames if A-MPDU isn't available rather than needing to be non-HT/non-VHT. It also allows A-MPDU+A-MSDU to work if it's negotiated. Tested: * AR9380, STA + AP mode (A-MPDU, A-MSDU, FF, A-MPDU+A-MSDU) * RT5350, STA mode (A-MSDU, FF) * AR9170, STA mode (A-MSDU, FF) Add a method to return the vap's ifname. This removes the requirement to know what's in the ifp. (If someone wants a quick clean-up task, it'd be nice to convert instances of ifp dereferencing for if_xname over to this method.) ok ok if_xname won't ever be NULL. Somewhere in net80211 if_xname is checked against NULL but it doesn't trigger a compiler warning, but this does. So DTRT for FreeBSD and the other if_xname derefences can be converted to this function at a later time. First part of A-MSDU offload handling - don't bump A-MPDU reordering seqno When doing A-MSDU offload handling the driver is required to mark A-MSDUs from the same MPDU with the same sequence number. It then tags them as AMSDU (if it's a decap'ed A-MSDU) and AMSDU_MORE (saying there's more AMSDUs decapped in the same MSDU.) This allows encryption and sequence number offload to work right. In the A-MSDU path the sequence number check looks at the A-MSDU flags in the frame to see whether it's part of the same seqno and will pass them (ie, not increment rx_seq until the last A-MSDU is seen from the driver, or a new seqno shows up.0 However, I did this work in the A-MSDU path but not the A-MSDU in A-MPDU path. For the non A-MDSU offload case the A-MPDU receive reordering will do its thing and then pass up the MPDU up for decap - which then will see it's an A-MSDU and decap each sub-frame. But this isn't done for offloaded A-MSDU frames. This requires two parts: * Don't bump the RX sequence number, same as above; and * If frames go into the reordering buffer, they need to be added into the slot as a set of frames rather than a single frame, so once a new seqno shows up this slot can be marked as "full" and we can move on. This patch does the first. The latter requires that I find and commit work to change rxa_m from an mbuf to an mbufq and the nhandle A-MSDU there. But, the first is enough to allow the normal case (ie, no or not a lot of A-MPDU RX reordering) to work. This allows the athp driver (QCA9880) throughput to go from VERY low (like 5mbit TCP, 1/3-1/4 expected UDP throughput) to ~ 250mbit TCP and > 300mbit UDP on a VHT/40 channel. TCP sucks because, well, it shows up as MASSIVE packet loss when all but one frame in a decap'ed A-MSDU stream is dropped. Le whoops. Now, where'd I put that laptop with the patch for rxa_m mbufq that I wrote like in 2017... Tested: * AR9380, STA/AP mode (a big no-op, no A-MSDU hardware decap); * if_run (RT3593), STA DWDS mode (A-MPDU / A-MSDU receive, but again no A-MSDU hardware decap); * QCA9880, STA/AP mode (which is doing hardware A-MPDU/A-MSDU decap, but no A-MPDU reordering in the firmware.) net80211: Add framework for debugnet(4) support Allow net80211 drivers to register a small vtable of debugnet-related methods. This is not a functional change. Driver support is needed, similar to debugnet(4) for wired NICs. Reviewed by: adrian, markj (earlier version both) Differential Revision: https://reviews.freebsd.org/D17308 separate out node allocation and node initialisation. This is a new, optional (for now!) method that drivers can use to separate node allocation and node initialisation. Right now they're the same, and drivers that need to do node allocation via firmware commands need to sleep and thus they need to defer node allocation into an internal taskqueue. Right now they're just separate but not deferred. Later on if I get the time we'll start deferring the node and key related operations but that requires making a bunch of other stuff (notably things that generate frames!) also async/deferred. Tested: * RT3593, STA/DWDS mode * AR9380, STA/AP modes * QCA9880 (athp) - STA/AP modes Handle offloaded AMSDU in AMPDU reordering. In the 11n world, most NICs did A-MPDU receive/transmit offloading but not A-MSDU offloading. So, the net80211 A-MPDU receive path would just receive MPDUs, do the reordering bit, pass it up to the rest of net80211 for crypto decap and then do A-MSDU decap before throwing ethernet frames up to the rest of the system. However 11ac and 11ax NICs are increasingly doing A-MSDU offload (and newer 11ax stuff does socket offload, but hey I don't want to scare people JUST yet) - so although A-MPDU reordering may be done in the OS, A-MSDUs look like a normal MPDU. This means that all the MSDUs are actually faked into a set of MPDUs with matching 802.11 header - the sequence number, QoS header and any encryption verification bits (like IV) are just copied. This shows up as MASSIVE packet loss in net80211, cause after the first MPDU we just toss the rest. (And don't get me started about ethernet decap with A-MPDU host reordering; we'll have to cross that bridge for later 11ac and 11ax bits too.) Anyway, this work changes each A-MPDU reorder slot into an mbufq. The mbufq is treated as a whole set of frames to pass up to the stack and reordered/de-duped as a group. The last frame in the reorder list is checked to see if it's an A-MSDU final frame so any duplicates are correctly tossed rather than double-received. Other than that, the rest of the logic is unchanged. The previous commit did a small subset of this - if there wasn't any reordering going on then it'd accept the A-MSDUs. This is the rest of the needed work. This is a no-op for 11n NICs doing A-MPDU reordering but needing software A-MSDU decap - they aren't tagged as A-MSDU and so any subsequent frames added to the reorder slot are tossed. Tested: * QCA9880 (ath10k/athp) - STA/AP mode; * RT3593 (if_rsu) - 11n STA+DWDS mode (I'm committing through it rn); * QCA9380 (if_ath) - STA/AP mode. Also convert the ddb path Whoops - this belonged in my previous commit. add a concat method. Reviewed by: gnn, ae, glebius Approved by: ae, glebius Differential Revision: https://reviews.freebsd.org/D10158 Treat frames without an rx status as not a decap'ed A-MSDU. Drivers for NICs which do A-MSDU decap in hardware / driver will need to set the rx status, so if it's missing then treat it as not a decap'ed A-MSDU. Add initial U-APSD negotiation support. U-APSD (unscheduled automatic power save delivery) is a power save method that's a bit better than legacy PS-POLL - stations can mark frames with an extra flag that tells the AP to leak out more frames after it sends its own frames rather than needing to send a PS-POLL to get another frame from the AP. Now, this code just handles the negotiation bits; it doesn't actually implement U-APSD. That's up to drivers, and nothing in the tree yet implements this. I /may/ implement this for ath(4) if I eventually care enough but right now I plan on just implementing it for firmware offload based NICs that handle this in the NIC. I'll commit the ifconfig bit after this and I may have some follow-up commits as this gets used more by me in local testing. This should be a glorious no-op for everyone else. If things change for anyone that isn't fixed by a complete recompile then please reach out to me. Add missing commit to previous-1 uapsd commit. Whoops; somehow my big commit line didn't include this.. cue the tree breakage emails. Migrate HT/legacy protection mode and preamble calculation to per-VAP flags The later firmware devices (including iwn!) support multiple configuration contexts for a lot of things, leaving it up to the firmware to decide which channel and vap is active. This allows for things like off-channel p2p sta/ap operation and other weird things. However, net80211 is still focused on a "net80211 drives all" when it comes to driving the NIC, and as part of this history a lot of these options are global and not per-VAP. This is fine when net80211 drives things and all VAPs share a single channel - these parameters importantly really reflect the state of the channel! - but it will increasingly be not fine when we start supporting more weird configurations and more recent NICs. Yeah, recent like iwn/iwm. Anyway - so, migrate all of the HT protection, legacy protection and preamble stuff to be per-VAP. The global flags are still there; they're now calculated in a deferred taskqueue that mirrors the old behaviour. Firmware based drivers which have per-VAP configuration of these parameters can now just listen to the per-VAP options. What do I mean by per-channel? Well, the above configuration parameters really are about interoperation with other devices on the same channel. Eg, HT protection mode will flip to legacy/mixed if it hears ANY BSS that supports non-HT stations or indicates it has non-HT stations associated. So, these flags really should be per-channel rather than per-VAP, and then for things like "do i need short preamble or long preamble?" turn into a "do I need it for this current operating channel". Then any VAP using it can query the channel that it's on, reflecting the real required state. This patch does none of the above paragraph just yet. I'm also cheating a bit - I'm currently not using separate taskqueues for the beacon updates and the per-VAP configuration updates. I can always further split it later if I need to but I didn't think it was SUPER important here. So: * Create vap taskqueue entries for ERP/protection, HT protection and short/long preamble; * Migrate the HT station count, short/long slot station count, etc - into per-VAP variables rather than global; * Fix a bug with my WME work from a while ago which made it per-VAP - do the WME beacon update /after/ the WME update taskqueue runs, not before; * Any time the HT protmode configuration changes or the ERP protection mode config changes - schedule the task, which will call the driver without the net80211 lock held and all correctly serialised; * Use the global flags for beacon IEs and VAP flags for probe responses and other IE situations. The primary consumer of this is ath10k. iwn could use it when sending RXON, but we don't support IBSS or AP modes on it yet, and I'm not yet sure whether it's required in STA mode (ie whether the firmware parses beacons to change protection mode or whether we need to.) Tested: * AR9280, STA/AP * AR9380, DWDS STA+STA/AP * ath10k work, STA/AP * Intel 6235, STA * Various rtwn / run NICs, DWDS STA and STA configurations Commit files missing in the previous commit These belong to my previous commit, but apparently I typed ieee80211_vhf.[ch] and forgot ht.h. Le oops. 80211: consistently spell 80P80 The standard uses 80+80 and 80p80 but nowhere 80_80. Switch the latter to 80P80 for all the macros and comments refering to #defined flags which I could find. The only place we leave as 80p80 is the ifconfig command line arguments as we spell them all in lower case. Ideally we would use 80+80 for any interactions with the user and 80P80 for anything internal but let us not confuse parsers and hence avoid the '+' in either case. Reviewed by: adrian, gnn MFC after: 2 weeks Sponsored by: Rubicon Communications, LLC (d/b/a "Netgate") Differential Revision: https://reviews.freebsd.org/D26001 80211: consistently order 160 and 80+80 For flags and checks the order goes VHT160 and then VHT80P80 unless checks are in reverse order ("more comes first") in which case we deal with VHT80P80 first. The one reverse order to pick out is where we check channel prefernences. While it may seem that VHT160 is better, finding two "free" channels (VHT 80+80) is more likely so we do prefer that. While dealing with VHT160 and VHT80P80 add extra clauses previously missing or marked TODO in a few places. Reviewed by: adrian, gnn MFC after: 2 weeks Sponsored by: Rubicon Communications, LLC (d/b/a "Netgate") Differential Revision: https://reviews.freebsd.org/D26002 net80211: remove vertical whitespace No functional changes. MFC after: 2 weeks Sponsored by: Rubicon Communications, LLC (d/b/a "Netgate") net80211/ifconfig: print hardware device name for wlan interfaces Add IEEE80211_IOC_IC_NAME to query the ic_name field and in ifconfig to print the parent interface again. This functionality was lost around r287197. It helps in case of multiple wlan interfaces and multiple underlying hardware devices to keep track which wlan interface belongs to which physical device. Sponsored by: Rubicon Communications, LLC (d/b/a "Netgate") Reviewed by: adrian, Idwer Vollering MFC after: 2 weeks Differential Revision: https://reviews.freebsd.org/D25832 net80211 / ifconfig: cleanup the use of IEEE80211_FVHT_USEVHT* Rather then using magic numbers duplicate IEEE80211_FVHT_VHT* in ifconfig (cleanup of these and other flags used and not exposed by net80211 should happen later) and use those. In the kernel this simplifies one ioctl path (the other one currently relies on individual bit flags being passed in). We also re-order the 80P80 and 160 flag for 160 to come before 80+80 and more clearly leave the flags as TODO in one of the 160/80+80 cases. Reviewed by: adrian MFC after: 2 weeks Sponsored by: Rubicon Communications, LLC (d/b/a "Netgate") Differential Revision: https://reviews.freebsd.org/D26000 net80211: return 80P80 before 160 In ieee80211_vht_get_chwidth_ie() we need to return 80P80 (3) before VHT160 (2) as otherwise we'll never use 80P80. Fix the order. MFC after: 2 weeks X-MFC with: r364303 (which missed this) Sponsored by: Rubicon Communications, LLC (d/b/a "Netgate") net80211: VHT correct NSS Set loop boundary For the <VHT-MCS, NSS> tuple, NSS is 1..8 (or in our loop case 0..7 but not 0..6). Correct the boundry to check for < 8 and not < 7. MFC after: 2 weeks Reviewed by: adrian Sponsored by: Rubicon Communications, LLC (d/b/a "Netgate") Differential Revision: https://reviews.freebsd.org/D26087 net80211: replace magic number by define Rather than coding an array size of [4] replace the number with WME_NUM_AC. MFC after: 2 weeks Reviewed by: adrian Sponsored by: Rubicon Communications, LLC (d/b/a "Netgate") Differential Revision: https://reviews.freebsd.org/D26090 net80211: set_vht_extchan() reverse order to always return best In set_vht_extchan() the checks are performed in the order of VHT20/40/80. That means if a channel has a lower and higheer VHT flag set we would return the lower first. We normally do not set more than one VHT flag so this change is supposed to be a NOP but follows the logical thinking order of returning the best first. Also we nowhere assert a single VHT flag so make sure we'll not be stuck with VHT20 when we could do more. While here add the debugging printfs for VHT160 and VHT80P80 which still need doing once we deal with a driver at that level. Reviewed by: adrian, gnn MFC after: 2 weeks Sponsored by: Rubicon Communications, LLC (d/b/a "Netgate") Differential Revision: https://reviews.freebsd.org/D26088 net80211: improve media information for VHT5GHZ Improve ieee80211_media_setup(), media2mode(), and ieee80211_rate2media() for VHT5GHZ at least. Reviewed by: adrian, gnn MFC after: 2 weeks Sponsored by: Rubicon Communications, LLC (d/b/a "Netgate") Differential Revision: https://reviews.freebsd.org/D26089 net80211: enhance getflags*() and ieee80211_add_channel*() For ieee80211_add_channel+*() we are passing in an int flag for ht40 and in some cases another int flag for vht80 where we'd only need two bits really. Convert these variables to a bitflag and fold them together into one. This also allows for VHT160 and VHT80P80 and whatever may come to be considered. Define the various options currently needed. Change the drivers (rtwn and rsu) which actually set this bit to non-0. For convenience the "1" currently used for HT40 is preserved. Enahnce getflags_5ghz() to handle the full set of VHT flags based on the input flags from the the driver. Update the regdomain implementation as well to make use of the new flags and deal with higher [V]HT bandwidths. ieee80211_add_channel() specifically did not take flags so it will not support naything beyond 20Mhz channels. Note: I am not entirely happy with the "cbw_flag[s]" name, but we do use chan_flags elsewhere already. MFC after: 2 weeks Reviewed by: adrian, gnn Sponsored by: Rubicon Communications, LLC (d/b/a "Netgate") Differential revision: https://reviews.freebsd.org/D26091 net: clean up empty lines in .c and .h files Provide MS() and SM() macros for 80211 and wireless drivers. We have (two versions) of MS() and SM() macros which we use throughout the wireless code. Change all but three places (ath_hal, rtwn, and rsu) to the newly provided _IEEE80211_MASKSHIFT() and _IEEE80211_SHIFTMASK() macros. Also change one internal case using both _S and _M instead of just _S away from _M (one of the reasons rtwn and rsu were not changed). This was done semi-mechanically. No functional changes intended. Requested by: gnn (D26091) Reviewed by: adrian (pre line wrap) MFC after: 2 weeks Sponsored by: Rubicon Communications, LLC (d/b/a "Netgate") Differential Revision: https://reviews.freebsd.org/D26539 80211: non-functional changes Sort a few VHT160 and 80+80 lines, update some comments, and remove a superfluous ','. No functional changes intended. MFC after: 1 week Sponsored by: The FreeBSD Foundation net80211: whitespace Fix indentation for the multi-line copies of ieee80211_add_channel_list_5ghz() for the 3 bands. MFC after: 1 week Sponsored by: The FreeBSD Foundation net80211: update for (more) VHT160 support Implement two macros IEEE80211_VHTCAP_SUPP_CHAN_WIDTH_IS_160MHZ() and its 80+80 counter part to check in vhtcaps for appropriate levels of support and use the macros throughout the code. Add vht160_chan_ranges/is_vht160_valid_freq and handle analogue to vht80 in various parts of the code. Add ieee80211_add_channel_cbw() which also takes the CBW flag fields and make the former ieee80211_add_channel() a wrapper to it. With the CBW flags we can add HT/VHT channels passing them to getflags() for the 2/5ghz functions. In ifconfig(8) add the regdomain_addchans() support for VHT160 and VHT80P80. With this (+ regdoain.xml updates) VHT160 channels can be configured, listed, and pass regdomain where appropriate. Tested with: iwlwifi Reviewed by: adrian MFC after: 10 days Sponsored by: The FreeBSD Foundation Differential Revision: https://reviews.freebsd.org/D26712 net80211: fix a typo Correct a typo referring to the wrong flags in a comment. No functional changes. MFC after: 3 days Sponsored by: Rubicon Communications, LLC (d/b/a "Netgate") Add new privileges; restrict what can be done in a jail. Split the MANAGE privilege into MANAGE, SETMAC and CREATE_VAP. + VAP_MANAGE is everything but setting the MAC and creating a VAP. + VAP_SETMAC is setting the MAC address of the VAP. Typically you wouldn't want the jail to be able to modify this. + CREATE_VAP is to create a new VAP. Again, you don't want to be doing this in a jail, but this DOES stop being able to run some corner cases like Dynamic WDS (DWDS) AP in a jail/vnet. We can figure this bit out later. This allows me to run wpa_supplicant in a jail after transferring a STA VAP into it. I unfortunately can't currently set the wlan debugging inside the jail; that would be super useful! Reviewed by: bz Differential Revision: https://reviews.freebsd.org/D25630 net80211: factor out the priv(9) checks into OS specifc code. Factor out the priv(9) checks into OS specifc code so other OSes can equally implement them. This sorts out those XXX in the net80211 code. We provide 3 arguments (cmd, vap, ifp) where available to the functions, in order to allow other OSes to use that data but also in case we'd add auditing to these check to have the information available. For now the arguments are marked __unused. PR: 249403 Reported by: martin(NetBSD) Reviewed by: adrian, martin(NetBSD) MFC after: 10 days Sponsored by: Rubicon Communications, LLC (d/b/a "Netgate") Differential Revision: https://reviews.freebsd.org/D26541 sockio.h: add missing ioctl SIOCSIFLLADDR Change-Id: I68703723ac919b901adb99ca1f7d0319fd0271f5 Reviewed-on: https://review.haiku-os.org/c/haiku/+/3910 Reviewed-by: waddlesplash <waddlesplash@gmail.com> |
||
|
Adrien Destugues
|
3b3bcbf7aa |
Update build packages repository
- Switch to Python3 - Switch to mawk instead of gawk - Update ffmpeg (there are several new dependencies) - Update ICU - Fix various pre-existing problems with packages not being properly declared for gcc2 (but somehow it ended up working) - remove curl, subversion, mercurial Confirmed that both nightly and release images are building fine on both 32 and 64bit. However, non-x86 architecture may require re-bootstrapping to do a complete nightly or release image build (the minimal profile should be fine) Fixes #16751. Change-Id: Iacac92923c4113b3e0a49a64b0b4cc1b8e2f5e2e Reviewed-on: https://review.haiku-os.org/c/haiku/+/3871 Reviewed-by: Adrien Destugues <pulkomandy@gmail.com> |
||
|
Adrien Destugues
|
f203aee66c |
Style fixes.
Pointed out by Axel on Gerrit, I was too fast to merge the commit. |
||
|
Jérôme Duval
|
f1ec69628a |
tcp: several fixes for SACK handling:
* kMaxOptionSize: TCP header size is 60 bytes. process_options() would have accepted a longer header as permitted. add_options() would have possibly added more options or SACK entries as permitted. * tcp_segment: reserve memory for sack entries. * _SendQueued(): "fLastAcknowledgeSent <= fReceiveNext": also send SACK entries for received data when acknowledging a missing segment. * _SendQueue(): after acknowledging, cancel the delayed acknowledgment timer. * _Receive(): if calling Acknowledged() already triggered sending a segment including an acknowledgement (piggy-back), remove "immediate acknowledge" from the action. This helps to reduce empty ACKs for bidirectional streams. Change-Id: I32808fbe549be0f5b25bcf4be17cd91a640b8ec4 Reviewed-on: https://review.haiku-os.org/c/haiku/+/3906 Reviewed-by: Adrien Destugues <pulkomandy@gmail.com> |
||
|
Jérôme Duval
|
a939e873ba |
tcp: fix trace build for BufferQueue
Change-Id: Iab502bdff3da23dff74972e6c480e0784ab3f4dd Reviewed-on: https://review.haiku-os.org/c/haiku/+/3905 Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com> |
||
|
A-star-ayush
|
745830a01b |
tcp: rfc 2018: implemented SACK option
Change-Id: I269ad2682446c4d37bae21dcf9f3036de964ff2c Reviewed-on: https://review.haiku-os.org/c/haiku/+/53 Reviewed-by: Jérôme Duval <jerome.duval@gmail.com> |
||
|
Andriy Gapon
|
a6e1e7e941 |
idualwifi7260: apply iwm commits from FreeBSD 13 except (the EPOCH one)
tested on Wireless 8265 / 8275 [8086:24fd] iwm: improve rfkill handling Previously the driver handled the bit within itself, but did not expose the state change to net80211 and interface layers. This change uses net80211 KPI for rfkill signaling. The code is modeled after similar code in iwn and wpi. Reviewed by: adrian MFC after: 2 weeks Differential Revision: https://reviews.freebsd.org/D24923 WiFi: fix ieee80211_media_change() callers In r178354 with the introduction of multi-bss ("vap") support factoring out started and with r193340 ieee80211_media_change() no longer returned ENETRESET but only 0 or error. As ieee80211(9) tells the ieee80211_media_change() function should not be called directly but is registered with ieee80211_vap_attach() instead. Some drivers have not been fully converted. After fixing the return checking some of these functions were simply wrappers between ieee80211_vap_attach() and ieee80211_media_change(), so remove the extra function, where possible as well. PR: 248955 Submitted by: Tong Zhang (ztong0001 gmail.com) (original) MFC after: 3 days Sponsored by: The FreeBSD Foundation iwm: fix regression from r365419 (ieee80211_media_change()) In r365419 ieee80211_media_change() callers were updated to not longer act on the obselete ENETRESET return code. While in the old days iwm has done a stop/init cycle in these cases, this was not executed since r193340. As a consequence simplify iwm code as well by passing ieee80211_media_change() right to ieee80211_vap_attach() as there is no more need for a local implementation. Reported by: Tomoaki AOKI (junchoon dec.sakura.ne.jp) Tested by: Tomoaki AOKI (junchoon dec.sakura.ne.jp) MFC after: 3 days X-MFC: fix is already in stable/12 PR: 248955 iwm(4): Add support for Intel Killer(R) Wireless-AC 1550i PR: 252578 Submitted by: shu <ankohuu@outlook.com> MFC after: 1 week Change-Id: Ibf9ec28986769bc7532e4c06ea2acafce7a8d86b Reviewed-on: https://review.haiku-os.org/c/haiku/+/3907 Reviewed-by: waddlesplash <waddlesplash@gmail.com> |
||
|
Augustin Cavalier
|
dfc8e52638 |
packagefs and IOCache: don't reread pages when we have them all.
Change-Id: I56a7769e7a2fa9693db7507ffadb01a56cbf42b2 Reviewed-on: https://review.haiku-os.org/c/haiku/+/1342 Reviewed-by: Adrien Destugues <pulkomandy@gmail.com> |
||
|
Murai Takashi
|
1d1b0d4594 |
bin/network/telnetd: Fix multiple definitions
Fix multiple definitions of 'terminaltype' and 'line' when linking. Pointed out by gcc11. Change-Id: I85552e2d243bd5db5f80806d92e6fa87bc41eb44 Reviewed-on: https://review.haiku-os.org/c/haiku/+/3903 Reviewed-by: Jérôme Duval <jerome.duval@gmail.com> |
||
|
Murai Takashi
|
a65f6a2308 |
Accelerants: Fix multiple definitions
Since nv_globals.h and globals.h are included from several files, it cause multiple definitions error when linking. Pointed out by gcc11. Change-Id: I10e27af062c6f4b49fdb9ef6bb3ba77809ebcba0 Reviewed-on: https://review.haiku-os.org/c/haiku/+/3904 Reviewed-by: Adrien Destugues <pulkomandy@gmail.com> |
||
|
Murai Takashi
|
d272f61263 |
cpu.h: Fix size of array element is not a multiple of its alignment
Pointed out by gcc11. Reference: https://bugzilla.redhat.com/show_bug.cgi?id=1937076 Change-Id: Ia76204f759710651340bc09fa6bc163d776b2ab4 Reviewed-on: https://review.haiku-os.org/c/haiku/+/3902 Reviewed-by: Jérôme Duval <jerome.duval@gmail.com> |
||
|
John Scipione
|
aae4fc7974 |
StyledEdit: SetInsets() instead of insetting initial text rect
Initial rect size doesn't persist to changing text rect sizes and alignment changes but insets do. Maintains a 3px border around text on all sides. Change-Id: I70e855c3b6b17bc576fd5e38cd43fedb6c830aef Reviewed-on: https://review.haiku-os.org/c/haiku/+/3901 Reviewed-by: Adrien Destugues <pulkomandy@gmail.com> |
||
|
Autocomitter
|
7584a8e549 | Update translations from Pootle | ||
|
Zoltán Mizsei
|
e7e3b6c14a |
build/cross_tools_gcc4: explicit disable libatomic and libgomp
Change-Id: If8cad96420cd249106c611aaf59353adab1271ee Reviewed-on: https://review.haiku-os.org/c/haiku/+/3897 Reviewed-by: Jérôme Duval <jerome.duval@gmail.com> |
||
|
Alexander von Gluck IV
|
ad284e7acb |
ifconfig: expand 10Gbps media knowledge
* These are pretty much the 10G standards that have any potential for usage on a desktop system. Change-Id: I2cb49f41ca61e82e091d042f877ee2f1acb9c4ec Reviewed-on: https://review.haiku-os.org/c/haiku/+/3900 Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com> Reviewed-by: Adrien Destugues <pulkomandy@gmail.com> |