For the framebuffer driver of the i.MX53 platform to work even when u-boot
didn't prepared the display previously, there were some IOMUX routes missing.
Fixes#914
By now, only one button press/release event per IRQ was handled correctly.
Pressing and/or releasing several buttons concurrently could bring the input
driver into an inconsistent state.
Fixes#913
* Remove far too low default values from Nic::Connection constructor
* Extend lwip initialization function with desired TX/RX buffer sizes
* Add configuration possibility to libc_lwip_dhcp plugin to define
buffer sizes, like the following:
'<libc tx_buf_size="1M" tx_buf_size="1M"/>'
Fixes#892
Previously, if two ID allocators for different kernel objects had the
same size, the kernel-object framework managed both objects types
through the same allocator instance. This is caused by the use of
unsynchronized singletons in the accessor functions and can be avoided
by creating new types through inheritance instead of using typedefs.
Anyways, this fix is a little bit ugly and should replaced by avoiding
the use of unsynchronized singletons in the future.
fix#906
At this point we cannot close the connection anymore because all
mappings are gone and the needed stack is invalid. This is not a
problem since process will be discarded anyway.
Fixes#909.
With this patch, the register contents of a paused thread (which is not
currently executing a syscall) can get modified by the
'Cpu_session::state()' function.
Fixes#896.
The copy constructor of Signal did not copy the Signal::Data contents of
the copy source. This bug could survive undetected because the compiler
can optimize code in a way, that copy constructor and destructor are not
necessary when returning by value from simple functions. I assume that
it creates the object in CPU registers instead of RAM and reuses it
instead of copying it to save time. This way the bug triggered first
after wait_for_signal was changed in a way that avoided optimization.
ref #912
In hybrid mode, all programs are dynamic executables and ld.lib.so is
not supported. Therefore, only the "static" variant of the test can be
build and executed.
This change allows for the testing of cli_monitor's automatic resource
balancing by executing the following command:
start ram_eater --ram-limit 1G --count 5
The command starts 5 instances of a RAM-eating process, which is,
however, able to yield resources when instructed. The RAM quota for the
processes gets automatically extended because of the overly large limit
of 1 GiB, which is far more than CLI monitor's RAM resources (100 MiB).
When the RAM usage hits the preservation limit, CLI monitor broadcasts
yield requests to each ram_eater instance, which allow the scenario to
remain alive.
If a local thread is attempted to be 'pause'd via cpu_session, don't wait
until it gets into the recalled state. If the caller is lucky it is, if not
return only the stack pointer.
Avoids deadlocking of the gdb when attached to a process running a server.
Issue #478
The 'pause' call on base-nova assumes that a thread can solely block in its
associated semaphore. Main reason is that so core can unblock a thread in order
that the recall exception gets delivered and the register state can be
obtained.
Unfortunately the signal session implementation creates a semaphore, which is
unknown by the pager code. Instead create the semaphore via the pager of the
thread, so that the pager can unblock the signal thread when a pause is issued.
Issue #478
If a thread caused a page fault and later on get be paused, then it left
the recall handler immediately due to the pause call instead of staying
in this handler.
Add some (complicated) state machine to detect and handle the case. Still not
waterproof, especially server threads may never get recalled if they never get
a IPC from the outside.
Fixes#478
This patch introduces new commands for dynamically balancing RAM between
subsystems. The 'status' command prints a table with the RAM status of
each subsystem. The 'ram' command changes the quota or a quota limit of
a given subsystem. The quota limit can be defined to allow the on-demand
expansion of the quota. Finally, the 'yield' command can be used to
instruct a subsystem to yield a specified amount of resources.
For trying out the new commands, a so-called 'ram_eater' example has
been added to the 'terminal_mux.run' scenario. This program simulates a
subsystem with a growing demand for resources, yet with the capability
to yield resources when instructed by the parent (i.e., cli_monitor).
Besides implementing the new features, the patch splits the
implementation of 'cli_monitor' into multiple files.
