Michael Brown [Wed, 24 Oct 2012 20:26:51 +0000 (13:26 -0700)]
[netdevice] Do not force a poll on net_tx()
Including a netdev_poll() within net_tx() can cause the net_step()
loop to end up processing hundreds or thousands of packets within a
single step, since each received packet being processed may trigger a
response which, in turn causes a poll for further received packets.
Network devices must now ensure that the TX ring is at least as large
as the RX ring, in order to avoid running out of TX descriptors. This
should not cause any problems; unlike the RX ring, there is no
substantial memory cost incurred by increasing the TX ring size.
Michael Brown [Sat, 20 Oct 2012 21:44:34 +0000 (14:44 -0700)]
[test] Remove self-test for empty formatted setting value
Commit 5ad445f ("[settings] Treat an empty formatted value as meaning
"delete setting"") (re)defined the semantics of storing an empty
formatted setting as meaning "delete setting".
Remove the existing self-test using an empty formatted hex setting
value, since it no longer conforms to the defined semantics.
Shao Miller [Fri, 5 Oct 2012 14:14:12 +0000 (15:14 +0100)]
[serial] Don't enable serial console without serial support
serial_console_init() would enable serial console support without
knowing if the serial driver succeeded or not. As a result, the
serial console would interfere with a normal keyboard on a system
lacking serial support.
Reported-by: Jan ONDREJ (SAL) <ondrejj(at)salstar.sk> Signed-off-by: Shao Miller <sha0.miller@gmail.com> Signed-off-by: Michael Brown <mcb30@ipxe.org>
Michael Brown [Fri, 5 Oct 2012 14:02:30 +0000 (15:02 +0100)]
[int13] Do not zero %edx when jumping to a boot sector
Commit 73eb3f1 ("[int13] Zero all possible registers when jumping to a
boot sector") introduced a regression preventing the SAN-booting of
boot sectors which rely upon %dl containing the correct drive number
(such as most CD-ROM boot sectors).
Michael Brown [Wed, 26 Sep 2012 20:42:23 +0000 (21:42 +0100)]
[tls] Split received records over multiple I/O buffers
TLS servers are not obliged to implement the RFC3546 maximum fragment
length extension, and many common servers (including OpenSSL, as used
in Apache's mod_ssl) do not do so. iPXE may therefore have to cope
with TLS records of up to 16kB. Allocations for 16kB have a
non-negligible chance of failing, causing the TLS connection to abort.
Fix by maintaining the received record as a linked list of I/O
buffers, rather than a single contiguous buffer. To reduce memory
pressure, we also decrypt in situ, and deliver the decrypted data via
xfer_deliver_iob() rather than xfer_deliver_raw().
Michael Brown [Fri, 14 Sep 2012 16:49:53 +0000 (17:49 +0100)]
[efi] Provide guaranteed space in transmitted packets
eIPoIB requires space to expand a transmitted ARP packet. This
guarantee is met by ensuring that a transmitted packet consists of at
least MAX_LL_HEADER_LEN bytes from the start of the I/O buffer up to
the end of the link-layer header, and at least IOB_ZLEN bytes
thereafter.
Adjust the I/O buffer allocation for SNP transmitted packets to ensure
that this guarantee is met.
Michael Brown [Fri, 14 Sep 2012 14:42:54 +0000 (15:42 +0100)]
[int13] Zero all possible registers when jumping to a boot sector
At least one boot sector (the DUET boot sector used for bootstrapping
EFI from a non-EFI system) fails to initialise the high words of
registers before using them in calculations, leading to undefined
behaviour.
Work around such broken boot sectors by explicitly zeroing the
contents of all registers apart from %cs:%ip and %ss:%sp.
Michael Brown [Fri, 31 Aug 2012 02:52:06 +0000 (03:52 +0100)]
[settings] Use a generic setting's own type as its default type
When fetching a named setting using a name that does not explicitly
specify a type, default to using the type stored when the setting was
created, rather than always defaulting to "string". This allows the
behaviour of user-defined settings to match the behaviour of
predefined settings (which have a sensible default type).
For example:
set server:ipv4 192.168.0.1
echo ${server}
will now print "192.168.0.1", rather than trying to print out the raw
IPv4 address bytes as a string.
The downside of this change is that existing tricks for printing
special characters within scripts may require (backwards-compatible)
modification. For example, the "clear screen" sequence:
set esc:hex 1b
set cls ${esc}[2J
echo ${cls}
will now have to become
set esc:hex 1b
set cls ${esc:string}[2J # Must now explicitly specify ":string"
echo ${cls}
Michael Brown [Wed, 29 Aug 2012 22:34:14 +0000 (23:34 +0100)]
[ipoib] Expose Ethernet-compatible eIPoIB link-layer addresses and headers
Almost all clients of the raw-packet interfaces (UNDI and SNP) can
handle only Ethernet link layers. Expose an Ethernet-compatible link
layer to local clients, while remaining compatible with IPoIB on the
wire. This requires manipulation of ARP (but not DHCP) packets within
the IPoIB driver.
This is ugly, but it's the only viable way to allow IPoIB devices to
be driven via the raw-packet interfaces.
Michael Brown [Fri, 24 Aug 2012 15:44:29 +0000 (16:44 +0100)]
[realtek] Force EEPROM CS low before disabling EEPROM access mode
Some RTL8169 cards seem to drive the EEPROM CS line high (i.e. active)
when 9346CR.EEM is set to "normal operating mode", with the result
that the CS line is never deasserted. The symptom of this is that the
first read from the EEPROM will work, while all subsequent reads will
return garbage data.
Reported-by: Thomas Miletich <thomas.miletich@gmail.com> Debugged-by: Thomas Miletich <thomas.miletich@gmail.com> Tested-by: Thomas Miletich <thomas.miletich@gmail.com> Signed-off-by: Michael Brown <mcb30@ipxe.org>
Michael Brown [Thu, 23 Aug 2012 21:44:20 +0000 (22:44 +0100)]
[realtek] Forcibly enable advertisement of 1000Mbps speeds
Some RTL8169 cards (observed with an RTL8169SC) power up advertising
only 100Mbps, despite being capable of 1000Mbps. Forcibly enable
advertisement of 1000Mbps on any RTL8169-like card.
This change relies on the assumption that the CTRL1000 register will
not exist on 100Mbps-only RTL8169 cards such as the RTL8101.
Michael Brown [Thu, 23 Aug 2012 12:35:19 +0000 (13:35 +0100)]
[realtek] Enable DAC only when built as a 64-bit binary
Some RTL8169 cards (observed with an RTL8169SC) crash and burn if DAC
is enabled, even if only 32-bit addresses are used. Observed
behaviour includes system lockups and repeated transmission of garbage
data onto the wire.
This seems to be a known problem. The Linux r8169 driver disables DAC
by default and provides a "use_dac" module parameter.
There appears to be no known test for determining whether or not DAC
will work. As a workaround, enable DAC only if we are built as as
64-bit binary. This at least eliminates the problem in the common
case of a 32-bit build, which will never use 64-bit addresses anyway.
Michael Brown [Thu, 23 Aug 2012 12:27:31 +0000 (13:27 +0100)]
[realtek] Use explicit value for TCR.MXDMA
Some RTL8169 cards (observed with an RTL8169SC) power up with
TCR.MXDMA set to 16 bytes. While this does not prevent proper
operation, it almost certainly degrades performance.
Fix by explicitly setting TCR.MXDMA to "unlimited".
Michael Brown [Thu, 23 Aug 2012 11:25:08 +0000 (12:25 +0100)]
[realtek] Use explicit values for RCR.RXFTH and RCR.MXDMA
Some RTL8169 cards (observed with an RTL8169SC) power up with invalid
values in RCR.RXFTH and RCR.MXDMA, causing receive DMA to fail. Fix
by setting explicit values for both fields.
Michael Brown [Fri, 17 Aug 2012 17:00:40 +0000 (18:00 +0100)]
[http] Fix HTTP SAN booting
Commit 501527d ("[http] Treat any unexpected connection close as an
error") introduced a regression causing HTTP SAN booting to fail. At
the end of the response to the HEAD request, the call to http_done()
would erroneously believe that the server had disconnected in the
middle of the HTTP headers.
Fix by treating the header block from a HEAD request as a trailer
block. This fixes the problem and also simplifies the logic in
http_rx_header().
Reported-by: Shao Miller <shao.miller@yrdsb.edu.on.ca> Signed-off-by: Michael Brown <mcb30@ipxe.org>
Marin Hannache [Wed, 15 Aug 2012 16:04:41 +0000 (17:04 +0100)]
[ftp] Add support for the FTP SIZE command
The FTP SIZE command allows us to get the size of a particular file,
as a consequence, we can now show proper transfer progression while
fetching a file using the FTP protocol.
Signed-off-by: Marin Hannache <git@mareo.fr> Modified-by: Michael Brown <mcb30@ipxe.org> Signed-off-by: Michael Brown <mcb30@ipxe.org>
Michael Brown [Wed, 15 Aug 2012 15:29:22 +0000 (16:29 +0100)]
[http] Treat any unexpected connection close as an error
iPXE currently checks that the server has not closed the connection
mid-stream (i.e. in the middle of a chunked transfer, or before the
specified Content-Length has been received), but does not check that
the server got as far as starting to send data. Consequently, if the
server closes the connection before any data is transferred (e.g. if
the server gives up waiting while iPXE performs the validation steps
for TLS), then iPXE will treat this as a successful transfer of a
zero-length file.
Fix by checking the RX connection state, and forcing an error if the
server has closed the connection at an unexpected point.
Originally-fixed-by: Marin Hannache <mareo@mareo.fr> Signed-off-by: Michael Brown <mcb30@ipxe.org>
Michael Brown [Wed, 15 Aug 2012 12:20:02 +0000 (13:20 +0100)]
[util] Fix up checksum in UNDI ROM header, if present
The UNDI ROM header does contain a checksum byte. Apparently no-one
cares about this, since iPXE has left it as zero for years without
anyone noticing.
Since Option::ROM now understands the UNDI ROM header, we may as well
fix up the checksum byte for the sake of completeness.
Daniel Wyatt [Wed, 15 Aug 2012 11:50:01 +0000 (12:50 +0100)]
[util] Allow for CALL NEAR in the option ROM initialisation entry point
Option::ROM currently understands only JMP NEAR and JMP SHORT
instructions in the initialisation entry point. At least one Broadcom
option ROM has been observed to use a CALL NEAR instruction.
Michael Brown [Mon, 13 Aug 2012 21:14:57 +0000 (22:14 +0100)]
[comboot] Accept only ".cbt" as an extension for COMBOOT images
COMBOOT images are detected by looking for a ".com" or ".cbt" filename
extension. There are widely-used files with a ".com" extension, such
as "wdsnbp.com", which are PXE images rather than COMBOOT images.
Avoid false detection of PXE images as COMBOOT images by accepting
only a ".cbt" extension as indicating a COMBOOT image.
Interestingly, this bug has been present for a long time but was
frequently concealed because the filename was truncated to fit the
fixed-length "name" field in struct image. (PXE binaries ending in
".com" tend to be related to Windows deployment products and so often
use pathnames including backslashes, which iPXE doesn't recognise as a
path separator and so treats as part of a very long filename.)
Commit 1c127a6 ("[image] Simplify image management commands and
internal API") made the image name a variable-length field, and so
exposed this flaw in the COMBOOT image detection algorithm.
Michael Brown [Wed, 25 Jul 2012 13:32:37 +0000 (14:32 +0100)]
[romprefix] Round up PMM allocation sizes to nearest 4kB
Some AMI BIOSes apparently break in exciting ways when asked for PMM
allocations for sizes that are not multiples of 4kB.
Fix by rounding up the image source area to the nearest 4kB. (The
temporary decompression area is already rounded up to the nearest
128kB, to facilitate sharing between multiple iPXE ROMs.)
Reported-by: Itay Gazit <itayg@mellanox.com> Signed-off-by: Michael Brown <mcb30@ipxe.org>
Michael Brown [Mon, 23 Jul 2012 16:41:38 +0000 (17:41 +0100)]
[romprefix] Report a pessimistic runtime size estimate
PCI3.0 allows us to report a "runtime size" which can be smaller than
the actual ROM size. On systems that support PMM our runtime size
will be small (~2.5kB), which helps to conserve the limited option ROM
space. However, there is no guarantee that the PMM allocation will
succeed, and so we need to report the worst-case runtime size in the
PCI header.
Move the "shrunk ROM size" field from the PCI header to a new "iPXE
ROM header", allowing it to be accessed by ROM-manipulation utilities
such as disrom.pl.
Reported-by: Anton D. Kachalov <mouse@yandex-team.ru> Signed-off-by: Michael Brown <mcb30@ipxe.org>
[contrib] Fix rom-o-matic git version number issues
Fixes issue in which git version number is not displayed on startup
when iPXE is built through rom-o-matic.
Remove special characters from filename generated by rom-o-matic (so
that you get "ipxe-1.0.0+c3b4-undionly.kkpxe" instead of
"ipxe-1.0.0+ (c3b4)-undionly.kkpxe")
Michael Brown [Fri, 20 Jul 2012 17:32:58 +0000 (18:32 +0100)]
[isa] Avoid spurious compiler warning on gcc 4.7
gcc 4.7 produces a spurious warning about an array subscript being out
of bounds. Use a pointer dereference instead of an array lookup to
inhibit this spurious warning.
Michael Brown [Fri, 20 Jul 2012 11:36:41 +0000 (12:36 +0100)]
[image] Add "--replace" option
Expose image tail-recursion to iPXE scripts via the "--replace"
option. This functions similarly to exec() under Unix: the
currently-executing script is replaced with the new image (as opposed
to running the new image as a subroutine).
Michael Brown [Wed, 18 Jul 2012 17:18:28 +0000 (18:18 +0100)]
[pxeprefix] Ignore errors from PXENV_FILE_CMDLINE
PXENV_FILE_CMDLINE is an iPXE extension, and will not be supported by
most PXE stacks. Do not report any errors to the user, since in
almost all cases the error will mean simply "not loaded by iPXE".
Reported-by: Patrick Domack <patrickdk@patrickdk.com> Signed-off-by: Michael Brown <mcb30@ipxe.org>
Michael Brown [Thu, 12 Jul 2012 15:04:41 +0000 (16:04 +0100)]
[pxe] Reopen network device if NBP exits
Attempt to restore the network device to the state it was in prior to
calling the NBP. This simplifies the task of taking follow-up action
in an iPXE script.