• Please review our updated Terms and Rules here

VaxStation 4000 VLC '?? C?? CRPT - Corrupt bit is set' ERROR

AK6DN

AK6DN

Veteran Member
Joined
Aug 23, 2010
Messages
1,294
Location
Silicon Valley USA
So this morning I powered on both of my venerable Vaxstation 4000 VLC systems (one VMS, one BSD) and they BOTH failed the exact same way:

?? C?? CRPT - Corrupt bit is set

message repeats endlessly. I can't find that error message in any of the DEC service manuals I have PDFs of. Searching online gives a bit of a clue that it might be related to the Dallas clock chips (which I last replaced about 9-10 years ago, I guess, with DS12887A devices. Both systems have been running fine for the last 10 years or so. I power them on once every month or two to play with them.

So I ordered some new DS12887A devices from Mouser, replaced it in one system, and the error message does not change. I can't get the console to respond to any keyboard interrupt (or sending a BREAK). I tried the 'system password clear' by shorting across the triangles on the PCB during power on. Still no joy.

So anybody have any ideas on this? If the clock chip went bad (battery dead) and I replace it with a new device, do I need to do some special power on sequence? The clock chip is not in the FRU list so the manuals are of little help.

Any ideas?

I read one thread I found where someone made a replacement PCB to allow one to use a plain DS12885 chip + a battery and crystal on a carrier PCB in place of the DS12887A, but the thread stops when it gets interesting.

Don
 
Some more info ...

Two digit hex display leds seem to be cycling between 0xFC (sizing memory) and 0xFA (memory test). Does this mean I have a memory problem? Both systems have the same 24MB memory modules I have had in them since I got them. Never changed, working fine forever. Or at least until today?

If I force a 'send break' keyboard sequence I can sometimes get the response:

?? CRPT - Reenter bit clr

but then it goes back to producing the original 'Corrupt bit is set' error every 15 sec or so.
 
First thing that comes to mind is the new module is not initialized. Most Suns are the same way and need to be reprogrammed at the PROM.
 
NeXT said:
First thing that comes to mind is the new module is not initialized. Most Suns are the same way and need to be reprogrammed at the PROM.
Click to expand...

I guess I can understand that, but unfortunately I can no longer issue any console commands (like SHOW DEVICE etc). It never gets to the >>> command prompt.

It may be that this 'Corrupt bit is set' error is due to some other cause besides the RTC chip having gone bad, but I can find no references to this specific error in any manual.

And the fact that both systems, one with BSD, the other with VMS, failed exactly the same way at the same time. Very perplexing.

Don
 
DECtechGuy said:
maybe try dropping in one of these? https://www.ebay.com/itm/GW-12887-1...727960?hash=item3fa34dda18:g:an4AAOSwFLBab95j

Could be your clock chips just happened to fail at the same time.

Only other thing I can think of is your firmware has failed, but it'd be just as weird for them both to fail at the same time as your RTCs.
Click to expand...

Well, I had DS12887A devices in both systems that I put in about 10yrs ago to replace previous dead RTC chips that were in the systems which I got them (original devices).
That this error came up ~10yrs after replacing the devices that have a '10 yr lifetime' I don't believe is a coincidence.
So I had '887A devices working fine for ~10yrs with no issues. Bought exact same replacement devices for $10ea at mouser as new replacements.
Inserting the new devices did not fix the problem, so I am thinking something else must be going on, but what?

Don
 
Ok, so I seem to have found a solution. Don't know why it works, but it does for me. Both systems.

What I have seen is LED error codes starting at 0xFF (powerup) then gets into a loop of 0xFC (memory sizing) and 0xFA (memory dpath test).

So to fix this, I turned system off, unplug the console serial cable, turn back on and then the LEDs go from 0xFF down to 0xF3 (entering console program).

Then I turn it back off, plug in the console cable, and when I reboot the normal CPU ID text appears along with the memory testing bars.
And then it gets to the command prompt where I can SHO DEVICE, SET BOOT DKA100, etc commands.
Back to working as it should.

Don
 
DECtechGuy said:
maybe try dropping in one of these? https://www.ebay.com/itm/GW-12887-1...727960?hash=item3fa34dda18:g:an4AAOSwFLBab95j

Could be your clock chips just happened to fail at the same time.

Only other thing I can think of is your firmware has failed, but it'd be just as weird for them both to fail at the same time as your RTCs.
Click to expand...

I just replaced the original DS1287A in my VAXstation 400/VLC with one of these replacements from Glitch. It worked great. I didn't have to initialize it before installing it in the VLC.
 
Alphasite said:
I just replaced the original DS1287A in my VAXstation 400/VLC with one of these replacements from Glitch. It worked great. I didn't have to initialize it before installing it in the VLC.
Click to expand...

So is your VLC setup with a local keyboard and monitor, or do you use a serial connection to the console port on the back (as I do)?

My VLC are setup as network servers only, no local keyboard or monitor. I only access via local serial console or telnet(VMS)/ssh(BSD) over the network.

Don
 
Really strange fix for a weird problem with a stunning level of coincidence.

All I can do is conjecture as to what the issue was. Clearly the VLC didn't want to go much further with your console cable plugged in. Makes me wonder if the cable is fishy, like a short or something. DEC did have loopback adapters for serial ports to activate certain service features on VAXes. The error message and the points at which your LED error codes we're looping makes it look like both VLCs couldn't get past test F9 (console data structures). So I guess there's a console fluke somewhere?

And when you say back to working as it should, is that consistently?

For what its worth, I use my VLC in its traditional graphics workstation setup so I've never messed around with the serial port.
 
DECtechGuy said:
Really strange fix for a weird problem with a stunning level of coincidence.

All I can do is conjecture as to what the issue was. Clearly the VLC didn't want to go much further with your console cable plugged in. Makes me wonder if the cable is fishy, like a short or something. DEC did have loopback adapters for serial ports to activate certain service features on VAXes. The error message and the points at which your LED error codes we're looping makes it look like both VLCs couldn't get past test F9 (console data structures). So I guess there's a console fluke somewhere?

And when you say back to working as it should, is that consistently?

For what its worth, I use my VLC in its traditional graphics workstation setup so I've never messed around with the serial port.
Click to expand...

The systems got stuck it appears in a loop around 0xFC (sizing memory) and 0xFA (memory test). I left them running for at least an hour like this to see if they might eventually break out into console mode, but no. Just kept spewing the 'Corrupt bit is set' message every 20sec or so.

I use third party commercial DEC cable adapters for the console cables, with a 6pin to DE9 adapter on the back of my PC. No problems with these.

The VLC can detect whether a cable is connected to something at the other end, as the 'BREAK condition' is detected and used by the console.
IE, if I use TeraTerm I select 'send break' to interrupt the CPU and force it back to console command mode.

So my suspicion is that when a virgin/corrupt clock/nvram is detected it 'needs' a console serial to be in the breaking state to proceed thru the sequence. Once that is done, at least once, the NVRam gets setup and the presence of a console device is ok on subsequent boots.

I have now power cycled and rebooted the systems (one NetBSD, one VMS) multiple times and they work as expected from the command line.

So ... problem solved. Not exactly sure why, but in ten years from now (if I'm lucky) I'll deal with it again.

Don
 
AK6DN said:
So is your VLC setup with a local keyboard and monitor, or do you use a serial connection to the console port on the back (as I do)?

My VLC are setup as network servers only, no local keyboard or monitor. I only access via local serial console or telnet(VMS)/ssh(BSD) over the network.

Don
Click to expand...

I'm using a serial console. My mouse isn't working and I haven't determined if it's the mouse or the mouse port. I need to test with my 4000/96 and see if the mouse works there.
 
AK6DN said:
The systems got stuck it appears in a loop around 0xFC (sizing memory) and 0xFA (memory test). I left them running for at least an hour like this to see if they might eventually break out into console mode, but no. Just kept spewing the 'Corrupt bit is set' message every 20sec or so.

I use third party commercial DEC cable adapters for the console cables, with a 6pin to DE9 adapter on the back of my PC. No problems with these.

The VLC can detect whether a cable is connected to something at the other end, as the 'BREAK condition' is detected and used by the console.
IE, if I use TeraTerm I select 'send break' to interrupt the CPU and force it back to console command mode.

So my suspicion is that when a virgin/corrupt clock/nvram is detected it 'needs' a console serial to be in the breaking state to proceed thru the sequence. Once that is done, at least once, the NVRam gets setup and the presence of a console device is ok on subsequent boots.

I have now power cycled and rebooted the systems (one NetBSD, one VMS) multiple times and they work as expected from the command line.

So ... problem solved. Not exactly sure why, but in ten years from now (if I'm lucky) I'll deal with it again.

Don
Click to expand...

i didn't need to send a BREAK when I installed the DS12887 replacement from Glitch.

What does stick somewhere in the back of my mind is a problem years ago with a VAX that wouldn't start properly due to a problem with the console. The details are fuzzy as it was about 20 years ago but I think the problem was with the terminal misbehaving. We replaced the console cable or VT420. If you are using a terminal emulator attached to a PC maybe it got into a strange state.
 
Alphasite said:
i didn't need to send a BREAK when I installed the DS12887 replacement from Glitch.

What does stick somewhere in the back of my mind is a problem years ago with a VAX that wouldn't start properly due to a problem with the console. The details are fuzzy as it was about 20 years ago but I think the problem was with the terminal misbehaving. We replaced the console cable or VT420. If you are using a terminal emulator attached to a PC maybe it got into a strange state.
Click to expand...

I'm using TeraTerm on a WinXP PC. I have two separate VLC systems connected by two separate cables to a 2port PCI serial card.

My (unfounded) suspicion is that when the VLC ROM comes upon a corrupt/virgin NVRAM as in the new clock chip, it is confused about the configuration of the system console port, and gets in this funky loop. I know that the console serial cable must be plugged into a controller port when the box is running; if I unplug it while BSD or VMS has been booted it causes the VLC to drop into the console command prompt, just like a sent a BREAK sequence via TeraTerm.

Anyway, above is based upon observation and not any internal probing of the box. It may be totally wrong.

But unplugging the cable, letting the VLC run thru (what appears) to be a complete boot sequence for the console code (based on diagnostic LEDs) allows the NVRam to be setup (correctly) so that the next time it boots correctly to the command line with the serial console cable connected to the PC.

Don
 
You must log in or register to reply here.
Back
Top