Hardware Compatibility

From Syslinux Wiki
Revision as of 12:58, 18 October 2010 by GeneC (talk | contribs) (LOCALBOOT: Add x3850 X5)

Jump to: navigation, search

Cards that cause trouble no matter what

Some versions of the Promise ATA RAID cards are known to cause problems no matter if you boot from them or not. I have received several reports that conclusively show that the Promise ATA RAID BIOS overwrites random location in low memory. This BIOS is considered utterly unsupportable. This phenomenon has been observed even when the ATA RAID is not the boot device (e.g. using PXELINUX.)

Problematic network cards

The following network cards are known to have problems with PXELINUX; and this is what you can do about it. This page is updated when new information becomes available; if you have additional information please send it to hpa+cards@zytor.com.

Basically all PXE implementations

A fair number of PXE implementations has problems with releasing base memory once booting is complete. This should not affect you if you're running Linux, but other operating systems, such as DOS under MEMDISK, may have less memory available than they should. PXELINUX 1.65 or higher will display a message:

Failed to free base memory, sorry... 

... when that happens. It should not cause problems other than the loss of some memory; usually about 64K worth. PXELINUX 2.03 or later will display an error code in conjunction with the message; reporting that error code might assist in identifying the location of the problem.

Most, possibly all, PXE implementations are completely broken if they receive fragmented IP packets; also, a lot of them will request a blksize of 1468 or thereabouts, corresponding to an MTU of 1500. Therefore, your boot server should never use an MTU that is larger than the MTU the packets may encounter during the transfer (typically 1500), and you should disable the blksize option (-r blksize in tftp-hpa) if you have to use an MTU smaller than 1500. Fortunately it's rare these days that you'll have that kind of network between your TFTP server and your clients.


A number of problems have been reported with SiS900-based cards (at least with "BootRom V1.09 Intel UNDI, PXE-2.0, build-082.") See this message for a workaround.

Intel Boot Agent 4.0.19

A lot of people have reported problems with Intel Boot Agent 4.0.19 not performing the initial bootstrap correctly. On the other hand, versions 4.0.17, 4.0.21, and 4.1.01 have all been reported to work correctly. This problem also seems to occur on version 4.0.18 as well. You will likely see symptoms similar to the following bolded output from a Sony VAIO PCG-GRX520 Version R0216B0:

Intel(R) Boot Agent Version 4.0.18
Copyright (C) 1997-2001, Intel Corporation
CLIENT MAC ADDR: 08 00 42 42 42 42  GUID: D4E54B40-4B65-11C6-8C44-080042424242
PXE-T04: unsupported request from
PXE-E36: Error received from TFTP server
PXE-M0F: Exiting Intel PXE ROM.

If you have a card or system with Intel Boot Agent 4.0.19, please contact the manufacturer for an upgrade.

If you have an Intel-branded network card (not on the motherboard), you might be able to find a flash upgrade at: http://support.intel.com/support/network/adapter/index.htm

If your network adapter is on the motherboard, you will probably need to request a BIOS upgrade from your system or motherboard vendor. Alternatively, with a little bit of googling, one can locate BIOS image editors capable of replacing "Expansion ROM" images following the main BIOS. Using this technique, it's possible to extract and modify the UNDI network driver and/or the Intel Boot Agent Expansion ROM. THIS IS DANGEROUS. DO NOT ATTEMPT IF YOU DO NOT UNDERSTAND EXACTLY WHAT YOU ARE DOING.

Early Intel Pro/100+ Server cards

According to the Intel release notes, some early versions of the Intel Pro/100+ Server cards will occationally bail with a "media test failure." This is a hardware problem.

Many 3Com cards

A lot of 3Com cards with PXE boot ROMs have been reported as having problems with PXELINUX. 3Com MBA v4.30 or later is believed to work on all supported network cards, however, not necessarily embedded on motherboards. If your boot ROM is older, you can download a firmware upgrade at: http://support.3com.com/infodeli/tools/nic/mba.htm

I would like to obtain information of various 3Com MBA versions and whether or not they work. Please send such reports to hpa+cards@zytor.com.

PXE stacks based on Intel's 0.99 series code

A lot of older PXE stacks are based on Intel LANDesk Service Agent II, versions 0.99, which were released by Intel as "PXE PDK v2.x", despite being what can best be described as alpha quality. These stacks have numerous problems and can trivially be crashed.

If you can, upgrade your firmware.

Unfortunately, firmware upgrade to a recent source base are frequently unavailable for these cards, especially motherboard cards where the PXE stack is integrated with the system BIOS. If so, these stacks can usually be made to work with the following workarounds:

  • Disable path MTU discovery on the boot servers.
Some versions of these stacks are known to crash if the boot server supports path MTU discovery on UDP. For a Linux server, path MTU discovery can be disabled by setting the sysctl entry net.ipv4.ip_no_pmtu_disc to 1:
       echo 1 > /proc/sys/net/ipv4/ip_no_pmtu_disc 
Note that that may cause bad performance for other services which may be running on the boot server, especially if they have to talk over WAN links. DHCP or TFTP services should generally not be affected.
Newer versions of tftp-hpa will automatically disable path MTU discovery for the TFTP service only if run on Linux.
  • Disable the blksize TFTP option on your TFTP server.
Some version of these stacks are known to request the blksize option and fail to complete the initial bootstrap transfer if the option is granted by the server (i.e. they got what they asked for.) For tftp-hpa, specify -r blksize to disable blksize, for atftp specify --no-blksize. For other TFTP servers, see your TFTP server documentation. Note that disabling blksize may have a significant impact on the performance of all TFTP clients. Other services are not affected.

Problematic CD-ROM controllers

At least one Promise ATA-type controller with BIOS (model number unknown) does not work with ISOLINUX since it hard-codes the location of the El Torito boot catalogue from the Windows 2000 CD-ROM and will only boot from this location!!!!!! The reporter of this bug was able to get it to boot by hacking mkisofs to put the boot catalogue in the same location as the Windows 2000 one.

Keyboard Issues with Dell OptiPlex GX520 and GX620

There is an apparent issue with the latest bios (A11) on this model that is known to cause this problem. The fix is to downgrade to version A10.

UPDATE: a possible workaround for this problem has been identified. Syslinux 3.70 or later is believed to not be affected.

USB related problems

No BIOS USB boot support by the BIOS

To overcome this BIOS limitation, you can boot this USB drive with PLoP Bootmanager.

Note: If you enable the USB support of PLoP Bootmanager, USB keyboards and USB mice won't work anymore.

Slow USB boot

You can enhance USB booting speed, when your BIOS only supports USB1.1 speed, while your USB controllers support USB2.0, with PLoP Bootmanager.

It might be worth to look at the ifplop.c32 COM32 module.

USB drives larger than 128GiB (=137GB)

Some BIOSes have problems with booting USB drives larger than 128GiB (137GB) (28-bit LBA limit). (If the drive can also be connected via SATA, it is entirely possible that it will boots fine.) When Syslinux,another bootloader or an OS that uses BIOS calls to read from the drive, wants to access any data beyond this 128GiB limit, it won't get what it wants.

To overcome this BIOS limitation, you can boot this USB drive with PLoP Bootmanager.

It might be worth to look at the ifplop.c32 COM32 module.


Certain models of computers, sometimes specific to BIOS and BIOS extension versions, do not work well with LOCALBOOT. As a workaround, use chain.c32 like this:

LABEL localboot
  MENU LABEL Boot from first hard drive
  COM32 chain.c32
  APPEND hd0

This is also equivalent to the command line "chain.c32 hd0 0"

LOCALBOOT on HP ProLiant servers

The LOCALBOOT option doesn't work reliably on G5 and older HP ProLiant servers because of BIOS defect QXCR1001064253.

LOCALBOOT on Dell Latitude E6400

The E6400 has an issue with using "LOCALBOOT 0" from PXELINUX.