| Quote: |
|
The remaining issues are:
- RFM network down. The IOP models on all hosts on the RFM network are not detecting their RFM cards. Keith Thorne thinks that this is because of changes in trunk to support the new long-range PCIe that will be used at the sites, and that we just need to add a new parameter to the cdsParameters block in models that use RFM. Him and Rolf are looking into for us.
|
RFM network is back! Everything green again.
Use of RFM has been turned off in adLigoRTS trunk in favor of the new long-range PCIe networking being developed for the sites. Rolf provided a single-line patch that re-enables it:
controls@c1sus:/opt/rtcds/rtscore/trunk 0$ svn diff
Index: src/epics/util/feCodeGen.pl
===================================================================
--- src/epics/util/feCodeGen.pl (revision 4447)
+++ src/epics/util/feCodeGen.pl (working copy)
@@ -122,7 +122,7 @@
$diagTest = -1;
$flipSignals = 0;
$virtualiop = 0;
-$rfm_via_pcie = 1;
+$rfm_via_pcie = 0;
$edcu = 0;
$casdf = 0;
$globalsdf = 0;
controls@c1sus:/opt/rtcds/rtscore/trunk 0$
This patched was applied to RTS source checkout we're using for the FE builds (/opt/rtcds/rtscore/trunk, which is r4447, and is linked to /opt/rtcds/rtscore/release). The following models that use RFM were re-compiled, re-installed, and re-started:
- c1x02
- c1rfm
- c1x03
- c1als
- c1x01
- c1scx
- c1asx
- c1x05
- c1scy
- c1tst
The re-compiled models now see the RFM cards (dmesg log from c1ioo):
[24052.203469] c1x03: Total of 4 I/O modules found and mapped
[24052.203471] c1x03: ***************************************************************************
[24052.203473] c1x03: 1 RFM cards found
[24052.203474] c1x03: RFM 0 is a VMIC_5565 module with Node ID 180
[24052.203476] c1x03: address is 0xffffc90021000000
[24052.203478] c1x03: ***************************************************************************
This cleared up all RFM transmission error messages.
CDS upstream are working to make this RFM usage switchable in a reasonable way. |