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.)
(cherry picked from commit 4909eb2091b751e2cee8eac11ecabf3315544a99)
Change-Id: I682b2c524996a9fbb2ddc0c4c661fd27c71fcec5
Reviewed-on: https://review.haiku-os.org/c/haiku/+/7982
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
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.
(cherry picked from commit 27462aa0c7cc684a0d3ed2ee7797f60b9410c44c)
Change-Id: Ied9e42dbd104e85962f280424a17bb9fe0e96c03
Reviewed-on: https://review.haiku-os.org/c/haiku/+/7981
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Otherwise we load and unload the SCSI module thousands of times,
which is expensive. It was only added to this section for virtio
in d3b108c53d151d7c0aab32c1562bca355462868b, 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 <no-reply+haikuformatbot@haiku-os.org>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
(cherry picked from commit 58c9714921c8fd4d82f2217693241fb71b29ec3a)
Reviewed-on: https://review.haiku-os.org/c/haiku/+/7980
EFI doesn't have a boot keys mechanism so we just disable the
routine that enables it entirely. Also disable it in early kernel
output before the settings file has been read.
This reverts c5a499a74b7a3516451337373e455bb2aba00ace
(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 81e50deecea7,
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.
