Hardware Compatibility

From Syslinux Wiki
Revision as of 02:53, 23 July 2006 by Warthog9 (talk | contribs)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
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. 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:


If your network adapter is on the motherboard, you will probably need to request a BIOS upgrade from your system or motherboard vendor.

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:


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. 

* 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.