Sorry for the late reply, here's the summary of all the responses I got
for restoring communications on my Mercury Plus 400 running VnmrJ 1.1D
on RHEL WS 4. Original post is as follows:
-----------------------------------------------------------------------
Greetings,
Having some severe communication problems with my Mercury Plus
400MHz with ATB probe on Linux (RHEL WS 4 running VnmrJ 1.1D). I
recently lost communication with the console, and no amount of 'su
acqproc', 'su acqproc' followed by console reset, and /vnmr/bin/setacq
has brought it back. I am also unable to 'ping inova', I always get a
'destination host unreachable' error when I try to 'ping inova' (inova
is listed in /etc/hosts). Here is what I have tried so far:
Using the configuration I had before (console connected to standard
ethernet port, network connected to second ethernet port):
su acqproc
su acqproc + console reset
/vnmr/bin/setacq
Tried this with both 'console connected to standard ethernet port',
and 'console connected to second ethernet port'.
None of these worked
Using a different configuration (console connected to second ethernet
port, network connected to standard ethernet port)
su acqproc
su acproc + console reset
/vnmr/bin/setacq
Tried this with both 'console connected to standard ethernet port',
and 'console connected to second ethernet port'.
These haven't worked either. Neither has a power cycle of the console
I then switched the cards, so that eth0 is now eth1 and vice versa, and
also no luck on that, using the same methods as above.
I am using 172.16.0.1 for the console IP, which is reflected in the
/vnmr/acq/bootptab
I also tried a different crossover cable, and that doesn't seem to be
the issue. I'm going to swap out the comm board with a mercury 300
tomorrow to see if it's the board, does anyone have any other
suggestions? At this point I'm willing to try anything. I checked the
comm board that I have, it's not the one that has communication problems
(some of the mercury communication boards had repeated problems with
'inactive Status' messages because of a bug with the chip, but this comm
board should be okay).
This may be unrelated, but just in case, I was tuning for 31P a couple
of days ago. I tuned, acquired, got the spectrum and then tuned back to
13C. For some reason I lost lock after that, and got it back for just a
little while before I lost it again and could not get a signal on D2O.
The next day I still didn't have a lock, and that was when the 'inactive
Status' occurred, which has so far been unrecoverable.
ANY suggestions would be greatly appreciated, as I'm out of ideas on
this one. Of course, this all happens the week before I'm due to go on
vacation......
Thanks for any assistance,
-----------------------------------------------------------------------
In the end, I reloaded Linux and VnmrJ 1.1D, and everything seems to work well now.
Curiously, I could get a setacq on my old Sun, and then run from there, but
never on the Linux box.
In addition to the above, I tried:
Swapping the CPU card with another Mercury
Double checking the firewall settings
Editing /vnmr/bin/setacq to use a different IP (this didn't work, so I reverted
to using the original /vnmr/bin/setacq
Editing /etc/hosts
But none of these worked, so I went for a total reload. There was probably a
less drastic solution than a complete reload of the OS (maybe just reload VnmrJ),
but it seemed that the OS reload would take care of everything and restore
it to defaults, and so far that has worked. From talking to others, this
intractable inactive status problem seems to be pretty rare. One thing to
note was that the Mercury did NOT like the 10.0.0.1 IP address, I had to use
172.16.0.1 for communication to the console.
Carlos Pacheco posted a similar problem about two years ago, here's the
link to his summary:
http://chemnmr.colorado.edu/ammrl/archives/November-2004/26.html
Thanks to David Vander Velde, Charles Fry, Joseph Massey, Alberto Ramirez,
Lilong Li, Martha Morton, Dave Scott, and Ken Kezeor. Special thanks to Ghirmai
Meresi, Dean Alexander and Andrew Lewis for their conversations and assistance.
All responses are summarized below. Cheers,
Chris
-----------------------------------------------------------------------
Hello,
Do you have the firewalls enabled? If so, you need to disable them and
then run a setacq.
-----------------------------------------------------------------------
Does the RedHat box have anything to say about the ethernet ports
in /var/log?
hth,
-----------------------------------------------------------------------
I have an Inova and my answer is based on the Inova architecture.
It sounds like your PC is fine. Your having a problem with the
communications card in the Mercury. This is the CPU card on my Inova.
Do you have another Mercury around that your could do a board swap
with? If not, I'd contact Varian about getting an exchange for it.
This card is flaky on my Inova. Have you cycled the power to the
Mercury? It can be miraculous.
Good Luck,
-----------------------------------------------------------------------
Is there any changes of network settings at all on this site? For
example, setting up an NIS? Something I could think of that can happen
this way is that NIS service is activated, and in /etc/nsswich.conf, the
hosts line looks like this:
hosts: nis dns
instead of
hosts: files nis dns
which means that in name resolving, the computer wouldn't look at
/etc/hosts file at all.
Or maybe NIS service is activated but not working properly.
Just a wild thought. But it looks like the computer is having name
resolving issue.
-----------------------------------------------------------------------
I think your next step is correct in trying another CPU. Yours may not be
booting up. We are able to do run tip hardwire on Sun computers or the
"cu" command on Dell with the VNMRS to check for bootup of a
board.
But I have not been able to do this on MVX cpu & Dell.
Usually when you cannot ping inova (or "destination host
unreachable"), it means:
a) acquisition CPU did not bootup
b) eth1 (main NIC connected to console) is disabled or not configured
properly
If you can ping wormhole, then you're talking to the eth1 NIC (on board
port), which should have an IP address= 172.16.0.1.
Also, /etc/hosts should include wormhole (172.16.0.1), inova
(172.16.0.2), & inovaauto (172.16.0.4)
In /etc/bootptab, near the bottom you should see a line: ha=####
....this # should match the MAC address sticker on your acq cpu. This
means setacq was able to read & transfer this number from the CPU
-----------------------------------------------------------------------
What does your /etc/hosts, file look like? All of our Mercury and INOVA
systems use 10.0.0.1 - 4 standard for the console entries:
Example /etc/hosts
127.0.0.1 localhost
130.101.58.200 mercury300 # LAN NIC
10.0.0.1 wormhole # Instrument NIC
10.0.0.2 inova # Mercury console
10.0.0.4 autoinova
These are all on SUN Solaris, but I don't see why there should be any
difference between the two OS types here when referring to the console
-----------------------------------------------------------------------
Sounds like a real mess. I believe it is likely that you've had the
comm board go on the console, and will have to replace it. But perhaps
something simpler has happened.
I wonder about the 172.16.0 you are using. Has this always been true?
We are working to upgrade from our Sun to a Linux PC, and we tried to
get ours working with 172.16.0 without success. As soon as we edited
/vnmr/bin/setacq and replaced everything there having 172.16.0 with
10.0.0 (which follows bug-id: setacq.j1106), then all started working ok
for us. Is is possible your IP address got changed somehow?
If you try the 10.0.0, make sure, of course, that you backup all the
changed files so you can go back to the way you are now.
Can't think of anything else.
IPs unless using a single NIC router configured system.
into the bootptab in /etc (means eth1 & cable is ok).
Are you missing some DC power supplies or have bad AC ripple on DC?
Received on Mon Nov 13 2006 - 11:04:53 MST