added POD, mt

diff --git a/trb3/GbEGettingStarted.tex b/trb3/GbEGettingStarted.tex
index 02a5265c9facbaf259447389862d2420a3392424..18bd5fd4a5f45cee833b8b85597b9f07efab7e48 100644 (file)
--- a/trb3/GbEGettingStarted.tex
+++ b/trb3/GbEGettingStarted.tex
@@ -2,7 +2,7 @@
 In order to control TRB3 or a larger system with TRB3 as slow control client
 via Ethernet link, one needs to properly install and compile the trbcmd
 server, load a correct FPGA design and configure DHCP daemon on the server
-PC.Follow the instructions described in the next points.
+PC. Follow the instructions described in the next points.
 
 \subsubsection{FPGA design}
 The optical link, activated for the Slow Control over GbE is the one labelled
@@ -30,6 +30,7 @@ Now you can reload the central FPGA and it should automatically acquire the IP
 address from the server. One can verify that by monitoring the network traffic
 or system log file.
 
+
 \subsubsection{Trbnetd}
 To access the TRB3 you can access it directly with trbcmd (the local version
 found in ``trbsoft/trbnettools/libtrbnet'', but this is not recommended and
@@ -111,4 +112,33 @@ connects:
 \subsubsection{Usage}
 Now you are ready to use the trbcmd in the same way as it is for the normal HADES system.
 
+\subsubsection{Ping of Death}
+Currently (2017), TRBNet-Hubs have an inherent weakness, as the data which
+flows into the hubs are not checked for sanity (for example no
+CRC-check). Every bogus network packet, for example produced by
+TRBNet-Endpoints FPGAs which suffer from a voltage drop on the core supply, or
+from a SEU, can cause the TRBNet-HUB to crash. It is planned in the long-term
+to reduce these crashes by sanity checks of the data (actually TRBNet-headers)
+in the media interfaces.
+Therefore, it can happen that due to wrong data in the TRBNet, that the
+GbE-Slow-Control entity will hang and the user can not communicate with the
+TRB3/sc1 via the trbcmd.
+One way to solve this it to power-cycle the system.
+An other way is the following.
+As the TRB3 has a GbE-Interface, even though the TRBNet is down, the GbE-part
+is still active.
+When a special formatted ``ping'' packet arrives at the TRB3/sc1 it will
+initiate a reload of the FPGA which receives the data from Ethernet, so
+normally FPGA5 (central) on the TRB3 or the only FPGA on the TRB3sc.
+This allows for a much faster and less invasive action, compared to a power-cycle.
+The rule is the following: The GbE-entity will initiate the reload of the
+central FPGA if a ping-packet arrives which has the TRBNet-address as payload.
+So, for example, after a fresh start of the CTS-FPGA it's address is 0xf3c0. 
+
+\begin{verbatim}
+ ping -c3 -W2 -pc001 trb084
+\end{verbatim}
+will reboot the central FPGA of trb084, if it's TRBNet-address is 0xc001.
+Don't be alarmed if the ping doesn't come back, as sometimes the interface is
+blocked to send back data, but it still receives the ping.