The IORequest internally likes to deal with transferEndOffset
not transferredBytes because of sub-requests potentially being
prepared all at once (in some paths in the I/O scheduler),
thus fTransferSize can get incremented in Advance() before we have
actually executed that transfer.
But external consumers much prefer just knowing transferredBytes
not transferEndOffset. And many of them actually named their
variables that (or "bytesTransferred") and just passed the
transferEndOffset through to variables with that name! That's
obviously wrong, and it's surprising it wasn't discovered before now.
The problem was uncovered by repeated KDLs in PrecacheIO.
That method used the "bytesTransferred" value as a count of
pages transferred, which would then run past the end of the array
if the transfer start offset was not 0 (which the majority
of the time it would be, since this method gets called on
the first mmap() of a file, probably before any pages are read in.)
Most other consumers of this API did not check the value, it seems,
or otherwise had some mitigating factor that prevented it from
causing more problems. An exception is the page code, which
may have spuriously considered writes as successful when they
really weren't.
May fix some of the "invalid concurrent access to page" KDLs.
The Desktop instance is currently a singleton, and by the time it starts
the GlobalFontManager's initial scan is already running, so if we
register the user paths then it will spend a long time waiting for
the lock. GlobalFontManager didn't even use the provided UID,
so just move the add-user-paths logic into the constructor.
This helps with #18669 on systems that have the default fonts set
and no font settings file. (On systems that do, the global font
manager lock will be acquired in desktop settings initialization.)
This wasn't noticed until now because the IPv4 module would just
truncate packets to their actual length, but the extra data would
appear in packet captures.
Otherwise we load and unload the SCSI module thousands of times,
which is expensive. It was only added to this section for virtio
in d3b108c53d, so avoid scanning
it here except in that case.
Confirmed that virtio_scsi still works as a boot device.
While at it, remove an unused get_attr.
Change-Id: I0882fcb3465809d6bcdd8ed45e66a4dbfe91f7ac
Reviewed-on: https://review.haiku-os.org/c/haiku/+/7965
Haiku-Format: Haiku-format Bot <[email protected]>
Reviewed-by: waddlesplash <[email protected]>
And add the necessary logic in scheduling_recorder. This way we can
track scheduling profiling during the boot process.
Also remove B_SYSTEM_PROFILER_IO_SCHEDULING_EVENTS as it can't be
activated this early in the boot process.
Change-Id: If32f9b5d61c8cd2b3b36a4e6f8065301abd46149
Reviewed-on: https://review.haiku-os.org/c/haiku/+/7963
Reviewed-by: waddlesplash <[email protected]>
This reverts c5a499a74b
(except for the style fixes in that commit.)
See inline comment. Even after the fix to realtime events,
it seems there are still some lingering bugs causing freezes
on some systems. For now, remove the check again.
_prepare_bounce_buffer also calls _allocate_dmamem and needs to have
the passed BUS_* flags handled properly, so just move the handling
to _allocate_dmamem directly.
The logic in the mixer will automatically stop the mix thread but
leave the "Started" flag set in this case.
While at it, clean up that logic.
This suffices to get the mixer to connect and disconnect from
the same output, at least, and have audio output still work.
See inline comment. As we initialize the TimeComputer with the current
system_time(), if the driver reports the played_real_time of its last
buffer exchange (which, if we're restarting media_server, could be
non-zero), we need to just ignore it.
Fixes assertion failures when using usb_audio. And now that we have
this check in here, we can remove the assert from TimeComputer.
Also add a cast in _GetControlName to appease GCC2 while at it.
Also refactor the logic to not need goto.
The previous design (from 2016) generated an event and wrote to the
control port to queue it, and then the control thread woke up our
semaphore at the appointed time. Rather than have this inefficency,
just use a timeout to the acquire_sem (which is more similar to the
pre-2016 design.)
This should not affect mixer behavior (as we wait for buffers
inside this logic already), it should only reduce the latency
of actual mixer runs.
Time out after waiting at most for 10 seconds. After 81e50deece,
this should only happen when the registrar succeeds in sending the
message but we fail in receiving it for whatever reason, so really
this is just a guard against infinite hangs.
Otherwise, if the filesystem doesn't set them, we will have garbage
values and act wrongly.
This fixes the second KDL and the underlying cause of #18838:
when the system gets into a low memory state, VFS purges unused vnodes.
But of course RAMFS keeps those nodes around. When the VFS went to
retrieve the nodes for reuse, the flags would sometimes randomly
have the "removed" flag set, and the VFS would then try to delete
the node. But of course it wasn't really removed, so we would hit
an assertion failure in RAMFS.
The sender is waiting for a reply, so if the reply fails to send
the target will hang forever. Send back an error in that case.
Should fix hangs of Tracker and Deskbar under low memory conditions
with a very large clipboard.
This can only happen if the real time or performance time values
specified are very large (more than 24 bits), which should only
happen if the time specified is system_time() and the "last" time
is 0. Under that circumstance, last_drift should be 1.0f,
so we can avoid using it at all. Otherwise, invoke debugger().
This would have caught some (but not all) of the problems fixed
in preceding commits.
BTimeSource::Now() uses the current real time to compute the
performance time, so if the performance time and last real time
are 0 in the time source data, we get a positive value that is
the same as the system time. That means we wind up waiting
a while to start the mixer unnecessarily, often equal to the
current system_time() when the mixer was started.
So, rather than checking the computed Now(), we instead check the
raw performance and real time values from the time source, and
wait for those to be valid before starting.
Also remove a comment about the BeOS R5 multi_audio node. It seems
that ours generates valid time values more quickly, but still starts
off with performance and real times of 0 (which are the default in
the time source anyway.) The new code would still work under such
broken nodes regardless.
This seems to fix sound output taking a long time to start after boot
(or even longer after restarting media services.)
Otherwise they will mess up the time computer and then the published
times, giving huge or miniscule drift values (since the time computer
already has a non-zero real-time by this point, so it will compute
a negative difference if passed 0 for the current real time.)
The "drift" value is the ratio between performance and real time,
so it must never be 0. Specifying it as such would mean that the
consumers of the time source would wind up with wait times that were
extremely large, due to doing a float divide-by-zero.
While working on the kernel timer fixes, I noticed some timer events
that had very large, but not quite infinite, timeouts; and this was
one of them.
Should not constitute a behavioral change (since the nearly-infinite
timeouts would never be hit.)
The logic in add_timer was scheduling the timer using "scheduleTime",
the originally passed value, not "event->schedule_time", which
is adjusted inside add_timer to be relative to the system_time.
This meant that if the event was the first added to the list,
we would set the hardware clock for a very long time in the future
rather than the correct duration.
Since until recently cancel_timer reset the hardware clock every run
even if the cancelled timer wasn't at the head of the list, this
problem was covered up by that one, as usually the scheduler would
cancel a timer relatively frequently, and thus the hardware timer
would usually get set to the correct value relatively frequently.
But after c5a499a74b, this was not
the case anymore as we skip updating the hardware timer if we cancelled
any timer other than the one at the head of the list, exposing this bug.
The fix is simple: don't bother storing a local "scheduleTime" variable
separate from the event->schedule_time. This makes things less confusing
anyway.
Fixes#18967.
HD currently fetches changelog and user ratings for packages using
a thread from the window. In this change, the fetching of this
data is instead performed using process coordinators in order to
make background processing behaviour consistent and to prep for
future changes.
Change-Id: I7fd0f33c4b9a63fa4b999e2909ce320296db59b9
Reviewed-on: https://review.haiku-os.org/c/haiku/+/7928
Reviewed-by: waddlesplash <[email protected]>
Tested-by: Commit checker robot <[email protected]>
TCP times are measured in milliseconds, and so on LAN (or on two
VMs on the same host) we can wind up with round trip times of
less than 1 ms, which thus come out to 0. Tolerate this appropriately
rather than taking 0 to be a magic value meaning "unknown".
Change-Id: Ica827ee4ea353208291cf4348e9da8af6214b507
Reviewed-on: https://review.haiku-os.org/c/haiku/+/7926
Tested-by: Commit checker robot <[email protected]>
Reviewed-by: waddlesplash <[email protected]>
The basic idea: target a window size large enough to fit one
second's worth of data in it, using the round-trip time to
condition when we make the computations.
If we don't have SACK (to reduce retransmissions on packet loss)
or the user has specified a specific receive buffer size, then don't
scale at all.
Send window scaling isn't implemented yet, as that more-or-less
requires more careful management of congestion windows and SACK
processing which we do not currently implement.
Part of #15886.
Change-Id: Ia2480e6981324d2663e47cb17e8fc47ccc5f9aa0
Reviewed-on: https://review.haiku-os.org/c/haiku/+/6364
Reviewed-by: waddlesplash <[email protected]>
This is more important when window scaling is enabled as otherwise
we will send large amounts of window-update ACKs needlessly.
Ideally we would just use fReceiveWindow here, but due to a
TODO it stays constant (or increases only) at present, so we
have to compute the window size remainder inline. Another
similar computation elsewhere failed to take the case when
the window is 0 into account, so fix that too while at it.
Change-Id: Ibcca258472940d7de2d1adc9f986ddb7245438be
Reviewed-on: https://review.haiku-os.org/c/haiku/+/7924
Reviewed-by: waddlesplash <[email protected]>
Tested-by: Commit checker robot <[email protected]>
Haiku-Format: Haiku-format Bot <[email protected]>
The network stack (TCP in particular) does not handle path MTU
discovery properly (or at all), so we should avoid trying to
send (or advertise support for) frames that large.
Now that we use net_buffers for receiving and sending directly,
this value really is only the "MTU"; it is entirely possible
to receive frames larger than this successfully. So this should
only fix things and not break anything at present.
The CRC is handled within the driver and does not need to be accounted
for here (despite the fact that some of the constants used in MTU
assignment do include it in their computations.)
We need to not expose arbitrary previously-used memory contents
to userspace applications, but this also fixes a bug in that
POSIX specified partial pages in mmaped files should be zero-filled,
and without this, RAMFS did not adhere to that.
Should fix https://github.com/haikuports/haikuports/issues/10463
(which was earlier reported as #18903.)
If the send maximum segment size is very large (as it is on loopback)
and we have receive scaling enabled, we can wind up in situations where
the advertised window will basically always be smaller than the maximum
segment size. In order to avoid stalling until timeouts occur in
this case, check the advertised window against the default segment
size times 3 (which is around the size of ethernet MTU.)
The TIME_WAIT timer, when it fires, either sets FLAG_DELETE_ON_CLOSE
(if FLAG_CLOSED is not set), or releases the socket reference directly
(if it is set.) As we set FLAG_CLOSED in Free(), we only want to start
the TIME_WAIT timer if FLAG_DELETE_ON_CLOSE is not set yet.
Probably harmless since the timer was cancelled on deletion anyway,
but it doesn't hurt to be clearer here.
...in-order packets following out-of-order ones.
This more or less undoes 04468d614b.
A closer reading of the specs indicates we should send duplicate ACKs
for every out-of-order packet even when SACK is enabled (and of course
send up-to-date SACK information with each duplicate ACK in that case.)
virtio can pass us packets with some of the checksums incomplete.
For now we just pass these to the stack without completing their
checksums; the stack will check only the CHECKSUM_VALID flags.
Tested with QEMU on Linux (IPv4, UDP, TCP, ICMP), seems to work.
Change-Id: Ifc13d931278849b6c4eec550444344e7f1bf53d1
Reviewed-on: https://review.haiku-os.org/c/haiku/+/7918
Reviewed-by: waddlesplash <[email protected]>
Reviewed-by: Jérôme Duval <[email protected]>
Tested-by: Commit checker robot <[email protected]>
If SACK is enabled, then we do not need to send a duplicate ACK
for every out-of-sequence packet, just the first one; following
ones will get delayed-acknowledge'd with SACK information.
Under those conditions, this reduces duplicate ACKs significantly.
We can't allow applications to reference/unreference cursors,
this is a safety/security violation, and it being done improperly
lead to the reference counts becoming incorrect on the app_server
side.
Change AS_REFERENCE_CURSOR to AS_CLONE_CURSOR and adjust the Cursor
code appropriately. (In the future, copying BCursor without Clone'ing
the data in the case of custom cursors could be accomplished with
client-side reference counting.)
Then rework CursorManager to remove cursors at once on team deletion,
and otherwise clean up cursor reference management to let the
reference counting handle things.
We need to acquire our own references to these Cursors.
Fixes assert failures after the addition of more Referenceable asserts,
and may help with #13464 and #18275.
This matches Linux. New files created in these folders will still
have rwxr-xr-x by default, of course, but the directories themselves
should be usable by all users.
If it is, that could indicate a use-after-free (0xdeadbeef has the
sign bit set), or at least that something else strange is happening.
May help with catching/diagnosing KDLs in the network stack.
This (mostly) reverts commit 3ea7c99119.
We no longer need this code after introducing the calls to send
net_buffers to drivers directly.
Change-Id: I31a2fdbbbe8203c53dbcc1e3b1fab2492c8651bd
Reviewed-on: https://review.haiku-os.org/c/haiku/+/7914
Reviewed-by: waddlesplash <[email protected]>
It would be nice to reuse the data_nodes as ext_bufs directly
and save another copy. However, we can't do that at the moment,
because while data_nodes and MCLBYTES are the same size (2048),
the data_nodes contain a header structure at the beginning of
that data.
(Perhaps we should consider reworking net_buffer to store data
differently to make that possible. It would also have the advantage
that data_nodes would start on a page boundary or a half-page boundary,
which would make doing direct DMA with them much easier in this
and other drivers as well.)
Change-Id: I8cd3b82a90f328c7a5d2437e3e95413bd74537ae
Reviewed-on: https://review.haiku-os.org/c/haiku/+/7913
Reviewed-by: waddlesplash <[email protected]>
This paves the way for a variety of more interesting interactions
between drivers and the stack which are currently not possible
(e.g. checksum offload, #18744). The main advantage for the moment
is that we will save a memcpy of the buffer on each send/receive.
Adapt the virtio_net driver so that at least one driver is using
the new interface. Network still seems to work OK with it.
Change-Id: Ic5832e4865e3e1bed7462583ca1ffd16418d7cab
Reviewed-on: https://review.haiku-os.org/c/haiku/+/7912
Reviewed-by: waddlesplash <[email protected]>
Augustin Cavalier