Uploading large files via HTTP PUT failed when the file system was
accessed via a file system session because lighttpd opened the
destination file with O_NONBLOCK and the write operation stalled
at some point.
genodelabs/genode#5093
When multiple threads (EMT-0..X + nic_ep) enter the very same
critical section, the use of RTCritSectTryEnter may reflect the contention
case to the Network Model (E1000). Since no one notifies the model, when the
critical section is free again, solely the next packet/event triggered by the
guest will resume the former operation. This may lead to long delays until
packets are sent actually.
Instead of using the RTCritSectTryEnter use RTCritSecEnter to avoid the
situation. All of our network code is non blocking, so the network backend
will only be contented a short time.
Follow up commit to
Issue #5045
- finished tx ack queue should be checked before new allocations
- packets which got not sent must be released in packet stream,
otherwise the network packet stream gets filled up and starves after a while
- rRegister for ack avail packets and process them concurrently to EMT-* threads
by nic_ep thread (thanks @Peter for the findings) + add synchronization.
- add sigh_ready_to_submit to network adapter to improve latency by notifying
the network model explicitly in case we had a full packet stream error case
(_retry resp. VERR_TRY_LATER)
Fixes#5045
Per Affinity::Location a system control cap can be requested. The capability
provides an RPC interface to request and set Cpu_state, as provided by the
former Pd::managing_system(Cpu_state) method. Invocation of those system
control capabilities then *can* (see below) be executed on the desired CPU
as described by Affinity::Location.
The system control cap will be invalid for kernels that don't support
system_control/managing_system functionality at all.
The system control cap will be ever by the same, e.g. ignoring the
Affinity::Location parameter, if the used kernel doesn't support or doesn't
require the feature to execute the system control per CPU.
The commit is a preparation step to add guarded and selective x86 MSR
access per CPU.
Fixes#5009
To prevent exessive allocations the bounce buffers are allocated
once and afterwards re-used. The DMA buffers are provided by an
range allocator whose backing store increases in 4 MiB chunks.
The range allocator might not merge the ranges as those chunks
are not necessarily allocated continously. Allocations larger
than the static chunk size are therefor treated as error.
instead via the hardware registers of the FPU. On Genode all components and
so VMMs are built such, that the compiler may generate optimized code by
using the FPU at any time. We had to make sure to save the
FPU state as early as possible before the VMM component touches the FPU,
to avoid corrupting & losing guest FPU state. This caused headache again
and again. To avoid the uncertainty, we remove this feature and explicitly
transfer the FPU state via the UTCB.
When the wait value is too small the HALT attempt turnes into
busy-polling in the VMM. To prevent that always wait a minimal
amount of time.
Issue #4990.
Some Ubuntu installations (e.g., 20.04) create installation disks with
strange C/H/S MBR partitions like 3988/255/2. Normally, VirtualBox reads
the MBR to guess disk geometry information for the virtual BIOS.
Unfortuantely, the strange values from Ubuntu lead to a heavy
virtual-disk activity on boot. Therefore, this commit forces the use of
calculated values based on the assumption that large disks use LBA
addressing anyway.
Fixes#4978
