The calibration of the interpolation parameters was previously only done
periodically every 500 ms. Together with the fact that the parameters
had to be stable for at least 3 calibration steps to enable
interpolation, it took at least 1.5 seconds after establishing a
connection to get microseconds-precise time values.
This is a problem for some drivers that directly start to poll time.
Thus, the timer connection now does a calibration burst as soon as it
switches to the modern mode (the mode with microseconds precision).
During this phase it does several (currently 9) calibration steps
without a delay inbetween. It is assumed that this is fast enough to not
get interrupted by scheduling. Thus, despite being small, the measured
values should be very stable which is why the burst should in most cases
be sufficient to get the interpolation initialized.
Ref #2400
When in modern mode (with local time interpolation), the timer
connection used to maximize the left shifting of its
timestamp-to-microseconds factor. The higher the shift the more precise
is the translation from timestamps to microseconds. If the timestamp
values used for determining the best shift were small - i.e. the delay
between the calibration steps were small - we may got a pretty big
shift. If we then used the shift with bigger timestamp values - i.e.
called curr_time seldom or raised calibration delays - the big shift
value became a problem. The framework had to scale down all measured
timestamps and time values temporarily to stay operative until the next
calibration step.
Thus, we now raise the shift only that much that the resulting factor
fullfills a given minimum. This keeps it as low as possible according
to the precision requirement. Currently, this requirement is set to 8
meaning that the shifted factor shall be at least 2^8 = 256.
Ref #2400
The kernel timer on RPI is able to measure time microseconds-precise.
Howeer, due to a bug, we dropped precision during the ticks-to-time
translation and return only milliseconds-precise time.
Ref #2400
As the timer session now provides a method 'elapsed_us', there is no more need
for doing any internal calculations with values of milliseconds.
Ref #2400
As timer sessions are not expected to be microseconds precise (because
of RPC latency and scheduling), the session interface provided only a
method 'elapsed_ms' although the back end of this method in the timer
driver works with microseconds.
However, in some cases it makes sense to have a method 'elapsed_us'. The
values it returns might be milliseconds away from the "real" time but it
allows you to work with delays smaller than a millisecond without
getting a zero delta value.
This commit is motivated by the need for fast bursts of calibration
steps for the time interpolation in the new timer connection.
Ref #2400
The filename buffer of a dataspace in base-linux is limited to
40 bytes. When using file names longer than this, the remainder
gets dropped silently. Add an error message to aid debugging this
case.
This is helpful for disabling messages in etc/tools.conf by
setting it to e.g.
MSG_LINK = @true ""
This results in much shorter and less cluttered logs in automatic
builds.
- factor out Rm_client::pager lambda code into utility
Region_map_component::create_map_item
- use utility to find/lookup physical addresses to be mapped eagerly
Issue #2209
The launcher.run scenario was last updated mid-may of the recently
developed cap-quota accounting (before all cap types were covered).
Hence, the quotas used in the scenario are too low. This patch adjusts
the values such that the scenario can be started on NOVA on Qemu. It
also fixes a warning about a deprecated way of configuring the
report_rom component.
Thanks to Jörg-Christian Böhme for reporting!
- Update FatFS port from 0.07e to 0.13
- Multi-device support
- Basic test at run/fatfs
- Adaption of existing components
Note, ffat is now consistently renamed to fatfs.
Ref #2410
rm_fault.run triggers write on read-only ROM provided by core, which
fails without this patch:
arm - "raised unhandled data abort"
x86 - (silent/invisible) busy loop because write fault gets never resolved
The run script did not consider the routing for the environment ROM
sessions for the test-iso component. It routed all ROM sessions -
including the ones for the executable and the dynamic linker - to
fs_rom. The patch also adds the cap quota definitions required since
version 17.05 and fixes a whitespace inconsistency between the test
program and the run script.
Thanks to Steven Harp for reporting!
This is expected by hardware terminals, ie., terminal programs connected
to null-modem serial connections. Otherwise, the next line starts at the
column right after the last line.
Platform_pd "_pd" uses a allocator for, which relies on the mapped RAM
dataspace within core. Unfortunately the RAM dataspaces are already freed up
during _ram_ds_factory destruction, which may lead to trouble if accessed
afterwards.
Issue #2451
The new version of the test exercises the combination of fs_report with
ram_fs and fs_rom as a more flexible alternative to report_rom.
It covers two corner cases that remained unaddressed by fs_rom and
ram_fs so far: First, the late installation of a ROM-update signal
handler at fs_rom right before the content of the file is modified.
Second, the case where the requested file is not present on the file
system at the creation time of the ROM session. Here, the ram_fs missed
to inform listeners for the compound directory about the later created
file.
This patch ensures that fs_rom delivers a ROM-update notification in the
case where the underlying file was changed in-between requesting the
initial ROM content and registering the signal handler.
With the introduction of the CONTENT_CHANGED notifications delivered via
the packet stream, the assumption that no more than one READ packet is
in flight at all times does no longer hold. If the fs server responds
to a CONTENT_CHANGED packet while the fs_rom expects the completion of a
read request, the '_update_dataspace' method would prematurely return,
leaving the dataspace unpopulated. This patch solves the problem by
specifically waiting for the completion of the read request.
Session_requester inherits from Dynamic_rom_session::Content_producer
which specifies the Buffer_capacity_exceeded exception which is thrown
on insufficient buffer space.
This patch sets the -march complile flag in spec/arm_v7a.mk, which
enables us to build depot archives for the 'arm_v7a' architecture.
It also removes copy-pasted comments that offer no valuable insights but
contain grammar errors.
On platforms that use the PIT timer driver, 'elapsed_ms' is pretty
inprecise/unsteady (up to 3 ms deviation) for a reason that is not
clearly determined yet. On Fiasco and Fiasco.OC, that use kernel timing,
it is the same. So, on these platforms, our locally interpolated time
seems to be fine but the reference time is bad. Until this is fixed, we
raise the error tolerance for these platforms in the run script.
Ref #2400
Appending a suffix to report filenames was behavior inherited from
fs_log, it prevents creating files where directories need to be created
later. But unlike logs, only a subset of the hierarchy will report and
those that do append a component-local label, so the risk of collision
is low.
By removing the suffix fs_rom can serve reports back as ROM just as
report_rom does.
Ref #2422
A bug in the timer-ticks-to-microseconds translation of the kernel timer
caused the user time to periodically get stuck for about 32 milliseconds
and then jump forward to the normal level again.
Ref #2400
In the timeout framework, we maintain a translation factor value to
translate between time and timestamps. To raise precision we scale-up
the factor when we calculate it and scale-down the result of its
appliance later again. This up and down scaling is achieved through
left and right shifting. Until now, the shift width was statically
choosen. However, some platforms need a big shift width and others a
smaller one. The one static shift width couldn't cover all platforms
which caused overflows or precision problems.
Now, the shift width is choosen optimally for the actual translation
factor each time it gets re-calculated. This way, we can take care that
the shift always renders the best precision level without the risk for
overflows.
Ref #2400
The result-buffer related members of the fast polling test are
the same for each buffered result type. Thus, we can make the
code easier by providing them through a struct.
Ref #2400
This patch increases init's preserved RAM and capability quota to
account for a current limitation of init with respect to the creation of
sessions to parent services:
In contrast to regular routed services, sessions to parent services are
created via 'Env::session'. The implementation of 'Env::session'
automatically upgrades session quotas on demand, which is the desired
behavior for regular 'Connection' objects. However, for sessions
established on the behalf of init's children, we would need to reflect
the error condition to the child instead of resolving it locally within
init (by subsidizing the session with init's quota). This patch leaves
this issue unresolved but fixes the symptom for the bomb test. It is
meant as an interim solution until the handling of parent sessions is
revised.
This patch decouples the error handling of the quota transfers
and the actual session creation. In the previous version, an error in
the 'initiate_request' phase would leave the local scope via an
exception without disarming the transfer guard objects. This way,
the guard destructors would attempt the returning of session quota in
addition to the explicit call of '_revert_quota_and_destroy' as done in
the error handling of the 'initiate_request' operation.
In the presence of a session-creation error in the 'initiate_request'
phase, session quota would eventually be returned twice. This patch
removes the intertwined error handling of both phases in a way that the
guards of the first phase (quota transfer) are no longer present in the
second phase (initiate_request).
This patch makes sure that the initial PD session limit (as defined by
the client-provided session quota) is preserved over the entire lifetime
of the PD session. That means, it cannot be transferred to other PD
sessions. Otherwise, it may be impossive to hand back all the static
session quota to the PD-session client at session-destruction time
because parts of the initial quota would no longer belong to the
session.
Note that the initial limit can still be used for allocations within the
PD session as those allocations are automatically reverted at
session-destruction time.
