* allow to handle a maximum of packets in parallel
that fits free slots in the ack queue
* stop processing packets, when the driver can't handle
more requests in parallel, and resume packet handling,
when the driver is ready again
As hw_arndale is a bit slower than foc_arm and spawn_serial timing
calculation has changed in general, timeouts of noux_tool_chain_auto test
must be adjusted.
fix#996
The Genode-specific implementation of 'QWaitCondition' contains a race
condition which can make the 'qt5_samegame' application hang on Fiasco.OC.
Since most of the pthread synchronization functions needed by the
UNIX-specific implementation of 'QWaitCondition' and 'QMutex' are
available now, we can use these now instead of fixing and keeping
the Genode-specific implementation.
Fixes#993.
Instead of using an additional thread in each Session_component of a
block server, which uses the generic block component and driver classes,
replace it with signal dispatchers.
Ref #113
With 64K stack size, when doing 'make core' in noux on base-hw, the main thread
of /libexec/gcc/arm-elf-eabi/4.7.2/cc1plus runs into a stack overflow during
the compilation of core/main.o . Thus raise the stack size to 128K.
fix#964
The previously used RAM 0x0..0x10000000 was just an alias for
0x70000000..0x80000000. Qemu provides up to of 768 MB RAM with the
correct -m argument. This RAM is located at 0x70000000..0x90000000 and
0x20000000..0x30000000. At least the noux_tool_chain scripts are
happy to have that much RAM.
ref #964
For PBXA9 qemu adjusts provided RAM chips to the -m arg. Thus we
filter user values and force value that enables all chips that Genode
expects to be available. Not doing so leads to inexplicable errors.
ref #964
Makeinfo versions greater 5 treat an @itemx that isn't preceeded by an @item
not as warning anymore but as error. The GCC version 4.7.2 that is used by
noux currently triggers this error multiple times. This commit adds a patch
to 'make prepare PKG="gcc"' that avoids the use of @itemx without preceeding
@item. As GCC versions greater than 4.8 should fix this problem by themselves
this should be seen as temporary quick fix.
ref #964
At least with base-hw, the endless loop at the end of the fork
parent slows execution of the fork child dramatically. Using
libc function pause() is a cleaner solution anyways.
ref #964
