Michael Brown [Tue, 30 Apr 2013 13:31:39 +0000 (14:31 +0100)]
[romprefix] Report failure cause when unable to open payload
Report the cause of the failure when we are unable to open the .mrom
payload. There are two possible failure cases:
- Unable to find a suitable memory BAR to borrow (e.g. if the NIC
doesn't have a memory BAR that is at least as large as the
expansion ROM BAR, or if the memory BAR has been assigned a 64-bit
address which won't fit into the 32-bit expansion ROM BAR). This
will be reported as "BABABABA".
- Unable to find correct ROM image within the BAR. This will be
reported as the address (within the borrowed BAR) at which we first
fail to find a valid 55AA signature.
Michael Brown [Tue, 30 Apr 2013 12:36:04 +0000 (13:36 +0100)]
[realtek] Allow reaction time between writing RTL_CAPR and reading RTL_CR
Some older RTL8139 chips seem to not immediately update the
RTL_CR.BUFE bit in response to a write to RTL_CAPR. This results in
iPXE seeing a spurious zero-length received packet, and thereafter
being out of sync with the hardware's RX ring offset.
Fix by inserting an extra PCI read cycle after writing to RTL_CAPR, to
give the chip time to react before we next read RTL_CR.
Reported-by: Gelip <mrgelip@gmail.com> Tested-by: Gelip <mrgelip@gmail.com> Signed-off-by: Michael Brown <mcb30@ipxe.org>
Michael Brown [Sun, 28 Apr 2013 17:50:10 +0000 (18:50 +0100)]
[realtek] Use ID word to detect EEPROM presence
Some onboard RTL8169 NICs seem to leave the EEPROM pins disconnected.
The existing is_valid_ether_addr() test will not necessarily catch
this, since it expects a missing EEPROM to show up as a MAC address of
00:00:00:00:00:00 or ff:ff:ff:ff:ff:ff. When the EEPROM pins are
floating the MAC address may read as e.g. 00:00:00:00:0f:00, which
will not be detected as invalid.
Check the ID word in the first two bytes of the EEPROM (which should
have the value 0x8129 for all RTL8139 and RTL8169 chips), and use this
to determine whether or not an EEPROM is present.
Reported-by: Carl Karsten <carl@nextdayvideo.com> Tested-by: Carl Karsten <carl@nextdayvideo.com> Signed-off-by: Michael Brown <mcb30@ipxe.org>
Michael Brown [Sun, 28 Apr 2013 16:43:37 +0000 (17:43 +0100)]
[build] Default to short wchar_t in stddef.h
sparse does not understand -fshort-wchar. Default to using uint16_t
as a wchar_t if not explicitly specified by the compiler, to avoid
large numbers of spurious warnings from sparse.
Michael Brown [Sun, 28 Apr 2013 15:43:32 +0000 (16:43 +0100)]
[build] Use -Wno-decl when running sparse
Linker table entries must be non-static in order to avoid being
completely optimised away by some versions of gcc. Use -Wno-decl to
prevent sparse from warning about these, since the alternative would
be to litter the code with otherwise unnecessary "extern"
declarations.
Michael Brown [Thu, 25 Apr 2013 13:51:33 +0000 (14:51 +0100)]
[build] Define __WINT_TYPE__ if necessary
sparse does not define __WCHAR_TYPE__ or __WINT_TYPE__. We already
define __WCHAR_TYPE__ if the compiler does not do so; do the same for
__WINT_TYPE__.
Michael Brown [Thu, 25 Apr 2013 12:45:41 +0000 (13:45 +0100)]
[build] Allow sparse to find compiler.h
sparse seems to have problems finding compiler.h when specified as
"-include compiler.h"; one possible explanation is that it ignores the
include path. Fix by using "-include include/compiler.h".
Michael Brown [Fri, 19 Apr 2013 13:26:12 +0000 (14:26 +0100)]
[netdevice] Use link-layer address as part of RNG seed
iPXE currently seeds the random number generator using the system
timer tick count. When large numbers of machines are booted
simultaneously, multiple machines may end up choosing the same DHCP
transaction ID (XID) value; this can cause problems.
Fix by using the least significant (and hence most variable) bits of
each network device's link-layer address to perturb the random number
generator. This introduces some per-machine unique data into the
random number generator's seed, and so reduces the chances of DHCP XID
collisions.
This does not affect the ANS X9.82-compatible random bit generator
used by TLS and other cryptography code, which uses an entirely
separate source of entropy.
Originally-implemented-by: Bernhard Kohl <bernhard.kohl@nsn.com> Signed-off-by: Michael Brown <mcb30@ipxe.org>
Add disambiguated errors for LoadImage() and StartImage(), primarily
to demonstrate how to use __einfo_uniqify() and __einfo_platformify()
in the context of EFI platform errors.
Michael Brown [Thu, 18 Apr 2013 20:29:53 +0000 (21:29 +0100)]
[efi] Perform meaningful error code conversions
Exploit the redefinition of iPXE error codes to include a "platform
error code" to allow for meaningful conversion of EFI_STATUS values to
iPXE errors and vice versa.
Michael Brown [Fri, 19 Apr 2013 12:34:13 +0000 (13:34 +0100)]
[libc] Redefine low 8 bits of error code as "platform error code"
The low 8 bits of an iPXE error code are currently defined as the
closest equivalent PXE error code. Generalise this scheme to
platforms other than PC-BIOS by extending this definition to "closest
equivalent platform error code". This allows for the possibility of
returning meaningful errors via EFI APIs.
Michael Brown [Wed, 3 Apr 2013 14:21:03 +0000 (15:21 +0100)]
[intel] Expose functionality to be shared with intelx driver
The Intel 10 Gigabit NICs have a datapath that is almost
register-compatible with the Intel 1 Gigabit NICs. Expose common
functionality to avoid duplication of code in the new "intelx" driver.
Michael Brown [Wed, 3 Apr 2013 14:20:55 +0000 (15:20 +0100)]
[intel] Remove hardcoded offsets for descriptor ring registers
The Intel 10 Gigabit NICs use the same simplified (aka "legacy")
descriptor format and the same layout for descriptor register blocks
as the Intel 1 Gigabit NICs. The offsets of the descriptor register
blocks are not the same.
Simplify reuse of the existing code by removing all hardcoded offsets
for registers within descriptor register blocks, and ensuring that all
offsets are calculated using the descriptor register block base
address provided via intel_init_ring().
Michael Brown [Wed, 17 Apr 2013 18:36:03 +0000 (19:36 +0100)]
[bios] Fix screen clearing on buggy BIOSes
The implementation of INT 10,06 on some BIOSes (observed with both
Hyper-V and a Dell OptiPlex 7010) seems to treat %dx=0xffff as a
special value meaning "do absolutely nothing". Fix by using
%dx=0xfefe, which should still be sufficient to cover any realistic
screen size.
Reported-by: John Clark <skyman@iastate.edu> Tested-by: John Clark <skyman@iastate.edu> Signed-off-by: Michael Brown <mcb30@ipxe.org>
Michael Brown [Sat, 6 Apr 2013 10:27:27 +0000 (11:27 +0100)]
[settings] Expose build architecture and platform via settings
Expose the build architecture (e.g. "i386" or "x86_64") via
${buildarch} and the firmware platform (e.g. "pcbios" or "efi") via
${platform}. These settings directly expose the ARCH and PLATFORM
variables from the Makefile.
Note that the build architecture reflects the architecture for which
iPXE was compiled, not the architecture on which iPXE is currently
running. The "cpuid" command can be used to detect a 64-bit system at
runtime.
Requested-by: James A. Peltier <jpeltier@sfu.ca> Signed-off-by: Michael Brown <mcb30@ipxe.org>
Michael Brown [Mon, 25 Mar 2013 18:02:20 +0000 (18:02 +0000)]
[prism2] Use standard type names
Avoid using UINT16 and similar typedefs, which are non-standard in the
iPXE codebase and generate conflicts when trying to include any of the
EFI headers.
Also fix trailing whitespace in the affected files, to prevent
complaints from git.
Michael Brown [Fri, 22 Mar 2013 13:42:16 +0000 (13:42 +0000)]
[efi] Add "reboot" command for EFI
Abstract out the ability to reboot the system to a separate reboot()
function (with platform-specific implementations), add an EFI
implementation, and make the existing "reboot" command available under
EFI.
Michael Brown [Wed, 20 Mar 2013 00:54:42 +0000 (00:54 +0000)]
[dhcp] Use PXE byte ordering for UUID in DHCP option 97
The PXE spec does not specify a byte ordering for UUIDs, but RFC4578
suggests that it follows the EFI spec, in which the first three fields
are little-endian.
Michael Brown [Wed, 20 Mar 2013 00:14:38 +0000 (00:14 +0000)]
[smbios] Mangle UUIDs for SMBIOS version 2.6 and newer
iPXE treats UUIDs as being in network byte order (big-endian). The
SMBIOS specification version 2.6 states that UUIDs are stored with
little-endian values in the first three fields; earlier versions did
not specify an endianness. This results in some inconsistency between
the BIOS, vendor PXE, iPXE, and operating system interpretations of
the SMBIOS UUID.
dmidecode assumes that the byte order is little-endian if and only if
the SMBIOS version is 2.6 or higher. Choose to match this behaviour.
Reported-by: Matthew Helton <mwhelton@gmail.com> Reported-by: Alexandru Bordei <alexandru.bordei@gmail.com> Signed-off-by: Michael Brown <mcb30@ipxe.org>
Michael Brown [Fri, 15 Mar 2013 15:22:57 +0000 (15:22 +0000)]
[lkrnprefix] Allow relocation when no initrd is present
Commit 2629b7e ("[pcbios] Inhibit all calls to INT 15,e820 and INT
15,e801 during POST") introduced a regression into .lkrn images when
used with no corresponding initrd.
Specifically, the semantics of the "maximum address for relocation"
value passed to install_prealloc() in %ebp changed so that zero became
a special value meaning "inhibit use of INT 15,e820 and INT 15,e801".
The %ebp value meaing "no upper limit on relocation" was changed from
zero to 0xffffffff, and all prefixes providing fixed values for %ebp
were updated to match the new semantics.
The .lkrn prefix provides the initrd base address as the maximum
address for relocation. When no initrd is present, this address will
be zero, and so will unintentionally trigger the "inhibit INT 15,e820
and INT 15,e801" behaviour.
Fix by explicitly setting %ebp to 0xffffffff if no initrd is present
before calling install_prealloc().
Reported-by: Ján ONDREJ (SAL) <ondrejj@salstar.sk> Tested-by: Ján ONDREJ (SAL) <ondrejj@salstar.sk> Signed-off-by: Michael Brown <mcb30@ipxe.org>
Michael Brown [Thu, 14 Mar 2013 00:20:04 +0000 (00:20 +0000)]
[efi] Fix building with newer binutils
Newer versions of bfd.h require definitions for the PACKAGE and
PACKAGE_VERSION macros used by autotools. Work around this by
manually defining these macros before including bfd.h.
Originally-fixed-by: Brandon Penglase <bpenglase-ipxe@spaceservices.net> Tested-by: Brandon Penglase <bpenglase-ipxe@spaceservices.net> Signed-off-by: Michael Brown <mcb30@ipxe.org>
Michael Brown [Wed, 13 Mar 2013 22:42:26 +0000 (22:42 +0000)]
[efi] Add our own EFI_LOAD_FILE_PROTOCOL implementation
When iPXE is used as a UEFI driver, the UEFI PXE base code currently
provides the TCP/IP stack, network protocols, and user interface.
This represents a substantial downgrade from the standard BIOS iPXE
user experience.
Fix by installing our own EFI_LOAD_FILE_PROTOCOL implementation which
initiates the standard iPXE boot procedure. This upgrades the UEFI
iPXE user experience to match the standard BIOS iPXE user experience.
Michael Brown [Wed, 13 Mar 2013 22:36:32 +0000 (22:36 +0000)]
[efi] Expose downloaded images via EFI_SIMPLE_FILE_SYSTEM_PROTOCOL
Expose iPXE's images as a UEFI file system, allowing the booted image
to access all images downloaded by iPXE.
This functionality is complementary to the custom iPXE download
protocol. The iPXE download protocol allows a booted image to utilise
iPXE to download arbitrary URIs, but requires the booted image to
specifically support the custom iPXE download protocol. The new
functionality limits the booted image to accessing only files that
were already downloaded by iPXE (e.g. as part of a script), but can
work with any generic UEFI image (e.g. the UEFI shell). Both
protocols are provided simultaneously, and are attached to the SNP
device handle.
Michael Brown [Mon, 11 Mar 2013 01:43:12 +0000 (01:43 +0000)]
[romprefix] Display only one "Ctrl-B" prompt per PCI device during POST
If a multifunction PCI device exposes an iPXE ROM via each function,
then each function will display a "Press Ctrl-B to configure iPXE"
prompt, and delay for two seconds. Since a single instance of iPXE
can drive all functions on the multifunction device, this simply adds
unnecessary delay to the boot process.
Fix by inhibiting the "Press Ctrl-B" prompt for all except the first
function on a PCI device.
Michael Brown [Mon, 11 Mar 2013 00:50:52 +0000 (00:50 +0000)]
[pcbios] Inhibit all calls to INT 15,e820 and INT 15,e801 during POST
Many BIOSes do not construct the full system memory map until after
calling the option ROM initialisation entry points. For several
years, we have added sanity checks and workarounds to accommodate
charming quirks such as BIOSes which report the entire 32-bit address
space (including all memory-mapped PCI BARs) as being usable RAM.
The IBM x3650 takes quirky behaviour to a new extreme. Calling either
INT 15,e820 or INT 15,e801 during POST doesn't just get you invalid
data. We could cope with invalid data. Instead, these nominally
read-only API calls manage to trash some internal BIOS state, with the
result that the system memory map is _never_ constructed. This tends
to confuse subsequent bootloaders and operating systems.
[ GRUB 0.97 fails in a particularly amusing way. Someone thought it
would be a good idea for memcpy() to check that the destination memory
region is a valid part of the system memory map; if not, then memcpy()
will sulk, fail, and return NULL. This breaks pretty much every use
of memcpy() including, for example, those inserted implicitly by gcc
to copy non-const initialisers. Debugging is _fun_ when a simple call
to printf() manages to create an infinite recursion, exhaust the
available stack space, and shut down the CPU. ]
Fix by completely inhibiting calls to INT 15,e820 and INT 15,e801
during POST.
We do now allow relocation during POST up to the maximum address
returned by INT 15,88 (which seems so far to always be safe). This
allows us to continue to have a reasonable size of external heap, even
if the PMM allocation is close to the 1MB mark.
The downside of allowing relocation during POST is that we may
overwrite PMM-allocated memory in use by other option ROMs. However,
the downside of inhibiting relocation, when combined with also
inhibiting calls to INT 15,e820 and INT 15,e801, would be that we
might have no external heap available: this would make booting an OS
impossible and could prevent some devices from even completing
initialisation.
On balance, the lesser evil is probably to allow relocation during
POST (up to the limit provided by INT 15,88). Entering iPXE during
POST is a rare operation; on the even rarer systems where doing so
happens to overwrite a PMM-allocated region, then there exists a
fairly simple workaround: if the user enters iPXE during POST and
wishes to exit iPXE, then the user must reboot. This is an acceptable
cost, given the rarity of the situation and the simplicity of the
workaround.
Michael Brown [Fri, 8 Mar 2013 13:26:22 +0000 (13:26 +0000)]
[prefix] Use %cs as implicit parameter to uninstall()
romprefix.S currently calls uninstall() with an invalid value in %ax.
Consequently, base memory is not freed after a ROM boot attempt (or
after entering iPXE during POST).
The uninstall() function is physically present in .text16, and so can
use %cs to determine the .text16 segment address. The .data16 segment
address is not required, since uninstall() is called only by code
paths which set up .data16 to immediately follow .text16.
Michael Brown [Wed, 6 Mar 2013 17:35:30 +0000 (17:35 +0000)]
[tftp] Allow TFTP block size to be controlled via the PXE TFTP API
The PXE TFTP API allows the caller to request a particular TFTP block
size. Since mid-2008, iPXE has appended a "?blksize=xxx" parameter to
the TFTP URI constructed internally; nothing has ever parsed this
parameter. Nobody seems to have cared that this parameter has been
ignored for almost five years.
Fix by using xfer_window(), which provides a fairly natural way to
convey the block size information from the PXE TFTP API to the TFTP
protocol layer.
Michael Brown [Wed, 6 Mar 2013 15:05:30 +0000 (15:05 +0000)]
[menu] Prevent separators with shortcut keys from being selected
Nothing currently prevents a menu separator from being assigned a
shortcut key, and then from being selected using that shortcut key.
This produces an inconsistency in the user interface, since separators
cannot be selected by other means of menu navigation (arrow keys, page
up/down, etc).
It would be trivial to prevent separators from being assigned shortcut
keys, but this would eliminate one potentially useful use case: having
a large menu and using shortcut keys to jump to a section within the
menu.
Fix by treating a shortcut key on a separator as equivalent to "select
the separator, then press the down arrow key". This has the effect of
moving to the first non-separator menu item following the specified
separator, which is probably the most intuitive behaviour. (The
existing logic for moving the selection already handles the various
nasty corner cases such as a menu ending with one or more separators.)
Reported-by: Ján ONDREJ (SAL) <ondrejj@salstar.sk> Signed-off-by: Michael Brown <mcb30@ipxe.org>
Michael Brown [Wed, 6 Mar 2013 14:41:46 +0000 (14:41 +0000)]
[menu] Prevent character code zero from acting as a shortcut key
Unrecognised keys may be returned by getkey() as character code zero,
which currently matches against the first menu item with no shortcut
key defined.
Prevent this unintended behaviour by explicitly checking that the menu
item has a defined shortcut key.
Reported-by: Ján ONDREJ (SAL) <ondrejj@salstar.sk> Signed-off-by: Michael Brown <mcb30@ipxe.org>
[zbin] Fix size used for memset in alloc_output_file
The output->buf field is a pointer, not an array, so sizeof() is not
applicable. We must use the allocated string length instead.
Identified by gcc:
util/zbin.c: In function ‘alloc_output_file’:
util/zbin.c:146:37: warning: argument to ‘sizeof’ in ‘memset’ call
is the same expression as the destination; did you mean to
dereference it? [-Wsizeof-pointer-memaccess]
memset ( output->buf, 0xff, sizeof ( output->buf ) );
Signed-off-by: Daniel P. Berrange <berrange@redhat.com> Signed-off-by: Michael Brown <mcb30@ipxe.org>
Michael Brown [Tue, 5 Mar 2013 14:22:53 +0000 (14:22 +0000)]
[undi] Work around specific devices with known broken interrupt behaviour
Some PXE stacks are known to claim that IRQs are supported, but then
never generate interrupts. No satisfactory solution has been found to
this problem; the workaround is to add the PCI vendor and device IDs
to a list of devices which will be treated as simply not supporting
interrupts.
This is something of a hack, since it will generate false positives
for identical devices with a working PXE stack (e.g. those that have
been reflashed with iPXE), but it's an improvement on the current
situation.
Reported-by: Richard Moore <rich@richud.com> Signed-off-by: Michael Brown <mcb30@ipxe.org>
Michael Brown [Fri, 1 Mar 2013 16:32:29 +0000 (16:32 +0000)]
[netdevice] Separate VLAN support from presence of VLAN-supporting drivers
Some NICs (e.g. Hermon) provide hardware support for stripping the
VLAN tag, but do not provide any way for this support to be disabled.
Drivers for this hardware must therefore call vlan_find() to identify
a suitable receiving network device.
Provide a weak version of vlan_find() which will always return NULL if
VLAN support has not been enabled (either directly, or by enabling
a feature such as FCoE which requires VLAN support). This allows the
VLAN code to be omitted from builds where the user has not requested
support for VLANs.
Inspired-by: Stefan Hajnoczi <stefanha@redhat.com> Signed-off-by: Michael Brown <mcb30@ipxe.org>
Stefan Hajnoczi [Fri, 1 Mar 2013 15:32:16 +0000 (16:32 +0100)]
[iscsi] Include 802.1Q VLAN identifier in iBFT
The iBFT NIC section has a VLAN field which must be filled in so that
iSCSI booting works over VLANs.
Unfortunately it is unclear from the IBM specification linked in
ibft.c whether the VLAN field is just the 802.1Q VLAN Identifier or
the full 802.1Q TCI. For now just fill in the VID, the Priority Code
Point and Drop Eligible Indicator could be set in the future if it
turns out they should be present too.
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com> Modified-by: Michael Brown <mcb30@ipxe.org> Signed-off-by: Michael Brown <mcb30@ipxe.org>
Michael Brown [Mon, 25 Feb 2013 17:22:01 +0000 (17:22 +0000)]
[efi] Ensure EFI binaries comply with Authenticode requirements
Authenticode requires that the size of the raw file must equal the
size of the OptionalHeader.SizeOfHeaders plus the sum of all sections'
SizeOfRawData.
Michael Brown [Wed, 21 Nov 2012 02:37:55 +0000 (02:37 +0000)]
[efi] Delegate to child device's EFI_COMPONENT_NAME2_PROTOCOL, if present
EFI's device naming model requires drivers to provide names for child
devices. Allow the driver's GetControllerName() method to delegate to
an instance of EFI_COMPONENT_NAME2_PROTOCOL installed on the child
device itself (if present); this allows the SNP device to expose its
own device name via the PCI driver's GetControllerName() method.
Michael Brown [Mon, 12 Nov 2012 16:16:31 +0000 (16:16 +0000)]
[bzimage] Allow initrds to be rearranged in place
At present, loading a bzImage via iPXE requires enough RAM to hold two
copies of each initrd file. Remove this constraint by rearranging the
initrds in place.
Thomas Miletich [Fri, 2 Nov 2012 15:00:09 +0000 (15:00 +0000)]
[build] Make version.o depend on the git index
The version number string is currently updated only if version.o
happens to be rebuilt due to changes in its dependencies. Add a
dependency upon the git index, so that the version number is updated
after any checkout.
Signed-off-by: Thomas Miletich <thomas.miletich@gmail.com> Modified-by: Michael Brown <mcb30@ipxe.org> Signed-off-by: Michael Brown <mcb30@ipxe.org>
Michael Brown [Fri, 2 Nov 2012 12:15:36 +0000 (12:15 +0000)]
[build] Inhibit .eh_frame on newer gcc versions
Using -fno-dwarf2-cfi-asm is not sufficient to prevent the .eh_frame
section from being generated on newer versions of gcc. Add
-fno-exceptions -fno-unwind-tables -fno-asynchronous-unwind-tables;
this is sufficient to inhibit the .eh_frame section on gcc 4.7.1.
This does not affect the overall binary size, but does fix the numbers
reported by "size" for individual object files.
Michael Brown [Fri, 2 Nov 2012 13:21:52 +0000 (13:21 +0000)]
[build] Use -maccumulate-outgoing-args if required by gcc
Current versions of gcc require -maccumulate-outgoing-args if any
sysv_abi functions call ms_abi functions. This requirement is likely
to be lifted in future gcc versions, so test explicitly to see if the
current version of gcc requires -maccumulate-outgoing-args.
This problem is currently masked since the implied
-fasynchronous-unwind-tables (which is the default in current gcc
versions) implies -maccumulate-outgoing-args.
Michael Brown [Mon, 29 Oct 2012 10:14:00 +0000 (10:14 +0000)]
[forcedeth] Increase TX ring size to prevent dropped packets
Commit 947976d ("[netdevice] Do not force a poll on net_tx()")
requires network devices to have TX rings that are sufficiently large
to allow a transmitted response to all packets received during a
single poll.
Reported-by: Robin Smidsrød <robin@smidsrod.no> Tested-by: Robin Smidsrød <robin@smidsrod.no> Signed-off-by: Michael Brown <mcb30@ipxe.org>
Michael Brown [Thu, 25 Oct 2012 23:09:09 +0000 (16:09 -0700)]
[intel] Poll RX queue if hardware reports RX overflow
The Intel NIC emulation in some versions of VMware seems to suffer
from a flaw whereby the Interrupt Cause Register (ICR) fails to assert
the usual "packet received" bit (ICR.RXT0) if a receive overflow
(ICR.RXO) has also occurred.
Work around this flaw by polling for completed descriptors whenever
either ICR.RXT0 or ICR.RXO is asserted.
Reported-by: Miroslav Halas <miroslav.halas@bankofamerica.com> Debugged-by: Miroslav Halas <miroslav.halas@bankofamerica.com> Tested-by: Miroslav Halas <miroslav.halas@bankofamerica.com> Signed-off-by: Michael Brown <mcb30@ipxe.org>
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.
projects / thirdparty / ipxe.git / log
