PXI-8176 Bootup

[orko]

Fellow RT firefighters,

I have a rack with two PXI-1010 chassis housing identical PXI-8176 controllers. They are configured identically (same versions of the RT engine, VISA, etc).

One of the controllers decided one day to not boot. It will get past the network initialization, but hang before (or during...not sure) the NI-VISA server startup. In other words it would not display the NI-VISA startup text. It will reboot three times after power up at the same spot, then sit in safe mode. I am able then to FTP in and have backed up the whole disk by downloading all of the folders/files with no issue. BTW, turning on the extended memory check in BIOS doesn't produce any failures on boot.

The other controller was working, and booting the NI-VISA server and starting the LabVIEW RT-OS just fine. By swapping the good controller with the bad, I was able to isolate the problem down to the controller itself and not the chassis. Memory swap between controllers didn't change the symptoms. Seeing that the hardware was identical on each controller, and the software installed was identical except for the configuration files for the modules, I decided to swap the HDD from the bad controller into the good to verify that the HDD or software was the cause of the lockups. It exhibited the same lockup issues in the good controller as expected. I then installed the good HDD in the bad controller...my mistake. It now exhibits the same lockups! Swapping it back to its original controller it is now acting exactly like the other one, rebooting at the same point...

Now I have two bad controllers... so on one hand it looks like the first controller that went bad has a bad IDE interface that is corrupting data(?). But that seems unlikely since the symptoms that it caused are exactly the same at the same point of bootup... this almost looks like a bad driver or software related failure, but then how did the good HDD get messed up all by itself when installed into the suspect controller? These are Fujitsu 20GB hard drives BTW and worked fine when they were first set up.

Now another point to mention is that the recovery CD's for the PXI controller are nowhere to be found. We suspect a contractor has them in their desk somewhere, but the main thing is getting one so we can attempt to resurrect the originally "GOOD" controller. Does anyone know where I could get/download a copy?

I've never done a reload before, but reading into it, it appears that we would be able to boot off of a DOS boot disk w/network support and map a remote CDROM as a shared drive to start the recovery.bat process. Then transfer over the target application software from our backups we made.

If I'm missing anything or you have any ideas, please someone provide some insight! I know this is probably something that has occurred with a handful of you at one point or another. ;-)

THANKS IN ADVANCE! WE ARE CURRENTLY IN "HOT" MODE TO FIX THIS, SO I WOULD WHOLE-HEARTEDLY APPRECIATE ANY FEEDBACK YOU MAY HAVE. FEEL FREE TO DIRECTLY EMAIL ME.

Joe Sines

SinesJP@kpt.nuwc.navy.mil

[Dan Press]

We recently experienced a similar issue, or I should say a set of issues that acted something like that.

The first and easiest thing to check is what you have installed on the RT side. If you have NI-IMAQ and NI-IMAQ-1394 installed at the same time, there could be a hang at bootup. That is a known issue, although I have not seen any fix for it. The workaround is to only have one or the other installed... or neither if you do not need image acquisition.

If you do not have IMAQ or IMAQ-1394, the problem could be VISA. There has been a rash of new VISA versions lately, and you could make sure you're on the latest and greatest.

Our current RT fire is burning on a generic desktop target. We have had to send the complete system to NI three times so that the R&D folks could fix driver and OS-level problems. We currently have an experimental build of the RTOS with slightly hacked Ethernet drivers. However, on a PXI controller, the step should not be necessary.

What version of everything are you using now?

Empathizing,

Dan Press

PrimeTest Automation

[orko]

The first and easiest thing to check is what you have installed on the RT side. If you have NI-IMAQ and NI-IMAQ-1394 installed at the same time, there could be a hang at bootup. That is a known issue, although I have not seen any fix for it. The workaround is to only have one or the other installed... or neither if you do not need image acquisition.

We are not using IMAQ

If you do not have IMAQ or IMAQ-1394, the problem could be VISA. There has been a rash of new VISA versions lately, and you could make sure you're on the latest and greatest.

I'll check to see...

What version of everything are you using now?

From MAX:

LV Realtime 7.1

NI-VISA Server 3.2

NI-VISA 3.2

NI-DAQmx 7.3.0

Traditional NI-DAQ 7.3.0

Language support for LV RT 1.0.0.1

Is there some way that a driver configuration of VISA or otherwise could cause a RT controller not to boot? I'm trying to wrap my brain around this, but am having difficulty figuring out what would cause a reboot in the exact same spot when I swapped the known good hard drive into the suspect controller... :headbang:

[Guest terminator]

You might want to look at this, it may be possible to reinstall from files on disk

http://zone.ni.com/devzone/conceptd.nsf/we...6256D080074AD58

(search for PXI system reinstall)

never did this myself, thought I might need to but didn't.

Fellow RT firefighters,

I have a rack with two PXI-1010 chassis housing identical PXI-8176 controllers. They are configured identically (same versions of the RT engine, VISA, etc).

One of the controllers decided one day to not boot. It will get past the network initialization, but hang before (or during...not sure) the NI-VISA server startup. In other words it would not display the NI-VISA startup text. It will reboot three times after power up at the same spot, then sit in safe mode. I am able then to FTP in and have backed up the whole disk by downloading all of the folders/files with no issue. BTW, turning on the extended memory check in BIOS doesn't produce any failures on boot.

The other controller was working, and booting the NI-VISA server and starting the LabVIEW RT-OS just fine. By swapping the good controller with the bad, I was able to isolate the problem down to the controller itself and not the chassis. Memory swap between controllers didn't change the symptoms. Seeing that the hardware was identical on each controller, and the software installed was identical except for the configuration files for the modules, I decided to swap the HDD from the bad controller into the good to verify that the HDD or software was the cause of the lockups. It exhibited the same lockup issues in the good controller as expected. I then installed the good HDD in the bad controller...my mistake. It now exhibits the same lockups! Swapping it back to its original controller it is now acting exactly like the other one, rebooting at the same point...

Now I have two bad controllers... so on one hand it looks like the first controller that went bad has a bad IDE interface that is corrupting data(?). But that seems unlikely since the symptoms that it caused are exactly the same at the same point of bootup... this almost looks like a bad driver or software related failure, but then how did the good HDD get messed up all by itself when installed into the suspect controller? These are Fujitsu 20GB hard drives BTW and worked fine when they were first set up.

Now another point to mention is that the recovery CD's for the PXI controller are nowhere to be found. We suspect a contractor has them in their desk somewhere, but the main thing is getting one so we can attempt to resurrect the originally "GOOD" controller. Does anyone know where I could get/download a copy?

I've never done a reload before, but reading into it, it appears that we would be able to boot off of a DOS boot disk w/network support and map a remote CDROM as a shared drive to start the recovery.bat process. Then transfer over the target application software from our backups we made.

If I'm missing anything or you have any ideas, please someone provide some insight! I know this is probably something that has occurred with a handful of you at one point or another. ;-)

THANKS IN ADVANCE! WE ARE CURRENTLY IN "HOT" MODE TO FIX THIS, SO I WOULD WHOLE-HEARTEDLY APPRECIATE ANY FEEDBACK YOU MAY HAVE. FEEL FREE TO DIRECTLY EMAIL ME.

Joe Sines

SinesJP@kpt.nuwc.navy.mil

[orko]

You might want to look at this, it may be possible to reinstall from files on disk

http://zone.ni.com/devzone/conceptd.nsf/we...6256D080074AD58

(search for PXI system reinstall)

never did this myself, thought I might need to but didn't.

Thanks! I found that and was excited...but then shortly afterward was shot down when I found that there wasn't an /images directory on my HDD.

[LAVA 1.0 Content]

Thanks! I found that and was excited...but then shortly afterward was shot down when I found that there wasn't an /images directory on my HDD.

Maybe I'm missing something here, but can you connect to the LV RT controller from MAX on your development system to format the drive and reload the SW? If necessary in MAX you can generate a boot disk for your RT controller to boot it into safe mode and connect from MAX.

Configure RT Series PXI controllers with the RT Engine pre-installed. In MAX, select Help

[orko]

Maybe I'm missing something here

Yes, I was missing something too I was assuming that we had all we needed on the host machine, but was very perterbed to find out that we neither had the recovery CDs, nor the LV RT dev environment! Ugh. Evidently the contractors left us with nothing to fix the system with!

Anyway, GOOD NEWS! I was googling and ran across a KB that dealt with a different problem, but I'm thinking that it had the same cause. It can be found Here. Deleting the files mentioned in the KB and rebooting both PXI controllers re-initialized these configuration database files and both of them booted normally!

According to the KB above, these files may become corrupt when power is removed during read/write access to them. I think this is what happened to my first controller. As far as I can tell, when the second controller's hard drive was put in the suspect controller, it got confused because the configuration files stored didn't match the controller it was in (??)

This is a learning experience, to say the least. These configuration database files are in my mind akin to "registry" files that everone should be aware of. Stumbling onto this KB article was pure luck for me since it looked like it only applied to one kind of error. It seems like they would also have a "PXI chassis reboots three times and fails to Safe Mode" KB with the above procedure to try... this really saved my hide!

Thanks for all your responses, and I hope this thread can help someone in the future.