From 62a3b16b7b7d8f9cab04359bab1ba41bea2c1996 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Laurent=20P=C3=A9tr=C3=A9?= <laurent.petre@cern.ch>
Date: Wed, 24 Nov 2021 18:31:59 +0100
Subject: [PATCH] Remove the main LMDB and rpcsvc sections
---
docs/electronics/ctp7.md | 106 ---------------------
docs/expert/operations/ctp7.md | 136 +--------------------------
docs/references/electronics-guide.md | 83 ----------------
3 files changed, 1 insertion(+), 324 deletions(-)
diff --git a/docs/electronics/ctp7.md b/docs/electronics/ctp7.md
index 918d3db..235c223 100644
--- a/docs/electronics/ctp7.md
+++ b/docs/electronics/ctp7.md
@@ -45,112 +45,6 @@ slot 2 of the μTCA shelf configured as shelf 1.
`gemos-elogs`{.interpreted-text role="ref"} for details on which elog is
of interest and how to make a proper elog.
-#### The `rpcsvc` Service
-
-Most common actions involving the CTP7 requie the Remote Procedure Call
-(RPC) service to be running and owned by the `gemuser` account. This
-service is run as a system process called `rpcsvc`. To check if this
-process is running login to the CTP7 and execute:
-
-``` bash
-ps | grep [r]pcsvc
-```
-
-Example output should look like:
-
-``` bash
-10994 gemuser 4040 S rpcsvc
-```
-
-If you only see a line that says `grep rpcsvc` then the `rpcsvc` service
-is *not* running. Additionally if you see that `rpcsvc` is running but
-it is not owned by the `gemuser` account then it will be configured with
-the *wrong* environment and must be killed (either by the DAQ expert
-using the `root` account or from a `$USER` of the owning account).
-
-!!! note
- You might find that multiple lines are returned which show multiple
- `rpcsvc` services. If these are all owned by `gemuser` then this just
- indicates that the `rpcsvc` service is running and that one or more open
- `rpc` connections exist between the card and the DAQ PC.
-
-Sometimes you may need to restart the `rpcsvc` (typically after updating
-the `rpcmodules` on the card), to do this execute:
-
-``` bash
-killall rpcsvc && rpcsvc
-```
-
-#### CTP7 directories
-
-The `/mnt/persistent/gemdaq/vfat3` directory contains the per
-`(ohN,vfatN)` configuration file specifying registers per chip (e.g.,
-here you would edit the `CFG_IREF` for the VFAT of interest). Inside the
-`vfat3` directory there will be a set of configuration files and
-symlinks that are given by the following pattern:
-
-``` bash
-lrwxrwxrwx 1 gemuser 1001 53 Aug 10 15:27 config_OHX_VFATY.txt -> /mnt/persistent/gemdaq/vfat3/config_OHX_VFATY_cal.txt
--rw-r--r-- 1 gemuser 1001 1267 Aug 10 15:27 config_OHX_VFATY_cal.txt
-```
-
-The symlink is what is used by the configuration command to configure
-the `vfat3` in `(ohN,vfatN) = (X,Y)` position; so this must always be a
-valid link. An example of how this file is expected to look can be found
-in the section `gemos-frontend-vfatcfgfile`{.interpreted-text
-role="ref"}.
-
-The address table `xml` files will be found under the
-`/mnt/persistent/gemdaqxml` folder and a set of symlinks will be
-specified there, for example:
-
-``` bash
--rw-r--r-- 1 51446 1399 21149299 Aug 8 15:46 gem_amc_top.pickle
-lrwxrwxrwx 1 51446 1399 18 Aug 8 15:45 gem_amc_top.xml -> gem_amc_v3_5_3.xml
--rw-r--r-- 1 51446 1399 136064 Aug 8 15:45 gem_amc_v3_5_3.xml
--rw-r--r-- 1 51446 1399 102472 Aug 8 15:41 oh_registers_3.1.2.B.xml
-lrwxrwxrwx 1 51446 1399 24 Aug 8 15:41 optohybrid_registers.xml -> oh_registers_3.1.2.B.xml
-```
-
-### RPC Modules and the LMDB
-
-The `rpcmodules` and `LMDB` are two terms you may hear when interacting
-eith the DAQ expert. These two pieces are how the functions perform
-register access.
-
-The LMDB is a database that the `rpcmodules` query when functions are
-launched on the CTP7. The `rpcmodules` are scoped by their
-functionality, depending on which part of the system they interact with.
-
-To view logging information that may help point at the source of some
-problems, on the CTP7 the logfile
-
-``` bash
-/var/log/messages
-```
-
-On the DAQ PC (if it is configured as the `sysmgr` host) the log files
-for all connected cards can be found under `/var/log/remote`, e.g.,:
-
-``` bash
-/var/log/remote/gem-shelfXX-amcYY/messages.log
-```
-
-Where `gem-shelfXX-amcYY` is the network alias of the CTP7 (e.g.,
-`gem-shelf01-amc02`). You can see the most recent information found in
-the log file via:
-
-``` bash
-tail -25 /var/log/messages
-```
-
-This will display the last 25 lines in the log file on the CTP7
-(executed as `gemuser` on the CTP7). Use the `tail` command similarly to
-view the log on the DAQ PC.
-
-If the log file is either not present, or the information is stale (not
-updating), contact the GEM DAQ expert to resolve the problem.
-
## Register CLI
The `gem_reg.py` tool is a command line interface (CLI) that allows you
diff --git a/docs/expert/operations/ctp7.md b/docs/expert/operations/ctp7.md
index 6bb6f5f..17ba5cb 100644
--- a/docs/expert/operations/ctp7.md
+++ b/docs/expert/operations/ctp7.md
@@ -487,103 +487,6 @@ entry](http://cmsonline.cern.ch/cms-elog/1060543).
`killall rpcsvc`, and then logout and log back in as `gemuser` to issue
the recover command.
-## The `rpcsvc` service
-
-Many actions on the card requie the Remote Procedure Call (RPC) service
-to be running and owned by the `gemuser` account. This service is run as
-a system process called `rpcsvc`. To check if this process is running
-login to the CTP7 and execute:
-
-``` bash
-ps | grep [r]pcsvc
-```
-
-Example output should look like:
-
-``` bash
-10994 gemuser 4040 S rpcsvc
-```
-
-If you only see a line that says `grep rpcsvc` then the `rpcsvc` service
-is *not* running. Additionally if you see that `rpcsvc` is running but
-it is not owned by the `gemuser` account then it will be configured with
-the *wrong* library and must be killed (either as the `root` user or as
-`$USER` owning the process).
-
-!!! note
- You might find that multiple lines are returned which show multiple
- `rpcsvc` services. If these are all owned by `gemuser`, this simply
- indicates that the `rpcsvc` service is running and that one or more open
- `rpc` connections exist between the card and the DAQ PC.
-
-Sometimes you may need to restart the `rpcsvc` (typically after updating
-the `rpcmodules` on the card), to do this execute:
-
-``` bash
-killall rpcsvc && rpcsvc
-```
-
-### RPC modules and the LMDB
-
-When a command to interface with the front-end hardware is sent from the
-DAQ machine this typically uses either the μTCA hardware access library
-(`uhal`) built on top of `ipbus`, or the cross hardware access library
-(`xhal`) built on top of `rpcsvc` (and using `TCP/IP` communication). In
-the second case, an RPC message is sent to the CTP7 and the Zynq
-processor on the CTP7 will load a function that is defined in a shared
-object library (`*.so`) file under `/mnt/persistent/rpcmodules`. These
-shared object libraries are referred to as `rpcmodules`. For more
-detailes please see the [README of the
-ctp7_mopdules](https://github.com/cms-gem-daq-project/ctp7_modules/blob/develop/README.md)
-repository.
-
-On a production machine these will be the following set (although more
-may be present in the future):
-
-``` bash
--rwxr-xr-x 1 root root 49093 Oct 9 16:48 amc.so
--rwxr-xr-x 1 root root 140180 Oct 9 16:48 calibration_routines.so
--rwxr-xr-x 1 root root 95769 Oct 9 16:48 daq_monitor.so
--rwxr-xr-x 1 root root 13917 Oct 9 16:48 extras.so
--rwxr-xr-x 1 root root 102207 Sep 13 2017 memory.so
--rwxr-xr-x 1 root root 122365 Sep 13 2017 optical.so
--rwxr-xr-x 1 root root 102929 Oct 9 16:48 optohybrid.so
--rwxr-xr-x 1 root root 108849 Sep 13 2017 rpctest.so
--rwxr-xr-x 1 root root 97422 Oct 9 16:48 utils.so
--rwxr-xr-x 1 root root 84989 Oct 9 16:48 vfat3.so
-```
-
-While on a development system, these **may** be a set of symlinks that
-point to a user editable area, for example `eagle64`:
-
-``` bash
-lrwxrwxrwx 1 root root 47 Oct 1 12:15 amc.so -> /mnt/persistent/gemuser/rpcmoduleTesting/amc.so
-lrwxrwxrwx 1 root root 64 Oct 1 12:15 calibration_routines.so -> /mnt/persistent/gemuser/rpcmoduleTesting/calibration_routines.so
-lrwxrwxrwx 1 root root 55 Oct 3 12:09 daq_monitor.so -> /mnt/persistent/gemuser/rpcmoduleTesting/daq_monitor.so
-lrwxrwxrwx 1 root root 50 Oct 1 12:15 extras.so -> /mnt/persistent/gemuser/rpcmoduleTesting/extras.so
--rwxr-xr-x 1 root root 102207 Sep 13 2017 memory.so
--rw-r--r-- 1 root root 611328 Jun 27 09:07 modules.tar
--rwxr-xr-x 1 root root 122365 Sep 13 2017 optical.so
-lrwxrwxrwx 1 root root 54 Oct 1 12:16 optohybrid.so -> /mnt/persistent/gemuser/rpcmoduleTesting/optohybrid.so
--rwxr-xr-x 1 root root 108849 Sep 13 2017 rpctest.so
-lrwxrwxrwx 1 root root 49 Oct 1 12:16 utils.so -> /mnt/persistent/gemuser/rpcmoduleTesting/utils.so
-lrwxrwxrwx 1 root root 49 Oct 1 12:16 vfat3.so -> /mnt/persistent/gemuser/rpcmoduleTesting/vfat3.so
-```
-
-where the user editable area is:
-`/mnt/persistent/gemuser/rpcmoduleTesting/`.
-
-The LMDB is an in-memory key-value-store used by the `rpcmodules` to map
-register names to addresses. The `rpcmodules` are segmented into what
-are referred to as local or remote/non-local modules. The local version
-has `someStringLocal()` always in it\'s function name and is only ever
-executed from the CTP7. The non-local module receives the RPC Message
-from the host DAQ PC, calls the corresponding local function(s) and
-returns and RPC response to the host machine. Note that no terminal
-output appears on the host machine during the execution of either the
-local or non-local `rpcmodules`. Instead the developer will have
-configured the functions to log actions on the CTP7\'s log file which is
-available on the CTP7 at:
## Register CLI advanced usage
In addition to the overview provided in the
@@ -602,44 +505,7 @@ An overview of the most common commands is found in the
`user guide<userguide:gemos-cli-commands>`{.interpreted-text
role="ref"}. All commands are documented in the
:py`xhal API<xhal:gem-reg>`{.interpreted-text role="mod"}. A few expert
-actions are described here for reference
-
- -----------------------------------------------------------------------------------------------------
- Command Description Example usage
- --------------- --------------------------------- ---------------------------------------------------
- `update_lmdb` updates the LMDB on the CTP7 `usage<gemos-ctp7-update-lmdb>`{.interpreted-text
- following a breaking change to role="ref"}
- the register address space
- (address table)
-
- -----------------------------------------------------------------------------------------------------
-
-### Updating the LMDB
-
-Whenever the FW of either the CTP7 or the OptoHybrid changes such that a
-new xml address table is generated (e.g., new node names are added, new
-addresses are added, or existing nodes (addresses) have their addresses
-(nodes) altered, FW is compiled for more OptoHybrids) then the LMDB must
-be updated. (If the FW update does not include changes to the xml
-address table then this action does *not* need to be taken).
-
-To update the LMDB launch `gem_reg.py` from the *DAQ PC* and after
-connecting execute:
-
-``` bash
-update_lmdb /mnt/persistent/gemdaq/xml/gem_amc_top.xml
-```
-
-!!! warning
- If an error was reported when trying to update the LMDB then it has
- failed and you must investigate the problem, solve it, and then update
- the LMDB again. A good place to start is in the
- `CTP7 log<gemos-ctp7-syslogd>`{.interpreted-text role="ref"}.
-
-!!! note
- This procedure is automatically run when using the officially supported
- FW `update tools<gemos-ctp7-helper-scripts>`{.interpreted-text
- role="ref"}
+actions are described here for reference.
## Update the OptoHybrid FW
diff --git a/docs/references/electronics-guide.md b/docs/references/electronics-guide.md
index 25b3597..b5b05c5 100644
--- a/docs/references/electronics-guide.md
+++ b/docs/references/electronics-guide.md
@@ -367,89 +367,6 @@ eagle26:~$ cat /mnt/image-persist/build_id
CTP7-GENERIC-20180529T153916-0500-4935611
```
-#### The `rpcsvc` Service
-
-Many actions on the card requie the Remote Procedure Call (RPC) service to be running and owned by the `gemuser` account. This service is run as a system process called `rpcsvc`. To check if this process is running login to the CTP7's linux image an execute:
-
-```bash
-eagleXX:~$ ps | grep rpcsvc
-```
-
-Example output should look like:
-
-```bash
-eagle60:~$ ps | grep rpcsvc
-10994 gemuser 4040 S rpcsvc
-14004 gemuser 2796 S grep rpcsvc
-```
-
-If you only see a line that says `grep rpcsvc` then the `rpcsvc` service is *not* running. Additionally if you see that `rpcsvc` is running but it is not owned by the `gemuser` account then it will be configured with the *wrong* library and must be killed (either by the sysadmin using the `root` account or from a `$USER` of the other account). Note you might find that multiple lines are returned which show multiple `rpcsvc` services. If these are all owned by `gemuser` then this just indicates that the `rpcsvc` service is running and that one or more open `rpc` connections exist between the card and the DAQ PC.
-
-Sometimes you may need to restart the `rpcsvc` (typically after updating the `rpcmodules` on the card), to do this execute:
-
-```bash
-killall rpcsvc && rpcsvc
-```
-
-##### RPC Modules and the LMDB
-
-When a command to interface with the front-end hardware is sent from the DAQ machine this typically uses either the micro hardware access library (`uhal`) built on top of `ipbus` or the cross hardware access library (`xhal`) built on top of `rpcsvc` (and using `TCP/IP` communication). An RPC message is sent to the CTP7 and the Zynq processor on the CTP7 will load a function that is defined in a shared object library (`*.so`) file under `/mnt/persistent/rpcmodules`. These shared object libraries are referred to as `rpcmodules`. For more detailes please see the [README of the ctp7_mopdules](https://github.com/cms-gem-daq-project/ctp7_modules/blob/develop/README.md) repository.
-
-On a production machine these will be the following set (although more may be present in the future):
-
-```bash
-$ ll /mnt/persistent/rpcmodules/
--rwxr-xr-x 1 root root 49093 Oct 9 16:48 amc.so
--rwxr-xr-x 1 root root 140180 Oct 9 16:48 calibration_routines.so
--rwxr-xr-x 1 root root 95769 Oct 9 16:48 daq_monitor.so
--rwxr-xr-x 1 root root 13917 Oct 9 16:48 extras.so
--rwxr-xr-x 1 root root 102207 Sep 13 2017 memory.so
--rwxr-xr-x 1 root root 122365 Sep 13 2017 optical.so
--rwxr-xr-x 1 root root 102929 Oct 9 16:48 optohybrid.so
--rwxr-xr-x 1 root root 108849 Sep 13 2017 rpctest.so
--rwxr-xr-x 1 root root 97422 Oct 9 16:48 utils.so
--rwxr-xr-x 1 root root 84989 Oct 9 16:48 vfat3.so
-```
-
-While on a development system these will be a set of symlinks that point to a user editable area, for example `eagle64`:
-
-```
-$ ll /mnt/persistent/rpcmodules/
-lrwxrwxrwx 1 root root 47 Oct 1 12:15 amc.so -> /mnt/persistent/gemuser/rpcmoduleTesting/amc.so
-lrwxrwxrwx 1 root root 64 Oct 1 12:15 calibration_routines.so -> /mnt/persistent/gemuser/rpcmoduleTesting/calibration_routines.so
-lrwxrwxrwx 1 root root 55 Oct 3 12:09 daq_monitor.so -> /mnt/persistent/gemuser/rpcmoduleTesting/daq_monitor.so
-lrwxrwxrwx 1 root root 50 Oct 1 12:15 extras.so -> /mnt/persistent/gemuser/rpcmoduleTesting/extras.so
--rwxr-xr-x 1 root root 102207 Sep 13 2017 memory.so
--rw-r--r-- 1 root root 611328 Jun 27 09:07 modules.tar
--rwxr-xr-x 1 root root 122365 Sep 13 2017 optical.so
-lrwxrwxrwx 1 root root 54 Oct 1 12:16 optohybrid.so -> /mnt/persistent/gemuser/rpcmoduleTesting/optohybrid.so
--rwxr-xr-x 1 root root 108849 Sep 13 2017 rpctest.so
-lrwxrwxrwx 1 root root 49 Oct 1 12:16 utils.so -> /mnt/persistent/gemuser/rpcmoduleTesting/utils.so
-lrwxrwxrwx 1 root root 49 Oct 1 12:16 vfat3.so -> /mnt/persistent/gemuser/rpcmoduleTesting/vfat3.so
-```
-
-With the user editable area being `/mnt/persistent/gemuser/rpcmoduleTesting/`.
-
-The LMDB is a database that the `rpcmodules` query when functions are launched on the CTP7. The `rpcmodules` are segmented into what are referred to as local or remote/non-local modules. The local version has `someStringLocal()` always in it's function name and is only ever executed from the CTP7. The non-local module receives the RPC Message from the host DAQ PC, calls the corresponding local function(s) and returns and RPC response to the host machine. Note that no terminal output appears on the host machine during the execution of either the local or non-local `rpcmodules`. Instead the developer will have configured the functions to log actions on the CTP7's log file which is available on the CTP7 at:
-
-```
-/var/log/messages
-```
-
-Note that this file is *not* found under the `/mnt/persistent` partition and is re-written everytime the card reboots. To ensure log information is not lost the DAQ PC is configured to have a version of this file found under:
-
-```
-/var/log/remote/eagleXX/messages.log
-```
-
-Where `eagleXX` is the network alias of the CTP7 (e.g. `eagle64`). This file is written to disk on the DAQ PC and will persist through crashes/reboots of the CTP7 (so no information will be lost). You can see the most recent information found in the log file via:
-
-```bash
-tail -25 /var/log/messages
-```
-
-This will display the last 25 lines in the log file on the CTP7 (executed as `gemuser` on the CTP7). Use the `tail` command similarly to view the log on the DAQ PC.
-
##### Restarting `syslogd`
In some weird cases `syslogd` will not be running after the CTP7 boots. This will cause the log file:
--
GitLab