The driver might end up in an endless loop on systems that do not
contain an i8042 controller when probing the AUX interface. This
leads to busy looping and in the end to not annoucing the Input
service. Components that wait for the announcement of the service
will therefore hang as well.
Normally a service gets announced only if it is usable but in this
case this is inconvient because it renders all scenarios that use
the input_merger non working on x86 systems that only provide USB
input and do not have PS/2 at all.
Ideally, the PS/2 driver should only be started if the system needs it.
That is currently not feasible and for the time being we post-pone the
inevitable and back down after several unsucessful attempts to read
from the AUX interface while initializing the driver.
Fixes#1871.
Interfaces that have been claimed by a component always have to be
released when the session is closed in case the component
malfunctioned.
Fixes#1869.
Inspired by the mailing-list posting [1], this commit removes the
MAC/PHY reset for all Intel cards and effectively prevents the bandwidth
drop to 10 MBit/s (e.g., on i217lm). I understand it as preliminary fix
for practical reasons - a real fix would be to update the ipxe port and
monitor for more postings like the one mentioned.
[1] http://lists.ipxe.org/pipermail/ipxe-devel/2015-December/004511.html
The 'usb_report_filter' component takes the devices report from the
USB driver and generates a new devices report after checking each
entry against its device white-list. Before emitting the new report
it changes the configuration of the USB driver to contain the
required policy entries.
See 'repos/os/src/app/usb_report_filter/README' for more details.
Issue #1863.
- Use 'label' attribute to identify device instead of
bus/dev and vendor_id/product_id
- Implement release_interface RPC
- Report 'label' as well as 'bus' and 'dev'
- Add policy handling to raw driver (includes reconfiguration
at runtime)
- Use own memory backing store for large DMA allocations
Issue #1863.
This prevents a sporadic null-pointer dereference in the nic_loopback
test, which occurred once in 100 runs. I'm not sure if there's still a
race window (we may investigate) with context dissolve.
Instead of polling for new Nic session signals, when waiting for
network packets with a timeout, block on the signal receiver, and
register a timer event beforehand using the same signal receiver.
Fix#1862
Ref #1864
Do not build core-muen_on library without the muen soecifier set.
Do not reference files of the muen contrib directory in the first
pass of make's rule analysis, when parding the muen specific kernel
makefile.
Fix#1859
The new implementation of the FPU and FPU context is taken out to
separate architecture-dependent header files. The generic Cpu_lazy_state
is deleted. There is no hint about the existence of something like an
FPU in the generic non-architexture-dependent code anymore. Instead the
architecture-dependent CPU context of a thread is extended by an FPU
context where supported.
Moreover, the current FPU implementations are enhanced so that threads
that get deleted now release the FPU when still obtaining it.
Fix#1855
Thanks to the log_terminal server, we no longer rely on a separate UART
for the noux output. We also skip the indirection of using a tar archive
but rather start the test-noux_form program as a mounted ROM module.
With commit e74b53d5dd the fork semantic in noux
changed slightly, and broke platforms like hw & sel4, where the UTCB is mapped
directly into the thread's context area. The change moved the re-initialization
to a point where the new noux process' thread stack-pointer was already switched
back to the context area. But to re-initialize the context area RPC calls must
be done, and the UTCB must be used therefore. On the other side the UTCB is
found implicitly by the stack-pointer, whereby a stack-pointer located in the
context-area refers to a UTCB that is expected to reside in the context-area
as well. But the UTCB gets overlayed inside the context area by the
context-area's re-initialization - we've come round in a circle.
This commit rolls back the move of the re-initialization routine. To preserve
the intention of the original commit, the context-area location is stored in
a static variable, so that the Native_config API is not needed anymore.
Fix#1851
This commit enables multi-processing for all Cortex A9 SoCs we currently
support. Moreover, it thereby enables the L2 cache for i.MX6 that was not
enabled until now. However, the QEMU variants hw_pbxa9 and hw_zynq still
only use 1 core, because the busy cpu synchronization used when initializing
multiple Cortex A9 cores leads to horrible boot times on QEMU.
During this work the CPU initialization in general was reworked. From now
on lots of hardware specifics were put into the 'spec' specific files, some
generic hook functions and abstractions thereby were eliminated. This
results to more lean implementations for instance on non-SMP platforms,
or in the x86 case where cache maintainance is a non-issue.
Due to the fact that memory/cache coherency and SMP are closely coupled
on ARM Cortex A9 this commit combines so different aspects.
Fix#1312Fix#1807
On ARM Cortex A9 platforms the external PL310 L2 cache controller
needs to be initialized dependent on the SoC. For instance on Pandaboard
it needs to call the firmware running in TrustZone's secure world,
on i.MX6 it initializes it directly, on other boards it doesn't need
to be initialized at all, because the bootloader already did so.
Therefore, we should implement the PL310 intialization in board specific
code and not in the base class implementation.
Ref #1312
This commit separates certain SMP aspects into 'spec/smp' subdirectories.
Thereby it simplifies non-SMP implementations again, where no locking
and several platform specific maintainance operations are not needed.
Moreover, it moves several platform specifics to appropriated places,
removes dead code from x86, and starts to turn global static pointers
into references that are handed over.
Now, the right PCI bus:device:function (BDF) is reported to the kernel
during assign_pci syscall - beforehand it was ever 0:0.0. The BDF is
needed to lookup the correct DMAR unit the kernel has to configure. This
was revealed as the DMAR unit for Intel graphics on x201 is not the same
as for all other PCI devices we have drivers for on this platform.
Fixes#1848
Instead of using the 'alloc()' method to allocate new packets use
the 'next()' method with the previous packet. This is needed because
the last audio stack changes broke the semantics assumed by 'alloc()'.
We now keep track of the already queued packets by hand.
Fixes#1827.
Use kernel branch which is more accurate in accounting memory, which avoids
kernel messages of following form:
[0] warning: insufficient resources ...
Fixes#1830
Because a check for the TEST_WRITE configuration was missing as condition for a
packet submit, the test caused unwanted write access to the device.
Ref #1824
Explicitly cast floats to long as we currently do not plan to support
float in Xml_generator and previously the value was implicitly casted to
long anyway.
Issue #1819
Executing the system call will change the input fds as a side-effect
because the select_in.fds and select_out.fds structure are part of a
union. Since the original select_in.fds content is needed afterwards
make a copy instead of using a reference.
Fixes#1809.
The main thread's UTCB, used during bootstrap of the main thread before
it allocates its context area, needs to be outside the virtual memory
area controlled by the RM session, because it is needed before the main
thread can access its RM session.
Fix#1804
This patch adds diagnostic messages during the label-policy application,
if no policy for the session label was found or if the domain configured
in the policy node does not exist.
When unblocking a thread in Semaphore::up() while holding the fifo meta-data
lock, it might happen that the lock holder gets destroyed by the one it was
unblocking. This happened for instance in the pthread test in the past, where
thread destruction was synchronized via a semaphore. There is no need to hold
the lock during the unblock operation, so we should do it outside the critical
section.
Fix#1333
Previously we used a pretty slow external clock source for the timer. This
resulted in such a low TICS_PER_MS value that the granularity wasn't
sufficient to find a setup with a precision better than 1 second error per
minute. Now we use the so-called High Frequency Reference Clock as input
with TICS_PER_MS=33333 and the timer precision is significantly < 1 second per
minute.
Fixes#1805
From our observations we can tell that the error should not exceed 4%.
However, there is no reasonable explanation by now why the test results
are less stable on these platforms. We have tried several things that
did not lead to an explanation or improvement:
* changing the timing parameters of the scheduler
* switching off SMP
* double-checking the speed of userland and kernel timers
Ref #1805
The test threads previously used a stack size independent from the machine
word width. Qemu was previously configured to provide 64Mb of RAM which isn't
sufficient for x86_64.
Ref #1805
