DTC48 mystery

[Fred Martin_1]

I had a DTC48 which was working (running terminals and a serial printer from it). When it was no longer needed, it became a working spare. I left the dtcmanager config and ddfa settings alone; just turned it off and unplugged it.

There are OCD processes still running in fact, from when it was a 'production' DTC.

Recently I'm having troubles with another DTC48 and so, hooked this one back up to the network.

Nothing has changed on the network; subnets, IP address, etc. etc. all the same. Still have the DTCs IP address reserved in DNS.

Now this working spare won't boot.

When I power it up, this appears in syslog:

Apr 25 16:34:51 corp ocd[22513]: (109) ERROR: Cleaning up daemon for pseudonym /dev/dtc5b0p05 and device at node 192.168.236.79 board 0 port 5

That's from the OCD process for the printer which was configured on that DTC.

On the DTC, I get a flashing C1.

dtcping returns 100% packet loss.

dtcdiag -r returns normally, as though the reset worked, but I still get a C1.

dtclist shows a current event with CodeDownloadError, for this DTC.

I restarted rbootd, dtcmgr and ddfa to make sure they were all running; that had no effect.

I'm having a hard time believing that a board has gone bad in the DTC while it sat unused and unpowered.

Are there any other things I can try in terms of troubleshooting?

Thanks in advance,

Fred

[Steven E. Protter]

Shalom Fred,

Its a known fact that power supply fans and such are better off left running. Left off, dust accummulates and they get gummed up.

The device needs service if that is possible.

SEP

[Fred Martin_1]

Well, I tried to bring this DTC up because I have another that exhibits the same behavior. We had a power outage here at the server end. The trouble DTC48 also lost power, and of course by spare was already unpowered. All the other DTC48's kept power at their remote locations.

Since they are both having issues now, I'm afraid if I shut down another one somewhere else, it will also be unable to boot. (can't afford to do that test, they're all in use)

Just a hunch but it seems that the issue is on the server/dtcmanager side.

As I mentioned I've re-started the daemons rbootd, dtcnmd and dtcnmp, and even ddfa.

I'll clean up the one I've got in the meantime but any other suggestions would be welcome.

[Fred Martin_1]

A very long time ago, I was working with an HP software support person on a similar issue, and he had given me something to run from the command line, that verified that the server could talk to the DTC. I'm struggling to remember it, and I don't believe it's one of the DTC commands shown in the DTC manual. It had a parameter which I can't remember. 'loop', maybe?

Does this sound familiar to anyone?

And - these DTC48's are no longer supported by HP - what is the current modern (supportable) equivalent from HP? Does it use the same dtcmanager software and daemons?

Fred

[Fred Martin_1]

And, a linkloop to the hardware address of the DTC is successful:

# linkloop -v 0x080009287db0
Link connectivity to LAN station: 0x080009287db0
-- OK

[Fred Martin_1]

Ok, I've just realized that dtcconfig can't talk to -any- of my DTCs including a DTC72.

For others, it says the DTC is not responding but lets me view the current config. For the two DTCs I've been discussing, it just says it can't perform the task and won't let me view the config.

I'm convinced now, if I were to power cycle a working DTC it would also stop working.

Any ideas please?

[Fred Martin_1]

Also the dtcnmp.log file continues to grow while the DTC48 displays the C1....

Fri Apr 27 14:54:02 2007 <4017> : timeout waiting for response from DTC
Fri Apr 27 14:54:02 2007 <4017> : timeout waiting for response from DTC
Fri Apr 27 14:54:03 2007 <4017> : timeout waiting for response from DTC
Fri Apr 27 14:54:03 2007 <4017> : timeout waiting for response from DTC

Restarting dtcmgr clears the log, but as long as the dtc48 tries to download, the entries start in again.

[Fred Martin_1]

And they lived happily ever after....

I deleted the config for the spare DTC48 and re-created it.

It booted right up.

I'm assuming that I'll have to rebuild the config for all of my DTCs, and then all will be well again with the world.

The power outage (which, after batteries went dead, dropped the power on my unix box) must have corrupted the DTC configs in some way.

[Fred Martin_1]

Well here's a suprise, and my final note.

After repairing the configs for the two DTCs that weren't working, all the other configs appear to be OK now, where earlier the software wouldn't allow me to modify them.

Power-cycled a couple of the others and they booted to F2 alright.