openslx-ng/ipxe.git/src/arch/x86/drivers, branch openslx

[undi] Assume that legacy interrupts are broken for any PCIe device

2025-07-24T13:14:41+00:00

PCI Express devices do not have physical INTx output signals, and on modern motherboards there is unlikely to be any interrupt controller with physical interrupt input signals. There are multiple levels of abstraction involved in emulating the legacy INTx interrupt mechanism: the PCIe device sends Assert_INTx and Deassert_INTx messages, PCIe bridges and switches must collate these virtual wires, and the root complex must map the virtual wires into messages that can be understood by the host's emulated 8259 PIC. This complex chain of emulations is rarely tested on modern hardware, since operating systems will invariably use MSI-X for PCI devices and the I/O APIC for non-PCI devices such as the real-time clock. Since the legacy interrupt emulation mechanism is rarely tested, it is frequently unreliable. We have encountered many issues over the years in which legacy interrupts are simply not raised as expected, even when inspection shows that the device believes it is asserting an interrupt and the controller believes that the interrupt is enabled. We already maintain a list of devices that are known to fail to generate legacy interrupts correctly. This list is based on the PCI vendor and device IDs, which is not necessarily a fair test since the root cause may be a board-level misconfiguration rather than a device-level fault. Assume that any PCI Express device has a high chance of not being able to raise legacy interrupts reliably. This is a relatively intrusive change since it will affect essentially all modern network devices, but should hopefully fix all future issues with non-functional legacy interrupts, without needing to constantly grow the list of known broken devices. If some PCI Express devices are found to fail when operated in polling mode, then this change will need to be revisited. Signed-off-by: Michael Brown

[uaccess] Remove redundant copy_from_user() and copy_to_user()

2025-04-30T14:32:03+00:00

Remove the now-redundant copy_from_user() and copy_to_user() wrapper functions. Signed-off-by: Michael Brown

[undi] Work around broken ASUSTeK KNPA-U16 server PXE ROM

2025-04-17T14:53:28+00:00

Signed-off-by: Michael Brown

[undi] Ensure forward progress is made even if UNDI IRQ is stuck

2025-03-26T14:56:20+00:00

If the UNDI interrupt remains constantly asserted (e.g. because the BIOS has enabled interrupts for an unrelated device sharing the same IRQ, or because of bugs in the OEM UNDI driver), then we may get stuck in an interrupt storm. We cannot safely chain to the previous interrupt handler (which could plausibly handle an unrelated device interrupt) since there is no well-defined behaviour for previous interrupt handlers. We have observed BIOSes to provide default interrupt handlers that variously do nothing, send EOI, disable the IRQ, or crash the system. Fix by disabling the UNDI interrupt whenever our handler is triggered, and rearm it as needed when polling the network device. This ensures that forward progress continues to be made even if something causes the interrupt to be constantly asserted. Signed-off-by: Michael Brown

[pxeprefix] Ensure that UNDI IRQ is disabled before starting iPXE

2025-03-26T14:56:13+00:00

When using the undionly.kkpxe binary (which is never recommended), the UNDI interrupt may still be enabled when iPXE starts up. If the PXE base code interrupt handler is not well-behaved, this can result in undefined behaviour when interrupts are first enabled (e.g. for entropy gathering, or for allowing the timer tick to occur). Fix by detecting and disabling the UNDI interrupt during the prefix code. Signed-off-by: Michael Brown

[build] Fix building with newer binutils

2024-01-14T12:16:02+00:00

Newer versions of the GNU assembler (observed with binutils 2.41) will complain about the ".arch i386" in files assembled with "as --64", with the message "Error: 64bit mode not supported on 'i386'". In files such as stack.S that contain no instructions to be assembled, the ".arch i386" is redundant and may be removed entirely. In the remaining files, fix by moving ".arch i386" below the relevant ".code16" or ".code32" directive, so that the assembler is no longer expecting 64-bit instructions to be used by the time that the ".arch i386" directive is encountered. Reported-by: Ali Mustakim Signed-off-by: Michael Brown

[build] Remove unnecessary ".text" directives

2024-01-14T11:51:16+00:00

The .text directive is entirely redundant when followed by a .section directive giving an explicit section name and attributes. Remove these unnecessary directives to simplify the code. Signed-off-by: Michael Brown

[build] Inhibit linker warnings about an implied executable stack

2023-06-30T10:05:37+00:00

Signed-off-by: Geert Stappers Modified-by: Michael Brown Signed-off-by: Michael Brown

[undi] Read TSC only when profiling

2021-05-12T10:03:01+00:00

Avoid using the "rdtsc" instruction unless profiling is enabled. This allows the non-debug build of the UNDI driver to be used on a CPU such as a 486 that does not support the TSC. Reported-by: Nikolai Zhubr Signed-off-by: Michael Brown

[malloc] Rename malloc_dma() to malloc_phys()

2020-11-05T19:13:52+00:00

The malloc_dma() function allocates memory with specified physical alignment, and is typically (though not exclusively) used to allocate memory for DMA. Rename to malloc_phys() to more closely match the functionality, and to create name space for functions that specifically allocate and map DMA-capable buffers. Signed-off-by: Michael Brown