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 <waddlesplash@gmail.com>
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
The previous code (introduced in hrev57034) was correct for most accesses, but
would reject access to the last word of the configuration space using 8 or 16 bit
access.
May help with #18536
Change-Id: I3eecbdb187eca0ec57e0ce65e4d1eb0d7c43d00a
Reviewed-on: https://review.haiku-os.org/c/haiku/+/7929
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Unless, of course, it has the B_BITMAP_CLEAR_TO_WHITE flag as well.
From my testing, not clearing the BBitmap matches BeOS's behaviour
more closely (if not exactly) compared to clearing the BBitmap.
My test program created the BBitmap and BView, drew a diagonal red line
across it, and saved the result to a file.
The results:
* BeOS - transparent background; red line with no anti-aliasing
* Haiku, current behaviour - white background; red line
* Haiku, new behaviour - transparent background; red line with
black pixels as artifacts of the anti-aliasing process.
The anti-aliasing artifacts, as PulkoMandy pointed out, are simply a
result of not using the B_OP_ALPHA and an appropriate blending mode,
and would happen on BeOS as well if the line had some transparency,
such as through anti-aliasing.
Change-Id: I09ac054eb0ce79e697b78ea48d1db4a15041e600
Reviewed-on: https://review.haiku-os.org/c/haiku/+/7899
Haiku-Format: Haiku-format Bot <no-reply+haikuformatbot@haiku-os.org>
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Reviewed-by: Adrien Destugues <pulkomandy@pulkomandy.tk>
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 <no-reply+buildbot@haiku-os.org>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
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 <waddlesplash@gmail.com>
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 <waddlesplash@gmail.com>
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Haiku-Format: Haiku-format Bot <no-reply+haikuformatbot@haiku-os.org>
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.)
Tidy up of the languages model handling.
Change-Id: Ie9f93dab0a91b4598da87e58cb065fc5272a7b74
Reviewed-on: https://review.haiku-os.org/c/haiku/+/7925
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
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.)
can be found on USB 3.1 xhci controllers in the PORTSC register
Change-Id: I11df7e22ca1ab71b42325f8c3db1e4745287feeb
Reviewed-on: https://review.haiku-os.org/c/haiku/+/7923
Haiku-Format: Haiku-format Bot <no-reply+haikuformatbot@haiku-os.org>
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
The onoff value should be set to 1 for "on" and 0 for "off",
based on the FreeBSD code.
Change-Id: I8da7c905bc4af815f51563b6d9696692b29771db
Reviewed-on: https://review.haiku-os.org/c/haiku/+/7919
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Haiku-Format: Haiku-format Bot <no-reply+haikuformatbot@haiku-os.org>
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 <waddlesplash@gmail.com>
Reviewed-by: Jérôme Duval <jerome.duval@gmail.com>
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
The revision number is used to know if the font list has changed, and
that's where it happens.
Fixes the revision going back when a font directory is removed.
Change-Id: Ib9bb0f463177aff11665c0083604f4a7e35395eb
Reviewed-on: https://review.haiku-os.org/c/haiku/+/7921
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Haiku-Format: Haiku-format Bot <no-reply+haikuformatbot@haiku-os.org>
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
It may not be ID 0 if it has been changed from the default.
Change-Id: I9aef328ee243d85c2cd37b47666440e0e54e66c7
Reviewed-on: https://review.haiku-os.org/c/haiku/+/7920
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Haiku-Format: Haiku-format Bot <no-reply+haikuformatbot@haiku-os.org>
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.
* Extend the volume size limit in bsd_device_init() from 32 GB to 256
GB.
* Permit read-only access above this threshold.
* I would like to do more testing before allowing write access above
256 GB.
* See #11119.
Change-Id: Ica7872d5f4c06415c1501f7a8ffb955785f91a29
Reviewed-on: https://review.haiku-os.org/c/haiku/+/7911
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
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.
