NVRAM error on DEC 3000/300X - DEC
This is a discussion on NVRAM error on DEC 3000/300X - DEC ; I have a DEC 3000/300X, and it is giving an "Unexpected interrupt"
message when booting and when attempting to use "SHOW CONFIG". "T NVR"
in SRM fails with a 400 (interrupt test failed) error code. All the
other tests appear ...
-
NVRAM error on DEC 3000/300X
I have a DEC 3000/300X, and it is giving an "Unexpected interrupt"
message when booting and when attempting to use "SHOW CONFIG". "T NVR"
in SRM fails with a 400 (interrupt test failed) error code. All the
other tests appear to pass. The error appeared when I took one of the
SIMMs out to try to see the part number. Some of the contacts on the
SIMM must not have been connected (the contacts appeared rather
dirty), and it didn't boot (and the diagnostic lights displayed a few
codes, and then just started flickering randomly). I did eventually
get it to boot, but with the error that I described. Is there any way
to fix the error other than replacing the motherboard? Could the
problem be solved by replacing the NVRAM chip?
-
Re: NVRAM error on DEC 3000/300X
Yes, if the system uses a Dallas or Benchmarq socketed clock/nvram chip. It's
worth a try, as these things wear out with regular writing and rewriting of
data. These chips are about the size of a lego. They are black with the
manufacturer, model and manufacturing date printed in white. Which chip does
your system have? ... Ben Myers
On 1 May 2007 06:46:14 -0700, Andrew Warkentin wrote:
>I have a DEC 3000/300X, and it is giving an "Unexpected interrupt"
>message when booting and when attempting to use "SHOW CONFIG". "T NVR"
>in SRM fails with a 400 (interrupt test failed) error code. All the
>other tests appear to pass. The error appeared when I took one of the
>SIMMs out to try to see the part number. Some of the contacts on the
>SIMM must not have been connected (the contacts appeared rather
>dirty), and it didn't boot (and the diagnostic lights displayed a few
>codes, and then just started flickering randomly). I did eventually
>get it to boot, but with the error that I described. Is there any way
>to fix the error other than replacing the motherboard? Could the
>problem be solved by replacing the NVRAM chip?
-
Re: NVRAM error on DEC 3000/300X
On May 1, 10:19 am, Ben Myers
wrote:
> Yes, if the system uses a Dallas or Benchmarq socketed clock/nvram chip. It's
> worth a try, as these things wear out with regular writing and rewriting of
> data. These chips are about the size of a lego. They are black with the
> manufacturer, model and manufacturing date printed in white. Which chip does
> your system have? ... Ben Myers
It has a Dallas DS1287A.
I don't think that the chip wore out. It was working fine when I got
it. As I had said before, the problem started when I pulled out one of
the SIMMs to see what the part number is. The contacts were kind of
dirty, and some must not have been connected, and when I turned it on,
the diagnostic LEDs flickered and it didn't boot. I did get it to
boot, but then it started giving me that error.
It is weird that the NVRAM holds settings when the computer is turned
off, but the RTC doesn't appear to be working. Are the settings stored
in Flash or something?
-
Re: NVRAM error on DEC 3000/300X
Oh, you're really pushing my memory as to how this stuff works. I once knew it
cold, but now we have all the new technology, and my memory dims.
IIRC, the DS1287A contains RTC, NVRAM and battery. The battery juice keeps the
RTC running and the NVRAM settings from degrading and corrupting. The DS1287A
has a life of 8-10 years according to manufacturer's specs. I would say that
the DS1287A needs to be replaced. In most modern systems, there is a trickle
charge from the line current flowing through a motherboard when the system is
powered down. If the system is unplugged, it loses the trickle charge, and with
a spent battery inside the DS1287A, the NVRAM gets corrupted.
If you want a couple or even three DS1287As, I have some here pulled from
motherboards I scrapped. Their battery components should still have some life.
Figure $10 including postage... Ben Myers
On 1 May 2007 17:16:00 -0700, Andrew Warkentin wrote:
>On May 1, 10:19 am, Ben Myers
>wrote:
>> Yes, if the system uses a Dallas or Benchmarq socketed clock/nvram chip. It's
>> worth a try, as these things wear out with regular writing and rewriting of
>> data. These chips are about the size of a lego. They are black with the
>> manufacturer, model and manufacturing date printed in white. Which chip does
>> your system have? ... Ben Myers
>
>It has a Dallas DS1287A.
>
>I don't think that the chip wore out. It was working fine when I got
>it. As I had said before, the problem started when I pulled out one of
>the SIMMs to see what the part number is. The contacts were kind of
>dirty, and some must not have been connected, and when I turned it on,
>the diagnostic LEDs flickered and it didn't boot. I did get it to
>boot, but then it started giving me that error.
>
>It is weird that the NVRAM holds settings when the computer is turned
>off, but the RTC doesn't appear to be working. Are the settings stored
>in Flash or something?
-
Re: NVRAM error on DEC 3000/300X
On May 1, 6:29 pm, Ben Myers
wrote:
> Oh, you're really pushing my memory as to how this stuff works. I once knew it
> cold, but now we have all the new technology, and my memory dims.
>
> IIRC, the DS1287A contains RTC, NVRAM and battery. The battery juice keeps the
> RTC running and the NVRAM settings from degrading and corrupting. The DS1287A
> has a life of 8-10 years according to manufacturer's specs. I would say that
> the DS1287A needs to be replaced. In most modern systems, there is a trickle
> charge from the line current flowing through a motherboard when the system is
> powered down. If the system is unplugged, it loses the trickle charge, and with
> a spent battery inside the DS1287A, the NVRAM gets corrupted.
>
> If you want a couple or even three DS1287As, I have some here pulled from
> motherboards I scrapped. Their battery components should still have some life.
> Figure $10 including postage... Ben Myers
>
> On 1 May 2007 17:16:00 -0700, Andrew Warkentin wrote:
>
> >On May 1, 10:19 am, Ben Myers
> >wrote:
> >> Yes, if the system uses a Dallas or Benchmarq socketed clock/nvram chip. It's
> >> worth a try, as these things wear out with regular writing and rewriting of
> >> data. These chips are about the size of a lego. They are black with the
> >> manufacturer, model and manufacturing date printed in white. Which chip does
> >> your system have? ... Ben Myers
>
> >It has a Dallas DS1287A.
>
> >I don't think that the chip wore out. It was working fine when I got
> >it. As I had said before, the problem started when I pulled out one of
> >the SIMMs to see what the part number is. The contacts were kind of
> >dirty, and some must not have been connected, and when I turned it on,
> >the diagnostic LEDs flickered and it didn't boot. I did get it to
> >boot, but then it started giving me that error.
>
> >It is weird that the NVRAM holds settings when the computer is turned
> >off, but the RTC doesn't appear to be working. Are the settings stored
> >in Flash or something?
I fixed the error. All that I had to do was boot VMS. I only had
Digital UNIX installed, but I was going to dual-boot VMS and Digital
Unix, but hadn't tried installing VMS yet.
The error must have occurred because the NVRAM was corrupted (it may
have had something to do with the clock speed setting, because it
occurred right after SRM printed the CPU type, when it would usually
print "OSC: 175 MHz" when booting or running "show config"). I don't
know why VMS resets the NVRAM if it sees that it is corrupted, but OSF/
1 doesn't. It is kind of silly that there is no way to reset the NVRAM
in hardware or firmware. At least I don't have to get a new NVRAM chip
or motherboard.
-
Re: NVRAM error on DEC 3000/300X
Andrew Warkentin schrieb:
>
> I fixed the error. All that I had to do was boot VMS. I only had
> Digital UNIX installed, but I was going to dual-boot VMS and Digital
> Unix, but hadn't tried installing VMS yet.
>
This might be a similar design flaw on DECs part as I've encountered
on an Alphastation. Apparently it was beyond DECs comprehension
that people would use the machines in dual boot mode,
with Unix as well as VMS. Booting one OS destroys the time information
the other has left. Obviously the two OS groups didn't talk too each other.