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.
Michael Brown [Tue, 10 Jul 2012 15:10:49 +0000 (16:10 +0100)]
[pxeprefix] Place temporary stack after iPXE binary
Some BIOSes (observed on a Supermicro system with an AMI BIOS) seem to
use the area immediately below 0x7c00 to store data related to the
boot process. This data is currently liable to be overwritten by the
temporary stack used while decompressing and installing iPXE.
Try to avoid any such problems by placing the temporary stack
immediately after the loaded iPXE binary. Any memory used by the
stack could then potentially have been overwritten anyway by a larger
binary.
Michael Brown [Tue, 10 Jul 2012 09:52:56 +0000 (10:52 +0100)]
[intel] Explicitly enable descriptor queues
On i350 the datasheet contradicts itself in stating that the default
value of RXDCTL.ENABLE for queue zero is both set (according to the
"Receive Initialization" section) and unset (according to the "Receive
Descriptor Control - RXDCTL" section). Empirical evidence suggests
that the default value is unset.
Explicitly enable both transmit and receive queues to avoid any
ambiguity.
Michael Brown [Tue, 10 Jul 2012 08:32:58 +0000 (09:32 +0100)]
[intel] Refill receive ring only after enabling receiver
On 82576 (and probably others), the datasheet states that "the tail
register of the queue (RDT[n]) should not be bumped until the queue is
enabled". There is some confusion over exactly what constitutes
"enabled": the initialisation blurb says that we should "poll the
RXDCTL register until the ENABLE bit is set", while the description
for the RXDCTL register says that the ENABLE bit is set by default
(for queue zero). Empirical evidence suggests that the ENABLE bit
reads as set immediately after writing to RCTL.EN, and so polling is
not necessary.
Michael Brown [Mon, 9 Jul 2012 19:26:40 +0000 (20:26 +0100)]
[bzimage] Update setup_move_size only for protocol versions 2.00 and 2.01
The setup_move_size field is not defined in protocol versions earlier
than 2.00 (and is obsolete in versions later than 2.01). In binaries
using versions earlier than 2.00, the relevant location is likely to
contain executable code.
Interestingly, this bug has been present since support for pre-2.00
protocol versions was added in 2009, and has been unexpectedly
modifying the memtest86+ code fragment:
mov $0x92, %dx
inb %dx, %al
Fortuitously, the modification exactly overwrote the value loaded into
%dx, and so the net effect was limited to causing Fast Gate A20
detection to always fail.
Michael Brown [Sun, 8 Jul 2012 16:54:07 +0000 (17:54 +0100)]
[tcp] Increase maximum window size to 256kB
A window size of 256kB should be sufficient to allow for
full-bandwidth transfers over a Gigabit LAN, and for acceptable
transfer speeds over other typical links.
Michael Brown [Sun, 8 Jul 2012 16:20:25 +0000 (17:20 +0100)]
[malloc] Increase heap size to 512kB
The maximum TCP throughput is fundamentally limited by the amount of
available receive buffer space. Increase the heap size from 128kB to
512kB to allow the use of larger TCP windows.
Michael Brown [Sun, 8 Jul 2012 15:51:21 +0000 (16:51 +0100)]
[tcp] Truncate TCP window to prevent future packet discards
Whenever memory pressure causes a queued packet to be discarded (and
so retransmitted), reduce the maximum TCP window to a size that would
have prevented the discard.
Michael Brown [Mon, 9 Jul 2012 08:55:26 +0000 (09:55 +0100)]
[arp] Try to avoid discarding ARP cache entries
Discarding the active ARP cache entry in the middle of a download will
substantially disrupt the TCP stream. Try to minimise any such
disruption by treating ARP cache entries as expensive, and discarding
them only when nothing else is available to discard.
Michael Brown [Sun, 8 Jul 2012 16:14:08 +0000 (17:14 +0100)]
[iobuf] Allocate I/O buffer descriptor separately to conserve aligned memory
I/O buffers are allocated on aligned boundaries. The I/O buffer
descriptor (the struct io_buffer) is currently attached to the end of
the I/O buffer. When the size of the buffer is close to its
alignment, this can waste large amounts of aligned memory.
For example, a network card using 2048-byte receive buffers will end
up allocating 2072 bytes on a 2048-byte boundary. This effectively
wastes 50% of the available memory.
Improve the situation by allocating the descriptor separately from the
main I/O buffer if inline allocation would cause the total allocated
size to cross the alignment boundary.
Michael Brown [Sun, 1 Jul 2012 21:47:06 +0000 (22:47 +0100)]
[netdevice] Process all received packets in net_poll()
The current logic is to process at most one received packet per call
to net_poll(), on the basis that refilling the hardware descriptor
ring should be delayed as little as possible. However, this limits
the rate at which packets can be processed and ultimately ends up
adding latency which, in turn, limits the achievable throughput.
With temporary modifications in place to essentially remove all
resource constraints (heap size increased to 16MB, RX descriptor ring
increased to 64 descriptors) and a TCP window size of 1MB, the
throughput on a gigabit (i.e. 119MBps) network can be observed to fall
off exponentially from around 115MBps to around 75MBps. Changing
net_poll() to process all received packets results in a steady
119MBps throughput.
projects / thirdparty / ipxe.git / log
