Make pmtimer tsc calibration not take 51 seconds to fail.
On my laptop running at 2.4GHz, if I run a VM where tsc calibration
using pmtimer will fail presuming a broken pmtimer, it takes ~51 seconds
to do so (as measured with the stopwatch on my phone), with a tsc delta
of 0x1cd1c85300, or around 125 billion cycles.
If instead of trying to wait for 5-200ms to show up on the pmtimer, we try
to wait for 5-200us, it decides it's broken in ~0x2626aa0 TSCs, aka ~2.4
million cycles, or more or less instantly.
Additionally, this reading the pmtimer was returning 0xffffffff anyway,
and that's obviously an invalid return. I've added a check for that and
0 so we don't bother waiting for the test if what we're seeing is dead
pins with no response at all.
If "debug" is includes "pmtimer", you will see one of the following
three outcomes. If pmtimer gives all 0 or all 1 bits, you will see:
This outcome was tested using qemu+kvm with UEFI (OVMF) firmware and
these options: -machine pc-q35-2.10 -cpu Broadwell-noTSX
If pmtimer gives any other bit patterns but is not actually marching
forward fast enough to use for clock calibration, you will see:
kern/i386/tsc_pmtimer.c:121: pmtimer delta is 0x0 (1904 iterations)
kern/i386/tsc_pmtimer.c:124: tsc delta is implausible: 0x2626aa0
This outcome was tested using grub compiled with GRUB_PMTIMER_IGNORE_BAD_READS
defined (so as not to trip the bad read test) using qemu+kvm with UEFI
(OVMF) firmware, and these options: -machine pc-q35-2.10 -cpu Broadwell-noTSX
If pmtimer actually works, you'll see something like:
kern/i386/tsc_pmtimer.c:121: pmtimer delta is 0x0 (1904 iterations)
kern/i386/tsc_pmtimer.c:124: tsc delta is implausible: 0x2626aa0
This outcome was tested using qemu+kvm with UEFI (OVMF) firmware, and
these options: -machine pc-i440fx-2.4 -cpu Broadwell-noTSX
48d086b...
by
Andrzej Kacprowski <email address hidden>
Add support for non-Ethernet network cards
This patch replaces fixed 6-byte link layer address with
up to 32-byte variable sized address.
This allows supporting Infiniband and Omni-Path fabric
which use 20-byte address, but other network card types
can also take advantage of this change.
The network card driver is responsible for replacing L2
header provided by grub2 if needed.
This approach is compatible with UEFI network stack which
also allows up to 32-byte variable size link address.
The BOOTP/DHCP packet format is limited to 16 byte client
hardware address, if link address is more that 16-bytes
then chaddr field in BOOTP it will be set to 0 as per rfc4390.
Resolves: rhbz#1370642
Signed-off-by: Andrzej Kacprowski <email address hidden>
[msalter: Fix max string calculation in grub_net_hwaddr_to_str]
Signed-off-by: Mark Salter <email address hidden>
(cherry picked from commit 50f3f90fe7ef5a875ede559124280d226d40743b)
Sometimes we have to provision boxes across regions, such as California to
Sweden. The http server has a 10 minute timeout, so if we can't get our 250mb
image transferred fast enough our provisioning fails, which is not ideal. So
add tcp window scaling on open connections and set the window size to 1mb. With
this change we're able to get higher sustained transfers between regions and can
transfer our image in well below 10 minutes. Without this patch we'd time out
every time halfway through the transfer. Thanks,
Signed-off-by: Josef Bacik <email address hidden>
(cherry picked from commit 995d66fc218e3ddd852269753be0ebd71b72174f)
This adds "exit" with a return code. With this patch, any "exit"
command /may/ include a return code, and on platforms that support
returning with an exit status, we will do so. By default we return the
same exit status we did before this patch.
Signed-off-by: Peter Jones <email address hidden>
(cherry picked from commit ccce3d69ae3eacc7bdc70217304586bd7e74fe1e)
Patch-Name: rhboot-f34-make-exit-take-a-return-code.patch
