Requires multiple media server restarts to switch
outputs to it, but that's a known media services
problem (#12777 and #12776.)
Input doesn't work quite right with the hardware
I've been testing with, but that's also a known
problem it seems (#9951). Meanwhile, output
seems to work pretty well, once it gets going.
Since transfer status is reported via the packet descriptors, we
can report the endpoint status through the callback status.
Reduces syslog spam when using the USB audio driver.
This error means that the controller failed to read or write data
to/from system memory fast enough. As a result, we should report it
as READ_ERROR/WRITE_ERROR, rather than something that sounds like
an error with the device itself.
Then, make BABBLE reporting consistent: this is a data overrun/underrun
of the device itself, not the buffers passed to the controller.
This then leaves B_DEV_FIFO_OVERRUN/UNDERRUN unused, and thus usable
for reporting ring overrun/underrun on isochronous transfers.
The API documentation already described DATA_OVERRUN/UNDERRUN basically
like they were babble errors, while FIFO_OVERRUN/UNDERRUN are
currently described as "internal errors" at present. No driver actually
checked for these.
When _InternalIO returns with "bytes" smaller than the
original request, this isn't an error (or something we
should retry), but just something we need to pass on.
Fixes part of #18746. However, even after this commit,
file reads don't work quite right: reading past the end
of a file returns errors instead of just no data.
Otherwise the calling program will think that
no part of the write succeeded, when in fact
it did.
tty_read() already did this correctly. Not sure
how this wasn't uncovered previously.
Fixes#18447.
Some non-layout applications start out with negative
view dimensions. Making them positive too early on can
break the view's appearance, it seems.
Fixes#18690.
* Break segment setup out into its own method.
* Break the actual sending logic out into its own method.
- While at it, remove some old/obsolete comments and
rearrange some of the logic to match.
* Separate the send-pure-ACK and send-data methods.
- This way, the "force" parameters will act differently,
specifying "force" to SendAcknowledge() may generate
a duplicate ACK, while to SendQueued() it will either
send data smaller than a segment size, or do nothing.
Functional changes should be minor, and the code
meanwhile should be much easier to read.
Change-Id: I1e14b9a1e3b7c8b2d3bf8ae30f1369d8c9f662a4
Reviewed-on: https://review.haiku-os.org/c/haiku/+/7361
Reviewed-by: waddlesplash <[email protected]>
* Each packet needs to be its own TD.
* All transfers are scheduled in frames, not microframes.
Combined with a few fixes to the USB audio driver, this seems
to get things working much better than before.
If the route supports a greater MTU, we need to
clamp it.
The loopback reports an MTU greater by one byte
(65536), and if we don't clamp it here, TCP will
try to send packets actually that large (and fail.)
The previous logic would link from the end of the ring to the start,
and the TRB there would always itself be a link TRB. Now, we avoid this
by linking back to the start from within the TD segments, and putting
the "Event Data" TRB there.
May help with some problems.
Change-Id: I92c4e135ee28c8c89646594a99fb40ee0d6c4484
Following the last commit, we can just let if_input
process the whole chain at once.
The logic here may not have been correct, and possibly
caused memory leaks under high-traffic conditions.
May help with #18585 and others.
There was a comment indicating where this happened, but then
there was a use of one of them after this point. Fix that,
and add { } around their use to prevent this from happening again.
Instead, rely on commitment being done later, when the
protections are changed. set_area_protection() already
did just that, but set_memory_protection did not, so
it is implemented here.
Fixes#18733.
Change-Id: Ia58aee93faf1296fce69d723b12d0fa0a8440706
Reviewed-on: https://review.haiku-os.org/c/haiku/+/7339
Reviewed-by: waddlesplash <[email protected]>
Also use the standard kernel-wide constants for IO or memory space
rather than defining new ones, as well as the PCI constants for
address types.
Change-Id: Iad03f7666ad5121a5c9a398339aa1a191339a1d1
Reviewed-on: https://review.haiku-os.org/c/haiku/+/7336
Reviewed-by: waddlesplash <[email protected]>
Upcoming changes will make this method return values in _vnode even
when they return error codes under some conditions. To avoid easily-
caused memory leaks, this commit refactors the output variable to
be VnodePutter&, and all consuming methods to thus make use of Putters.
Should not be a functional change.
Change-Id: Id7b9066f8cd50c159d52c921b16e475e4e1de806
Reviewed-on: https://review.haiku-os.org/c/haiku/+/7301
Reviewed-by: waddlesplash <[email protected]>
Remaining non-uses are mostly in specialized functions that e.g. operate
on many file descriptors at once (like vfs_exec_io_context.)
Reduces "goto"s. Should not have any functional change.
IMMEDIATE_ACKNOWLEDGE invokes SendQueued ... but with
a send window size forced to 0, so it just generates an
ACK (or a duplicate ACK as the case may be), and doesn't
actually trigger sending of data.
So, adjust the check, introduce a new action flag, and
invoke it properly.
Fixes traffic stalls caused by waiting for the
persist timeout to occur.
This amends hrev51540 (yes, from 2017.)
Change-Id: I6344463938cfaa0134bb8cf3e224789cded0987c
Reviewed-on: https://review.haiku-os.org/c/haiku/+/7285
Reviewed-by: waddlesplash <[email protected]>
First, we don't need to generate ACKs for every other
segment received, only every second full-size segment
or within 500ms, as the comment notes. So check the
receive window size before deciding to send an ACK
immediately.
Second, let the timeout routine handle sending the ACK
even in the immediate invocation case. This way, we
don't spend time in receive routines waiting for the
send path locks, and also multiple packets received in
quick succession will have one ACK generated instead of
many.
Also, following the previous commit, the timeout routine
will avoid generating duplicate ACKs now. In the case
where a duplicate ACK really needs to be generated,
DelayedAcknowledge won't be used anyway.
Inspired by ambroff's remarks and patch in
comment:14 of #18203.
Greatly reduces the number of ACKs generated,
and increases throughput due to less duplicate ACKs
causing congestion logic to kick in.
Change-Id: I37991464b1a802aceb3e2b453df8dc4cb2e14ce5
Reviewed-on: https://review.haiku-os.org/c/haiku/+/7284
Reviewed-by: Alex von Gluck IV <[email protected]>
Reviewed-by: waddlesplash <[email protected]>
As the comment already notes, it's possible that we wind up
in the timeout routine despite the timer being cancelled, if
the cancellation was done after execution was in progress.
In either case, do not invoke Send if there is nothing to do,
as invoking Send...(force = true) will generate a duplicate ACK.
Duplicate ACKs will be noticed by the remote end as a sign of
congestion, so we don't want that to happen.
Change-Id: Iac30c140c322ccf0b0477e434459e7674bc24e1a
Reviewed-on: https://review.haiku-os.org/c/haiku/+/7283
Reviewed-by: waddlesplash <[email protected]>
Reviewed-by: Alex von Gluck IV <[email protected]>
A variety of things marked "not implemented" actually are,
at least partially, but the comment was not adjusted.
Change-Id: I760cca8ef3f601d27c0143f7dc75f5049d02f899
Reviewed-on: https://review.haiku-os.org/c/haiku/+/7282
Reviewed-by: waddlesplash <[email protected]>
Reviewed-by: Alex von Gluck IV <[email protected]>
We bypass device logic in datalink_send_routed_data() in the case
of RTF_LOCAL, so if we don't update the stats there, they'll never
get updated. Furthermore, there's places packets can be dropped
inside the device reader thread. So, we might as well consolidate
the stats-updating logic and get it out of drivers.
(The only remaining case where drivers need to update stats is when
they drop a packet in receive(), as the stack can't tell when an error
from receive() is due to a dropped packet or not.)
Fixes a potential leak on packet drops in the device reader thread,
and fixes loopback statistics for TCP/UDP/etc.
We were storing real_time_clock_usecs() but comparing against
BStatable::GetModificationTime() which is just a time_t. The
values were thus displayed wrongly in the "Get Info" window,
but also thumbnails would not have been updated when the file was.
Should fix#18691 and possibly some other tickets.
* Rename the "tun" network device to "tunnel". FreeBSD calls theirs
"tuntap" but speaks of both TUN and TAP devices as interfaces for
tunnels. The other BSDs seem to do likewise.
* Fold the "tun" driver into the "tunnel" network device. The
network device now publishes entries in devfs when interfaces
are created, and unpublishes them when interfaces are destroyed.
This removes the need for the driver and device to communicate
through a file descriptor, and thus allows the receive queue
to be totally eliminated, massively simplifying that logic.
* Use standard net-stack FIFOs instead of TCP BufferQueue, which is
specialized to TCP's needs in far too many ways. Thanks to the
previous commit adding support for interrupting semaphore waits,
we can use the FIFO wait mechanisms, too.
* Restructure the TAP logic, and generate MAC addresses more like
Linux does.
* Actually set type = IFT_TUN, and use the "loopback" frame handler
instead of the "ethernet" frame handler. This allows significant
cleanup of the header handling logic.
* In TUN mode, reject packets that don't look like IP packets.
* Delete "tunconfig"; it was mostly stubs and is now unnecessary.
TUN mode tested and confirmed as working by kallisti5 with OpenVPN.
TAP mode partially tested, but not yet confirmed as working.
Fixes#18673.
Change-Id: Ibd803139474e8db556a4f567901da15ee4083621
Reviewed-on: https://review.haiku-os.org/c/haiku/+/7143
Reviewed-by: Alex von Gluck IV <[email protected]>
Previously, "count" did nothing for B_RELEASE_ALL. Now, if it is
< 0, it will be the error code returned by acquire_sem() of any
waiting threads.
As B_RELEASE_ALL is a Haiku extension, this change should not
cause any compatibility problems that we cannot fix.
This will be useful in implementing some features of TUN/TAP
with network FIFOs.
Change-Id: I2dbccedefac2024fe740b87543ff3b80f5257e20
Reviewed-on: https://review.haiku-os.org/c/haiku/+/7163
Reviewed-by: waddlesplash <[email protected]>
* Reshuffle variable declarations, most are placed much
closer to first usages now.
* Turn a confusingly worded comment into an ASSERT(),
and remove another one that was outdated.
* Fix some minor code style problems.
* Make the copying logic more consistent between first
and then subsequent copies.
* Make it possible for B_BAD_ADDRESS (EFAULT) to be
returned. This is not listed in POSIX, but as per
online sources, at least Linux does do this.
Change-Id: Idcfbed30531c1ab4796c4ee37f7f4ce8078e535b
Reviewed-on: https://review.haiku-os.org/c/haiku/+/7147
Reviewed-by: waddlesplash <[email protected]>
Reviewed-by: Jérôme Duval <[email protected]>
Tested-by: Commit checker robot <[email protected]>
This is a Linux extension (which at least FreeBSD has also
adopted.) It's used in the Haiku port of libpcap (where it's
a necessity) and wpa_supplicant (where it wasn't, and I
removed it.) It seems that we've had it for quite some time.
Fixes tcpdump following addition of flag checks.
GCC2 tolerates [] FLAs in C++ mode but not in C mode, as discovered
when trying to build wpa_supplicant against R1/beta4. A workaround
was added there for now, but this is the more general solution.
These have not been used in years (maybe since the redesign of the
network stack?). Only socket_writev had an implementation, which was
mostly just an incomplete version of socket_send.
Scatter/gather I/O is already supported via msghdr's msg_iov/len fields,
so this is redundant anyway.
Change-Id: If41c4f4ee021856f6db49c7cb95422a9c1aa7700
Reviewed-on: https://review.haiku-os.org/c/haiku/+/7127
Reviewed-by: waddlesplash <[email protected]>
Tested-by: Commit checker robot <[email protected]>
Reviewed-by: Adrien Destugues <[email protected]>
Reviewed-by: Jérôme Duval <[email protected]>
They only described things that the function names and parameters
already indicated. As per the Coding Guidelines, such excessive
commenting is to be removed.
Also fix some other (minor) code style issues while at it.
"LGTM" code scanning was bought out and merged into GitHub Actions.
The code scanning setup there has a different mechanism for configuration,
and so this file is not useful anymore.
The filesystem name returned by read_fs_info will be correct (i.e.
returning "ext3" or "ext4" as appropriate), but some things just list
the filesystem driver's name, which can cause confusion.
Change-Id: Ic4acf497fc5db5c167131aeb323b45eeb78594d6
Reviewed-on: https://review.haiku-os.org/c/haiku/+/7126
Reviewed-by: waddlesplash <[email protected]>
Reviewed-by: Jérôme Duval <[email protected]>
This removes the burden of determining whether to and then
actually sending SIGPIPE from the protocol modules, meaning
the MSG_NOSIGNAL flag can now be implemented entirely in
the socket module and not even passed further down the chain.
Change-Id: I9ba976c4aff60d533cb4b390bbba1560c0de423f
Reviewed-on: https://review.haiku-os.org/c/haiku/+/7124
Reviewed-by: Jérôme Duval <[email protected]>
Reviewed-by: waddlesplash <[email protected]>
Fixes WebKitGTK spinning endlessly and spawning lots of
short-lived worker processes following the addition of
flag checks and EOPNOTSUPP to the various socket modules.
Change-Id: I6d944b4d0235eea9e8a9333645fcb531805f340f
Reviewed-on: https://review.haiku-os.org/c/haiku/+/7123
Reviewed-by: Jérôme Duval <[email protected]>
Tested-by: Commit checker robot <[email protected]>
Reviewed-by: waddlesplash <[email protected]>
Its declarations were moved from another header to this file
in 2008, with a comment in the commit message and a TODO here
questioning whether it was needed for anything. In the 15 years
since then, nothing has used it.
Waiting for state changes correctly checked MSG_DONTWAIT,
but the overall data timeout only did in ReadData, not
SendData. This corrects that and makes the implementation
more consistent overall.
Same logic as in the TCP protocol module.
This fixes a regression from hrev57383: curl now works
again. (Perhaps it shouldn't be called a "regression",
though, but instead an uncovered bug / missing feature.)
Fixes#18666.
The debug_server sends MSG_DEBUG_THIS_TEAM but of course it doesn't
have a way to specify the internal interface pointer. We should thus
assume the local one is implied.
Fixes#18645, which is not a regression but has been the case since
the initial host-interface refactors years ago, apparently.
Change-Id: I48078232f154f2f8f7cdf28792d39ae58471ce19
Reviewed-on: https://review.haiku-os.org/c/haiku/+/7074
Reviewed-by: Jérôme Duval <[email protected]>
Tested-by: Commit checker robot <[email protected]>
* Declare databridge buffer lengths in LocaleBackend.
* Use strcpy instead of strlcpy when writing to databridge buffers
(this is the first fix for #18598.)
* Check for overflows and error out when they happen.
* Verify that ICU actually knows the timezone in question
and fall back to GMT if it does not (this would also fix that crash.)
Fixes#18598.
While debugging some problems on the HaikuPorts build VMs, mmlr
noticed their clocks had an alarming amount of drift. This prompted
an investigation into TSC calibration mechanisms, and the discovery
that there is a VM-specific one which we did not implement.
This mechanism is more accurate than counting cycles on VMs where
cycles can be "stolen" (the probable cause of the aforementioned
clock drift.)
Tested in VMware (works out of the box) and on QEMU/KVM
(may need TSC frequency specified or a host with invariant TSC.)
Change-Id: I4ccfdb2e4e2621404ec9026e7106c02bf96faf18
Reviewed-on: https://review.haiku-os.org/c/haiku/+/7063
Reviewed-by: waddlesplash <[email protected]>
The previous code did not work on non-English locales,
a problem readily detectable when running in Terminal
inside a Terminal session, e.g.:
PrefHandler::getRGB(Hintergrund) - key not found
Fixes#18614.
There are now some system headers (e.g. <stdatomic.h>) that have outright
different versions for C and C++ which are not compatible with each other.
Change-Id: Ibf797e0817f0fe4d5241424d7d06023b19888c02
Reviewed-on: https://review.haiku-os.org/c/haiku/+/6991
Reviewed-by: waddlesplash <[email protected]>
Tested-by: Commit checker robot <[email protected]>
Augustin Cavalier