Having determined that Rana (the computer) was having to many issues with testing the new Raid array due to age of the system, we proceeded to test on fb40m.
We brought it down and up several times between 11 and noon. We eventually were able to daisy chain the old raid and the new raid so that fb40m sees both. At this time, the RAID arrays are still daisy chained, but the computer is setup to run on just the original raid, while the full 14 TB array is initialized (16 drives, 1 hot spare, RAID level 5 means 14 TB out of the 16 TB are actually available). We expect this to take a few hours, at which point we will copy the data from the old RAID to the new RAID (which I also expect to take several hours). In the meantime, operations should not be affected. If it is, contact one of us.
This afternoon the alignment script chrashed after returning sysntax errors. We found that the tpman wasn't running on the framebuilder becasue it had probably failed to get restarted in one of the several reboots executed in the morning by Alex and Jo.
Restarting the tpman was then sufficient for the alignment scripts to get back to work.
Restarted backup since fb40m was rebooted.
The 40m frame builder is currently being patched to be able utilize the full 14 TB of the new raid array (as opposed to being limited to 2 TB). This process is expected to take several hours, during which the frame builder will be unavailable.
The Elog started crashing last night. It turns out I was the culprit, and whenever I tried to upload a certain 500kb .png picture, it would die. It has happened both when choosing "upload" of a picture, and when choosing "submit" after successfully uploading a picture. Both culprits were ~500kb .png files.
we did a hard reboot of c1susvme1, c1susvme2, c1sosvme, and c1susaux. We are hoping this will fix some of the weird suspension issues we've been having (MC3 side coil, ITMX alignment).
I just restarted the elog. It was crashed for unknown reasons. The restarting instructions are in the wiki.
c1susvme2 has been running just a bit late for about a week. I rebooted it.
The plot shows SRM_FE_SYNC, which is the number of times in the last second that c1susvme2 was late for the 16k cycle. Similarly for ETMX.
The reboot appears to have worked.
I restarted ntpd on op440m to solve a "synchronization error" that we were having in DTT. I also edited the config file (/etc/inet/ntp.conf) to remove the lines referring to rana as an ntp server; now only nodus is listed.
To do this:
log in as root
/usr/local/bin/ntpd -c /etc/inet/ntp.conf
rob, alberto, rana, pete
we reset this computer, which was out of sync (16384 in the FE_SYNC field instead of 0)
tdsavg 5 C1:LSC-PD4_DC_IN1
was causing grievous woe in the cm_step script. It turned out to fail intermittently at the command line, as did other LSC channels. (But non-LSC channels seem to be OK.) So we power cycled c1lsc (we couldn't ssh).
Then we noticed that computers were out of sync again (several timing fields said 16383 in the C0DAQ_RFMNETWORK screen). We restarted c1iscey, c1iscex, c1lsc, c1susvme1, and c1susvme2. The timing fields went back to 0. But the tdsavg command still intermittently said "ERROR: LDAQ - SendRequest - bad NDS status: 13".
The channel C1:LSC-SRM_OUT16 seems to work with tdsavg every time.
Let us know if you know how to fix this.
Did you try restarting the framebuilder?
What you type is in bold:
op440m> telnet fb40m 8087
Restarting the framebuilder didn't work, but the problem now appears to be fixed.
Upon reflection, we also decided to try killing all open DTT and Dataviewer windows. This also involved liberal use of ps -ef to seek out and destroy all diag's, dc3's, framer4's, etc.
That may have worked, but it happened simultaneously to killing the tpman process on fb40m, so we can't be sure which is the actual solution.
To restart the testpoint manager:
what you type is in bold:
rosalba> ssh fb40m
fb40m~> pkill tpman
The tpman is actually immortal, like Voldemort or the Kurgan or the Cylons in the new BG. Truly slaying it requires special magic, so the pkill tpman command has the effect of restarting it.
In the future, we should make it a matter of policy to close DTTs and Dataviewers when we're done using them, and killing any unattended ones that we encounter.
After poking around for a few minutes several facts became clear:
1) At least one GPIB interface has a hard ethernet connection (and does not currently go through the wireless).
2) The wireless on the laptop works fine, since it can connect to the router.
3) The rest of the martian network cannot talk to the router.
This led to me replugging the ethernet cord back into the wireless router, which at some point in the past had been unplugged. The computers now seem to be happy and can talk to each other.
I checked out a copy of matapps into /cvs/cds/caltech/apps/lscsoft so that I could find the matlab function strassign.m, which is necessary for some old mDV commands to run. I don't know why it became necessary or why it disappeared if it did.
Today I found the elog down, so I rebooted it following the instructions in the wiki.
I have the impression that Nodus has been rebooted since last night, hasn't it?
Sun Jun 21 00:06:43 PDT 2009
Mar 6 15:46:32 nodus sshd: [ID 800047 auth.crit] fatal: Timeout before authentication for 220.127.116.11
Mar 10 11:11:32 nodus sshd: [ID 800047 auth.crit] fatal: Timeout before authentication for 18.104.22.168
Mar 11 13:27:37 nodus sshd: [ID 800047 auth.error] error: connect_to 22.214.171.124 port 7000: Connection refused
Mar 11 13:27:37 nodus sshd: [ID 800047 auth.error] error: connect_to nodus port 7000: failed.
Mar 11 13:31:40 nodus sshd: [ID 800047 auth.error] error: connect_to 126.96.36.199 port 7000: Connection refused
Mar 11 13:31:40 nodus sshd: [ID 800047 auth.error] error: connect_to nodus port 7000: failed.
Mar 11 13:31:45 nodus sshd: [ID 800047 auth.error] error: connect_to 188.8.131.52 port 7000: Connection refused
Mar 11 13:31:45 nodus sshd: [ID 800047 auth.error] error: connect_to nodus port 7000: failed.
Mar 11 13:34:58 nodus sshd: [ID 800047 auth.error] error: connect_to 184.108.40.206 port 7000: Connection refused
Mar 11 13:34:58 nodus sshd: [ID 800047 auth.error] error: connect_to nodus port 7000: failed.
Mar 12 16:09:23 nodus sshd: [ID 800047 auth.crit] fatal: Timeout before authentication for 220.127.116.11
Mar 14 20:14:42 nodus sshd: [ID 800047 auth.crit] fatal: Timeout before authentication for 18.104.22.168
Mar 25 19:47:19 nodus sudo: [ID 702911 local2.alert] controls : 3 incorrect password attempts ; TTY=pts/2 ; PWD=/cvs/cds ; USER=root ; COMMAND=/usr/bin/rm -rf kamioka/
Mar 25 19:48:46 nodus su: [ID 810491 auth.crit] 'su root' failed for controls on /dev/pts/2
Mar 25 19:49:17 nodus last message repeated 2 times
Mar 25 19:51:14 nodus sudo: [ID 702911 local2.alert] controls : 1 incorrect password attempt ; TTY=pts/2 ; PWD=/cvs/cds ; USER=root ; COMMAND=/usr/bin/rm -rf kamioka/
Mar 25 19:51:22 nodus su: [ID 810491 auth.crit] 'su root' failed for controls on /dev/pts/2
Jun 8 16:12:17 nodus su: [ID 810491 auth.crit] 'su root' failed for controls on /dev/pts/4
12:06am up 150 day(s), 11:52, 1 user, load average: 0.05, 0.07, 0.07
12:06am up 150 day(s), 11:52, 1 user, load average: 0.05, 0.07, 0.07
tdsresp is broken on our linux control room machines. I made a little perl replacement which uses the DiagTools.pm perl module, called pzresp. It's in the $SCRIPTS/general directory, and so in the path of all the machines. I also edited the cshrc.40m file so that on linux machines tdsresp points to this perl replacement.
I've patched DiagTools.pm to circumnavigate the tdsdmd bug described here. I also added a function to DiagTools.pm called diagRespNoLog, which is just like diagResp but without that pesky log file.
Here's the output from the tdsresp binary on CentOS:
allegra:~>tdsresp 941.54 10000 100 10 C1:LSC-ITMX_EXC C1:LSC-PD1_Q C1:LSC-PD1_I
nan nan nan nan nan nan nan
nan nan nan nan nan nan nan
nan nan nan nan nan nan nan
*** glibc detected *** tdsresp: free(): invalid next size (fast): 0x089483e8 ***
======= Backtrace: =========
======= Memory map: ========
00242000-00249000 r-xp 00000000 fd:00 15400987 /lib/librt-2.5.so
00249000-0024a000 r--p 00006000 fd:00 15400987 /lib/librt-2.5.so
0024a000-0024b000 rw-p 00007000 fd:00 15400987 /lib/librt-2.5.so
009f9000-00a13000 r-xp 00000000 fd:00 15400963 /lib/ld-2.5.so
00a13000-00a14000 r--p 00019000 fd:00 15400963 /lib/ld-2.5.so
00a14000-00a15000 rw-p 0001a000 fd:00 15400963 /lib/ld-2.5.so
00a17000-00b55000 r-xp 00000000 fd:00 15400974 /lib/libc-2.5.so
00b55000-00b57000 r--p 0013e000 fd:00 15400974 /lib/libc-2.5.so
00b57000-00b58000 rw-p 00140000 fd:00 15400974 /lib/libc-2.5.so
00b58000-00b5b000 rw-p 00b58000 00:00 0
00b5d000-00b70000 r-xp 00000000 fd:00 15400984 /lib/libpthread-2.5.so
00b70000-00b71000 r--p 00012000 fd:00 15400984 /lib/libpthread-2.5.so
00b71000-00b72000 rw-p 00013000 fd:00 15400984 /lib/libpthread-2.5.so
00b72000-00b74000 rw-p 00b72000 00:00 0
00b76000-00b78000 r-xp 00000000 fd:00 15400981 /lib/libdl-2.5.so
00b78000-00b79000 r--p 00001000 fd:00 15400981 /lib/libdl-2.5.so
00b79000-00b7a000 rw-p 00002000 fd:00 15400981 /lib/libdl-2.5.so
00b7c000-00ba1000 r-xp 00000000 fd:00 15400975 /lib/libm-2.5.so
00ba1000-00ba2000 r--p 00024000 fd:00 15400975 /lib/libm-2.5.so
00ba2000-00ba3000 rw-p 00025000 fd:00 15400975 /lib/libm-2.5.so
00bca000-00bdd000 r-xp 00000000 fd:00 15401011 /lib/libnsl-2.5.so
00bdd000-00bde000 r--p 00012000 fd:00 15401011 /lib/libnsl-2.5.so
00bde000-00bdf000 rw-p 00013000 fd:00 15401011 /lib/libnsl-2.5.so
00bdf000-00be1000 rw-p 00bdf000 00:00 0
00dca000-00dd5000 r-xp 00000000 fd:00 15400986 /lib/libgcc_s-4.1.2-20080825.so.1
00dd5000-00dd6000 rw-p 0000a000 fd:00 15400986 /lib/libgcc_s-4.1.2-20080825.so.1
08048000-080b7000 r-xp 00000000 00:17 6455328 /cvs/cds/caltech/apps/linux/tds/bin/tdsresp
080b7000-080ba000 rw-p 0006e000 00:17 6455328 /cvs/cds/caltech/apps/linux/tds/bin/tdsresp
080ba000-080bb000 rw-p 080ba000 00:00 0
0893d000-0896b000 rw-p 0893d000 00:00 0 [heap]
f5e73000-f5e74000 ---p f5e73000 00:00 0
f5e74000-f6874000 rw-p f5e74000 00:00 0
f692d000-f6931000 r-xp 00000000 fd:00 15400995 /lib/libnss_dns-2.5.so
f6931000-f6932000 r--p 00003000 fd:00 15400995 /lib/libnss_dns-2.5.so
f6932000-f6933000 rw-p 00004000 fd:00 15400995 /lib/libnss_dns-2.5.so
f6956000-f6a12000 rw-p f6a31000 00:00 0
f6a74000-f6a7d000 r-xp 00000000 fd:00 15400997 /lib/libnss_files-2.5.so
f6a7d000-f6a7e000 r--p 00008000 fd:00 15400997 /lib/libnss_files-2.5.so
f6a7e000-f6a7f000 rw-p 00009000 fd:00 15400997 /lib/libnss_files-2.5.so
f6a7f000-f6a80000 ---p f6a7f000 00:00 0
f6a80000-f7480000 rw-p f6a80000 00:00 0
f7480000-f7481000 ---p f7480000 00:00 0
f7481000-f7e83000 rw-p f7481000 00:00 0
f7e83000-f7f63000 r-xp 00000000 fd:00 6236924 /usr/lib/libstdc++.so.6.0.8
f7f63000-f7f67000 r--p 000df000 fd:00 6236924 /usr/libAbort
Once again, this morning I found the wireless router disconnected from the LAN cable. No martian WiFi was available.
I wonder who is been doing that and for what reason.
I popped by the 40m, and was dismayed to find that all of the front end computers are red (only framebuilder, DAQcontroler, PEMdcu, and c1susvmw1 are green....all the rest are RED).
I keyed the crates, and did the telnet.....startup.cmd business on them, and on c1asc I also pushed the little reset button on the physical computer and tried the telnet....startup.cmd stuff again. Utter failure.
I have to pick someone up from the airport, but I'll be back in an hour or two to see what more I can do.
I think the problem was caused by a failure of the RFM network: the RFM MEDM screen showed frozen values even when I was power recycling any of the FE computers. So I tried the following things:
After Alberto's bootfest which was more successful than mine, I tried powercycling the AWG crate one more time. No success. Just as Alberto had gotten, I got the DAQ screen's AWG lights to flash green, then go back to red. At Alberto's suggestion, I also gave the physical reset button another try. Another round of flash-green-back-red ensued.
When I was in a few hours ago while everything was hosed, all the other computer's 'lights' on the DAQ screen were solid red, but the two AWG lights were flashing between green and red, even though I was power cycling the other computers, not touching the AWG at the time. Those are the lights which are now solid red, except for a quick flash of green right after a reboot.
I poked around in the history of the curren and old elogs, and haven't found anything referring to this crazy blinking between good and bad-ness for the AWG computers. I don't know if this happens when the tpman goes funky (which is referred to a lot in the annals of the elog in the same entries as the AWG needing rebooting) and no one mentions it, or if this is a new problem. Alberto and I have decided to get Alex/someone involved in this, because we've exhausted our ideas.
Today Alex came over, performed his magic rituals on the DAQAWG computer and fixed it. Now it's up and running again.
I asked him what he did, but he's not sure of what fixed it. He couldn't remember exactly but he said that he poked around, did something somewhere somehow, maybe he tinkered with tpman and eventually the computer went up again.
Now everything is fine.
Alex and Steve,
SunFire x4600 ( not MEGATRON 2 , it is fb40m2 ) and JetStor ( 16 x 1 TB drives ) were installed on side rails at the bottom of 1Y6
We cleaned up the fibres and cabling in 1Y7 also
The fb40m just went out of order with status indicator number 8
It recovered on its own five minutes later.
Yet again, the DAQAWG flipped out for an unknowable reason. In order of restart activities listed on the Wiki, I keyed the crate and nothing really happened, then I hit the physical reset button and nothing happened, and then I did the 'telnet....vmeBusReset', and a couple minutes later, it was all good again.
Backup script restarted, backup of trend frames and /cvs/cds is up-to-date.
I came into the 40m to sign things out briefly then swiftly return them, and the alarms were going off on op540m at 1am.
The cat and donkey? were making much noise.
All suspentions are kicked up. Sus dampings and oplev servos turned off.
c1iscey and c1lsc are down. c1asc and c1iovme are up-down
The computers and RFM network are up working again. A boot fest was necessary.Then I restored all the parameters with burtgooey.
The mode cleaner alignment is in a bad state. The autolocker can't get it locked. I don't know what caused it to move so far from the good state that it was till this afternoon. I went tuning the periscope but the cavity alignment is so bad that it's taking more time than expected. I'll continue working on that tomorrow morning.
I now suspect that after the reboot the MC mirrors didn't really go back to their original place even if the MC sliders were on the same positions as before.
we diagnosed the problem. It was related with sticky sliders. After a reboot of C1:IOO the actual output of the DAC does not correspond anymore to the values read on the sliders. In order to update the actual output it is necessary to do a change of the values of the sliders, i.e. jiggling a bit with them.
I've updated the slider twiddle script to include the MC alignment biases. We should run this script whenever we reboot all the hardware, and add any new sticky sliders you find to the end of the script. It's at
in the rack next to the printer. It sounds like a fan is hitting something.
I compiled and ran a simple (i.e. empty) front end controller on scipe12 at wilson house. I hooked a signal into the ADC and watched it in the auto-generated medm screens.
There were a couple of gotchas:
1. Add an entry SYS to the file /etc/rc.local, to the /etc/setup_shmem.rtl line, where the system file is SYS.mdl.
2. If necessary, do a BURT restore. Or in the case of a mockup set the BURT Restore bit (in SYS_GDS_TP.adl) to 1.
This morning I found the elog down. I restarted it using the procedure in the wiki.
Yesterday, Jay brought over the IO box for megatron, and got it working. We plan to firewall megatron this afternoon, with the help of Jay and Alex, so we can set up GDS there and play without worrying about breaking things. In the meantime, we went to Wilson House to get some breakout boards so we can take transfer functions with the 785, for an ETMX controller. We put in a sine wave, and all looks good on the auto-generated epics screens, with an "empty" system (no filters on). Next we'll load in filters and take transfer functions.
Unfortunately we promised to return the breakout boards by 1pm today. This is because, according to denizens of Wilson House, Osamu "borrowed" all their breakout boards and these were the last two! If we can't locate Osamu's cache, they expect to have more in a day or two.
Here is the transfer function of the through filter working at 16KHz sampling. It looks fine except for the fact that the dc gain is ~0.8. Koji is going to characterize the digital down sampling filter in order to try to compare with the generated code and the filter coefficients.
Just now found it dead. Restarted it. Is our elog backed up in the daily backups?
Alex has firewalled megatron. We have started a framebuilder there and added testpoints. Now it is possible to take transfer functions with the shared memory MDC+MDP sandbox system. I have also copied filters into MDC (the controller) and made a really ugly medm master screen for the system, which I will show to no one.
Yesterday we found that the channel C1:MDP-POS_EXC looked distorted and had what appeared to be doubled frequency componenets, in the dataviewer. This was because the dcu_rate in the file /caltech/target/fb/daqdrc was set to 16K while the adl file was set to 32K. When daqdrc was corrected it was fixed. I am going to recompile and run all these models at 16K. Once the 40 m moves over to the new front end system, we may find it advantageous to take advantage of the faster speeds, but maybe it's a good idea to get everything working at 16K first.
Last night Rana noticed that the overflows on the ITM and ETM coils were a crazy huge number. Today I rebooted c1dcuepics, c1iovme, c1sosvme, c1susvme1 and c1susvme2 (in that order). Rob helped me burt restore losepics and iscepics, which needs to be done whenever you reboot the epics computer.
Unfortunately this didn't help the overflow problem at all. I don't know what to do about that.
Just start by re-setting them to zero. Then you have to figure out what's causing them to saturate by watching time series and looking at spectra.
We put a simple pendulum into the MDP model, and everything communicates. We're still having some kind of TP or daq problem, so we're still in debugging mode. We went back to 32K in the .adl's, and when driving MDP, the MDC-ETMX_POS_OUT is nasty, it follows the sine wave envelope but goes to zero 16 times per second.
The breakout boards have arrived. The plan is to fix this daq problem, then demonstrate the model MDC/MDP system. Then we'll switch to the "external" system (called SAM) and match control TF to the model. Then we'd like to hook up ETMX, and run the system isolated from the rest of the IFO. Finally we'd like to tie it into the IFO using reflective memory.
FB40m up and running again after restarting the DAQ.
I added a clock to the PMC medm screen.
I made a backup of the original file in the same directory and named it *.bk20090805
The daq on megatron was nuts. Alex and I discovered that there was no gds installation for site_letter=C (i.e. Caltech) so the default M was being used (for MIT). Apparently we are the first Caltech installation. We added the appropriate line to the RCG Makefile and recompiled and reinstalled (at 16K). Now DV looks good on MDP and MDC, and I made a transfer function that replicates bounce-roll filter. So DTT works too.
Ever since July 22, the backup script that runs on fb40m has failed to ssh to ldas-cit.ligo.caltech.edu to back up our trend frames and /cvs/cds.
This was a new failure mode which the scripts didn't catch, so I only noticed it when fb40m was rebooted a couple of days ago.
Alex fixed the problem (RAID array was configured with the wrong IP address, conflicting with the outside world), and I modified the script ( /cvs/cds/caltech/scripts/backup/rsync.backup ) to handle the new directory structure Alex made.
Now the backup is current and the automated script should keep it so, at least until the next time fb40m is rebooted...
Today I was able to make low frequency transfer function with DTT on megatron. There seems to have been a timing problem, perhaps Alex fixed it or it is intermittent.
I have attached the open loop transfer function for the un-optimized system, which is at least stable to step impulses with the current filters and gains. The next step is to optimize, transfer this knowledge to the ADC/DAC version, and hook it up to isolated ETMX.