Various libraries, like libnl and wpa_driver_nl80211, used hardcoded
values for the interface index (ifindex) and name (ifname).
To accomdate the legacy as well as the upcoming new driver we add
functions to query these information where at least the index differs.
Issue #4455.
The location of the used 'source.list' file is hard-coded and will not
work when the ported driver is implemented as a shared library. For
this use-case provide means to set the location differently.
Issue #4455.
In case where the ported driver or protocol stack is executed from
an already managed environment, e.g. the libc, the execution
of the static constructors will be performed at the appropriate
time.
Issue #4455.
Whenever the nic_router encounters ARP requests on an interface
that does not have a valid IP config it will ignore them. However,
When increasing the verbosity of the component for diagnostic
purposes the resulting 'Bad network protocol' message is misleading.
Issue #4455.
* Test DHCP RENEW by the test client in the unmanaged variant.
* Add event IDs to log output of test client in order to prevent false positive
result in the managed variant.
* Let managed and unmanaged variant have separate string patterns for
'run_genode_until' because they already had different output and it will
differ even more as we don't want to test DHCP RENEW with the managed
variant.
* Delay first test client DHCP in order to fix unexpected sporadic initial IP
config.
* Remove some unnecessary code from the run script
Fixes#4460
The NIC router did update the IP config of a domain on a completed DHCP
REQUEST but not on completed DHCP RENEW or DHCP REBIND. Thus, it didn't adapt
to "real" DHCP servers (not NIC router servers) that got restarted with a
changed configuration by the means of RENEW/REBIND. The commit fixes this.
Note, that testing this is complicated as we don't have the necessary
infrastructure (we cannot simply use the DHCP server of the NIC router as this
would apply a link down/up sequence in order to let the client restart DHCP)
Ref #4460
After reverting unused ranges during allocator destruction
'_meta_data.free_empty_blocks' may lead to more unused ranges because
meta data blocks maybe freed where the meta data for the blocks is
managed by other meta data blocks. This leads to dangling allocation
warnings which are caused by meta data. Therefore, we call
'_revert_unused_ranges' and 'free_empty_blocks' until no more ranges
can be freed.
issue #4466
by using the io_mem RPC of the platform session instead of parsing the
bar resources manually. This commits avoids and breakage on systems where
the Intel graphic cards just uses 64bits with addresses above 4G.
Issue #4450
Compared to the bytewise memset, a wordwise memset (or even multi-word)
achieves a speedup of ~6.
On Zynq-7000/Cortex-A9:
317 MiB/s -> 2040 MiB/s
On base-linux x86_64:
3580 MiB/s -> 23700 MiB/s
genodelabs/genode#4456
Preloading a few cache lines ahead brings a significant speedup in
memcpy throughput. Note, the particular (optimal) value was empirically
determined on a Cortex-A9 (Zynq-7000) SoC @ 666Mhz. It is best combined
with L2 prefetching enabled (including double linefills and prefetch
offset 7). Yet, even without L2 prefetching this seems to be the sweet
spot.
genodelabs/genode#4456
The implementation is not in use any more. Furthermore, on typical ARM
cores such as the Cortex-A9, the cached read appears to be the
bottleneck rather than instruction density. On a Zynq-7000 SoC, the vfp
implementation performed significantly worse than the standard load/store
multiple implementation with preloading.
genodelabs/genode#4456
When executed on Linux, the test was impaired by the copy-on-write
optimisation since the source buffer was never initialised. By default,
Linux only maps a zeroed page until the first write access to the page
occurs. Since the source buffer was never written, the corresponding
page was always present in the physically-indexed data cache. In
consequence, the test merely measured write performance (similar to memset).
genodelabs/genode#4454
Send usb ctrl transfers with one second timeout as some devices (e.g.,
smartcard readers) do not response to certain control transfers.
Thanks to Peter for the investigation.
The i2c code has a busy loop (see commit for the location), which expects that
the jiffies advances without a cooperative scheduling decision.
Issue #4450
Our usb_host driver supports UHCI, OHCI, EHCI, and XHCI host
controllers. The USB4 host interface / Thunderbolt is currently not
supported and must therefore not be passed to the USB host driver.
If any PCI device reports 0 as interrupt PIN, drivers may try to force
MSI setup (e.g., xhci). So, we clamp the interrupt PIN to 1 to let
drivers finish initialization and don't bother the platform driver.
Encountered on the Fuji5 where for reasons currently unknown the
first xHCI HC (0:0d.0) could not be initialize due to incomplete
interupt informations. The other HCs appear to work fine (tested
with a USB low-speed mouse).
This commit removes all physical notions from the information given
to the Linux kernel regarding PCI BARs.
With the exception for the host bridge that needs to be located at
'0:00.0' as required by the Intel FB driver, all other devices are
announced at the PCI BUS in an ascending order.
Additionally the MMIO regions start at 1 GiB and are capped at 32 bit
to prevent unnecessary access to 64 bit addresses.
With this fix, the driver no longer aborts on the Tigerlake notebook and
just skips the out-of-region ACPI table. Issue #4452 is not fixed by
this commit, but in this specific case the table is not used anyway.
Upgrade to the well known worst cases by the GPU multiplexer. Do not
keep track of resources locally, in case resources are exceeded the
remain so anyway.
issue #4451
Check if there are a least 4 caps + 2MB (heap) + possible buffer size
available before any resource allocation. Only account resources that are
actually used.
issue #4451
Some devices do not answer connection attempts timely, which leads
amtterm to time out (after 60s). Using multiple attempts in 500 ms
intervals results in timely connection and complete boot logs.
Issue #4429
