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 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>
Necessary to get the system profiler to work properly.
Change-Id: Id9c1a0bedaef18680361c5de449d293ff053940c
Reviewed-on: https://review.haiku-os.org/c/haiku/+/7964
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
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 <waddlesplash@gmail.com>
It helps to simplify to view difference and apply patches.
No functional changes.
Change-Id: Ia29368eceaeb3306990c09da77c4527eff87c72a
Reviewed-on: https://review.haiku-os.org/c/haiku/+/7932
Haiku-Format: Haiku-format Bot <no-reply+haikuformatbot@haiku-os.org>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
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.
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.)
