[prefix] Avoid using base memory for temporary decompression area
In the unlikely (but observable) event that INT 15,88 returns less
memory above 1MB than is required for the temporary decompression
area, ignore it and use the 1MB point anyway.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
[linux] Make malloc and linux_umalloc valgrindable
Make the allocators used by malloc and linux_umalloc valgrindable.
Include valgrind headers in the codebase to avoid a build dependency
on valgrind.
Signed-off-by: Piotr Jaroszyński <p.jaroszynski@gmail.com>
Modified-by: Michael Brown <mcb30@ipxe.org>
Signed-off-by: Michael Brown <mcb30@ipxe.org>
There is no need to explicitly call basename() to construct an image
name in imgfetch_core_exec(), since image_set_uri() will do so
automatically anyway (and will do so without getting confused by URIs
with query strings).
Signed-off-by: Michael Brown <mcb30@ipxe.org>
[netdevice] Mark devices as open only if opening succeeds
netdev_close() assumes that devices that are open are on the
open_list, which wasn't true if device specific opening failed.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
The "read" command allows a script to prompt a user to enter a
setting. For example:
echo -n Static IP address:
read net0/ip
Total cost: 17 bytes.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Commit 6861304 ("[tcp] Handle out-of-order received packets")
introduced a regression in which ts_recent would not be updated until
the first packet is received in the ESTABLISHED state, i.e. the
timestamp from the SYN+ACK packet would be ignored. This causes the
connection to be dropped by strictly-conforming TCP peers, such as
FreeBSD.
Fix by delaying the timestamp window check until after processing the
received SYN flag.
Reported-by: winders@sonnet.com
Signed-off-by: Michael Brown <mcb30@ipxe.org>
bin/ipxe.lkrn is built anyway in order to create bin/ipxe.iso, so
there is no additional cost to including it within the default build.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
[monojob] Avoid overflow when calculating percentage progress
Normalise the progress figures to ensure that multiplication by 100
(to produce a percentage) cannot result in integer overflow.
Reported-by: Sven Dreyer <sven@dreyer-net.de>
Signed-off-by: Michael Brown <mcb30@ipxe.org>
iPXE documentation tends to refer to "settings" rather than "options",
since settings can be more general than DHCP options.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
[undi] Cope with devices that erroneously claim not to use interrupts
Some PXE stacks advertise that interrupts are not supported, despite
requiring the use of interrupts. Attempt to cope with such cards
without breaking others by always hooking the interrupt, and using the
"interrupts supported" flag only to decide whether or not to wait for
an interrupt before calling PXENV_UNDI_ISR_IN_PROCESS.
The possible combinations are therefore:
1. Card generates interrupts and claims to support interrupts
iPXE will call PXENV_UNDI_ISR_IN_PROCESS only after an interrupt
has been observed. (This is required to avoid lockups in some PXE
stacks, which spuriously sulk if called before an interrupt has
been generated.)
Such a card should work correctly.
2. Card does not generate interrupts and does not claim to support
interrupts
iPXE will call PXENV_UNDI_ISR_IN_PROCESS indiscriminately, matching
the observed behaviour of at least one other PXE NBP (winBoot/i).
Such a card should work correctly.
3. Card generates interrupts but claims not to support interrupts
iPXE will call PXENV_UNDI_ISR_IN_PROCESS indiscriminately. An
interrupt will still result in a call to PXENV_UNDI_ISR_IN_START.
Such a card may work correctly.
4. Card does not generate interrupts but claims to support interrupts
Such a card will not work at all.
Reported-by: Jerry Cheng <jaspers.cheng@msa.hinet.net>
Tested-by: Jerry Cheng <jaspers.cheng@msa.hinet.net>
Reported-by: Mauricio Silveira <mauricio@livreti.com.br>
Tested-by: Mauricio Silveira <mauricio@livreti.com.br>
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Improve the appearance of the "config" user interface by ensuring that
settings appear in some kind of logical order.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Commit 5fbd020 ("[settings] Display canonical setting name in output
of "show" command") introduced a regression causing all setting
expansions (e.g. "${net0/mac}") to expand to an empty string.
Fix by returning the formatted value length from
fetchf_named_setting(), as expected by the caller.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
[settings] Add hierarchy navigation in "config" user interface
Allow the user to browse through the settings block hierarchy.
Originally-implemented-by: Glenn Brown <glenn@myri.com>
Signed-off-by: Michael Brown <mcb30@ipxe.org>
[settings] Display only applicable settings in "config" user interface
Display only settings relevant to the current scope. For example,
"config net0" no longer displays SMBIOS settings, and "config smbios"
displays only SMBIOS settings.
Originally-implemented-by: Glenn Brown <glenn@myri.com>
Signed-off-by: Michael Brown <mcb30@ipxe.org>
[settings] Display canonical setting name in output of "show" command
Enable the "show" command to display the full, canonicalised name of
the fetched setting. For example:
iPXE> show mac
net0/mac:hex = 52:54:00:12:34:56
iPXE> dhcp && show ip
DHCP (net0 52:54:00:12:34:56)... ok
net0.dhcp/ip:ipv4 = 10.0.0.168
iPXE> show net0/6
net0.dhcp/dns:ipv4 = 10.0.0.6
Inspired-by: Glenn Brown <glenn@myri.com>
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Expose settings_name(), shrink the unnecessarily large static buffer,
properly name root settings block, and simplify.
Modified-by: Michael Brown <mcb30@ipxe.org>
Signed-off-by: Michael Brown <mcb30@ipxe.org>
[settings] Formalise notion of setting applicability
Expose a function setting_applies() to allow a caller to determine
whether or not a particular setting is applicable to a particular
settings block.
Restrict DHCP-backed settings blocks to accepting only DHCP-based
settings.
Restrict network device settings blocks to accepting only DHCP-based
settings and network device-specific settings such as "mac".
Inspired-by: Glenn Brown <glenn@myri.com>
Signed-off-by: Michael Brown <mcb30@ipxe.org>
[console] Try to avoid problems caused by keycode 86
The "us" keyboard layout contains a mapping for keycode 86 (which
seems not to correspond to any physical key on many US keyboards) to
the ASCII character '<'. This mapping causes conflicts with the
mapping for keycode 51, which also maps (with shift) to '<'.
Change the keyboard mapping generator to choose the lowest keycode for
each ASCII character as indicating the relevant mapping to use, on the
basis that a lower keycode roughly indicates a "more normal" key. On
a German keyboard, which has keys for both keycode 51 and keycode 86
present, this causes '<' to be remapped to ';', which is a closer
match to typical user expectations.
Reported-by: Sven Dreyer <sven@dreyer-net.de>
Signed-off-by: Michael Brown <mcb30@ipxe.org>
From a cursory examination, it appears as though the calculation of
tx_available is redundant, since eepro_transmit() waits for transmit
completion before returning anyway.
Reported-by: Ralph Giles <giles@thaumas.net>
Tested-by: Ralph Giles <giles@thaumas.net>
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Michael Brown