Update documentation -- point to hardware information page
authorhpa <hpa>
Sat, 24 Nov 2001 08:19:50 +0000 (08:19 +0000)
committerhpa <hpa>
Sat, 24 Nov 2001 08:19:50 +0000 (08:19 +0000)
pxelinux.doc
syslinux.doc

index 70e8710..1908e87 100644 (file)
@@ -81,36 +81,6 @@ Lefebvre:
 
        ftp://ftp.mamalinux.com/pub/atftp/
 
-Unfortunately, the Intel LANDesk Service Agent II prior to version
-0.99h (PXE PDK V2.4) seems to have a host of serious bugs.  Among
-other things, it requests the TFTP "blksize" option, but will be
-mortally confused if this option is actually accepted by the server!
-There are three possible workarounds for this bug:
-
-1. Use a TFTP server with doesn't support "blksize".
-
-   Unfortunately, PXELINUX requires the "tsize" option to be
-   supported, and it is very unusual for TFTP servers to implement one
-   and not the other.  Both the tftp-hpa and atftp TFTP servers (see
-   above) therefore can be configured to disable the blksize option.
-   Use "-r blksize" for tftp-hpa, "--no-blksize" for atftp.
-
-2. Use MTFTP for the initial bootstrap.  You need an MTFTP server with
-   the appropriate DHCP setup to do this.
-
-3. Use appropriate DHCP options that the client will attempt MTFTP
-   before trying conventional TFTP.  It seems that the client will not
-   request the "blksize" option if it has tried MTFTP and failed.
-   These DHCP options are beyond the scope of this document.
-
-These systems also seem to break if PMTU discovery is enabled on the
-TFTP server.  This has to be disabled in the kernel on the TFTP
-server.  On Linux, you can disable PMTU discovery by setting:
-
-       echo 1 > /proc/sys/net/ipv4/ip_no_pmtu_disc
-
-Note that this may cause bad performance for other services on the machine.
-
 
     ++++ SETTING UP THE DHCP SERVER ++++
 
@@ -317,6 +287,14 @@ minutes after displaying an error message, it will reset the machine.
 This allows an unattended machine to recover in case it had bad enough
 luck of trying to boot at the same time the TFTP server goes down.
 
+Lots of PXE stacks, especially old ones, have various problems of
+varying degrees of severity.  Please see:
+
+       http://syslinux.zytor.com/hardware.php
+
+... for a list of currently known hardware problems, with workarounds
+if known.
+
 
     ++++ CURRENTLY KNOWN PROBLEMS ++++
 
@@ -329,14 +307,9 @@ The following problems are known with PXELINUX, so far:
   decent way of telling it to free up all memory and unchain any
   interrupts; it allows the base stack to be unloaded, but not the
   UNDI driver.
-+ There seems to be a problem with sending ACK "storms"; a number of
-  ACK packets fired off without the proper delay in between.  I
-  suspect this is a PXE firmware problem, rather than a PXELINUX
-  problem.
 + We should probably call the UDP receive function in the keyboard
   entry loop, so that we answer ARP requests.
-+ Boot sectors don't work yet... they probably need auxilliary information
-  (such as device) to work at all.
++ Boot sectors/disk images are not supported yet.
 
 If you have additional problems, please contact the SYSLINUX mailing
 list (see syslinux.doc for the address.)
index 71cbbe4..e61dda4 100644 (file)
@@ -622,6 +622,18 @@ prompt 1
 display bootmsg.txt
 
 
+   ++++ HARDWARE INFORMATION +++
+
+I have started to maintain a web page of hardware with known
+problems.  There are, unfortunately, lots of broken hardware out
+there; especially early PXE stacks (for PXELINUX) have lots of
+problems.
+
+A list of problems, and workarounds (if known), is maintained at:
+
+       http://syslinux.zytor.com/hardware.php
+
+
    ++++ BUG REPORTS ++++
 
 I would appreciate hearing of any problems you have with SYSLINUX.  I